Czy opis architektury stanowi naruszenie zasady DRY?

11

Zasada DRY (Don't Repeat Yourself) mówi, że „każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie”. Najczęściej odnosi się to do kodu, ale często obejmuje również dokumentację.

Mówi się, że każdy system oprogramowania ma architekturę, niezależnie od tego, czy ją wybierzesz, czy nie. Innymi słowy, oprogramowanie, które budujesz, ma strukturę, a struktura „po zbudowaniu” jest architekturą oprogramowania. Skoro wbudowany system oprogramowania ma architekturę, czy tworzenie opisu architektury tego systemu stanowi naruszenie zasady DRY? W końcu, jeśli chcesz poznać architekturę, zawsze możesz po prostu spojrzeć na kod ...

— Michael
źródło

Czy naprawdę wierzysz, że potrafisz rozpoznać architekturę, patrząc na kod? Kod powie ci wszystkie wymagania funkcjonalne i niefunkcjonalne, kompromisy architektoniczne, problemy z wdrażaniem, kontekst biznesowy, scenariusze przypadków użycia itp. Itp.? Jeśli Twój kod może PRAWDZIWIE ci to powiedzieć, to cholernie prosty system.

— luis.espinal

@ luis.espinal, Możliwe jest odróżnienie struktur statycznych i dynamicznych odpowiednio od kodu i działającego systemu. To, czy struktury te są równoważne architekturze systemu, będzie zależeć od twojej szkoły myślenia. Jak już wskazałeś, nadal brakuje ci dużych fragmentów, w tym sterowników architektonicznych i uzasadnienia decyzji projektowych.

— Michael

Jaka istna szkoła myślenia przyrównuje struktury pochodzące z kodu do architektury systemu? Jeśli wiemy, że będziemy tęsknić za dużymi fragmentami, w tym za wszelkimi sterownikami architektonicznymi, to tęsknimy za całą architekturą. Dowodzi to w sposób trywialny, że statyczne i dynamiczne struktury, które można odróżnić od samego kodu, nie reprezentują całej architektury (niezależnie od szkoły myślenia). Jeśli spojrzymy na dość dobrze ustalone definicje architektury systemów i oprogramowania (tj. SEI lub INCOSE), są jasne, że kod jest tylko ułamkiem architektury.

— luis.espinal

przykładem. Architektura systemu może wymagać ode mnie wdrożenia na określonej liczbie komputerów z wyłączonymi i włączonymi interfejsami zewnętrznymi w określonej kolejności. Struktury statyczne i dynamiczne pochodzące z samego kodu z trudem uchwycą to (jeśli w ogóle). Najwyraźniej jednak są one częścią wdrażania i aspektów operacyjnych architektury systemu. I każdy kod pochodzi struktura będzie dotyczyć tylko tych realizacjach statycznych aspektów oprogramowania aplikacji (lub jego element) architektury. Nigdy nie może być architektury systemu .

— luis.espinal

1

@ luis.espinal, zapraszam do przesłania odpowiedzi na to pytanie! Wygląda na to, że oferujesz doskonałą perspektywę, która moim zdaniem mogłaby wnieść prawdziwą wartość do tego tematu. Głosisz na ten temat w chórze, więc dlaczego nie stworzyć odpowiedzi, która w pełni wyjaśnia twoje myślenie, aby każdy mógł skorzystać? Właśnie dlatego zadałem to pytanie.

— Michael

11

Czy powielanie myśli w kodzie narusza zasadę DRY?

Rany, gdybyś mógł po prostu poznać architekturę, patrząc na kod, nie byłoby takich rzeczy jak „dokumenty opisu architektury”. To nie jest powtórka, to kolejny poziom opisu systemu , którego nie można w prosty sposób wydedukować z kodu i odwrotnie. Ma więc pełne prawo do istnienia, nawet jeśli obejmuje SUSZENIE.

— P Shved
źródło

7

Nie bierz DRY jako twardej i szybkiej zasady. To dobra rzecz, ale możesz to przybliżyć w praktyce.

Myślę też, że nie jest dobrze napisany. Wydaje się, że „nie powtarzaj się” nie obejmuje równie ważnego przypadku, że aby dokonać semantycznej lub funkcjonalnej zmiany, musiałbyś edytować tekst źródłowy w wielu miejscach, mówiąc różne, ale skoordynowane rzeczy.

Zamiast traktować to jako przykazanie, aby nie zostać naruszone, lepiej zrozumieć, dlaczego jest to dobry pomysł i dokonywać rozsądnych wyborów. Powodem, dla którego źle jest dokonywać skoordynowanych zmian w wielu miejscach, jest to, że redaktor popełnia błędy. Nie jesteś w 100% niezawodny, aby dokonywać zmian bez błędów. Jeśli musisz wprowadzić 10 różnych zmian tekstu źródłowego, a poprawnie otrzymujesz tylko 9 z nich, popełniłeś błąd . Dlatego dobrze jest ustawić tekst źródłowy w celu zminimalizowania liczby skoordynowanych zmian. Minimalizuje błędy.

Nie należymy do religii, w której SUCHANIE jest jednym z przykazań. Jest to po prostu poręczny, choć nieco mylący sposób na zakodowanie zdrowego rozsądku.

— Mike Dunlavey
źródło

4

Architektura Opis lub Software Design Opis nie naruszają suche. Jednak w dużej organizacji, w której projekty są w ostatnich latach, programiści przychodzą i odchodzą, a system jest zbyt duży, aby jakakolwiek osoba mogła zachować wszystkie szczegóły w głowie, jest to dokument krytyczny. Ilość „powtórzeń” potrzebnych do utrzymania synchronizacji jest całkowicie warta wysiłku zaoszczędzonego podczas następnej aktualizacji lub konserwacji.

— AShelly
źródło

1

To nieporozumienie lub ślepe zastosowanie DRY. Opis architektoniczny nie stanowi jego naruszenia. Jeśli ktoś zastosowałby SUCHO w ten sposób na ślepo, to wszystko poza kodem stanowi naruszenie tego prawa ... i oczywiście nie było to intencją tych, którzy wpadli na ten pomysł.

— luis.espinal

2

Opis architektury nie narusza zasady DRY.

Twój system oprogramowania ma pewną architekturę. I jest rozłożony na wiele plików, w wielu klasach, z wieloma dodatkowymi i szczegółami, które nie są potrzebne do przeglądu.

Twój dokument architektury powinien być jak pierwszy akapit raportu informacyjnego: jest to zarys, streszczenie, mapa drogowa projektu.

— Frank Shearar
źródło

1

Jeśli datujesz dokument, wówczas opisuje on architekturę w momencie pisania.

Podczas gdy kod reprezentuje architekturę w chwili obecnej.

Dwie oddzielne rzeczy - nie ta sama wiedza.

Tak długo, jak oświadczysz, że dokument reprezentuje architekturę w momencie pisania, nie powielasz wiedzy IMO, ponieważ jest to inna wiedza, jeśli chodzi o system w innym momencie.

— Nikt
źródło

Kod nigdy nie reprezentuje architektury. To tylko przejaw architektury. Kod, który został zmieniony dzisiaj, może nadal reprezentować architekturę wczorajszą. Co więcej, może nie reprezentować zamierzonej (lub wymaganej umownie) architektury, o co musisz się najbardziej martwić. Kod nie mówi ci, czy to dobrze, czy źle, tylko że działa. Aby wiedzieć, czy jest to dobre, czy złe, musisz spojrzeć na zamierzoną architekturę i wymagania, które doprowadziły system na początek.

— luis.espinal