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 ...
agile
documentation
architecture
dry
Michael
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło