Atomic Spin

Programiści są świetni w rozpoznawaniu wzorców. Być może jest to wrodzona umiejętność, która przyciąga nas do tego zawodu. A może to proces pisania oprogramowania, który rozwija tę umiejętność. Tak czy inaczej, „nie powtarzaj się” (DRY) jest naturalnym zastosowaniem tej umiejętności.

Jednakże, powtarzanie samo w sobie nie jest wrogiem, za jakiego uchodzi ta zasada.

Don’t Repeat Yourself

Jakkolwiek intuicyjne może być „nie powtarzaj się”, The Pragmatic Programmer podsumowuje to w ten sposób:

Każdy fragment wiedzy musi mieć pojedynczą, jednoznaczną, autorytatywną reprezentację w systemie.

Nie jest trudno wyobrazić sobie korzyści płynące z ograniczenia lub wyeliminowania powtórzeń.

• Mniej duplikacji oznacza mniej kodu do utrzymania. A jeśli najlepszy kod to brak kodu w ogóle, brzmi to jak dobra rzecz.
• Jednolite źródło prawdy eliminuje możliwość, że rzeczy przestaną być zsynchronizowane. Zmieniła się jakaś reguła biznesowa? Zaktualizuj ją w jednym miejscu i gotowe.
• Kod jest wielokrotnego użytku. Masz proces, który jest współdzielony przez trzy rzeczy, a dodajesz czwartą? Większość pracy została już wykonana.

Sometimes Repeat Yourself

Zbyt gorliwe dążenie do ograniczenia pozornej duplikacji może stworzyć więcej problemów, niż rozwiązuje. Mówię „pozorna duplikacja”, ponieważ czasami rzeczy, które wyglądają podobnie, nie są w rzeczywistości powiązane. Na przykład, dwie struktury danych z identycznymi właściwościami i typami mogą być takie same strukturalnie, ale nie semantycznie.

Powszechną strategią redukcji duplikatów kodu jest wyodrębnienie części wspólnych i ukrycie ich za abstrakcją. Ale niepożądanym efektem ubocznym tego jest to, że sprzęga wszystko, co używa abstrakcji. Każda zmiana w abstrakcji wpływa na wszystkich jej konsumentów. I podobnie, abstrakcja może wymagać zgięcia, aby dopasować się do wymagań tylko jednego konsumenta.

Ten wzrost sprzężenia przychodzi również ze spadkiem elastyczności. Powiedzmy, że masz proces, który jest używany w trzech miejscach. Jest on prawie taki sam we wszystkich trzech miejscach, z kilkoma istotnymi różnicami. Więc implementujesz proces jako pojedynczy moduł, który pobiera kilka parametrów, aby pokryć różnice.

Poprawianie procesu tylko dla jednego z tych przypadków użycia jest teraz niemożliwe: każda zmiana w jednym wpływa na wszystkie trzy. Jasne, możesz dodać więcej parametrów (lub specjalnych przypadków!), ponieważ przypadki użycia różnią się od siebie. Ale szybko stanie się niemożliwe odróżnienie ważnych części procesu od infrastruktury oddzielającej przypadki użycia.

Pytania do zadania

Podczas refaktoryzacji istniejącego kodu lub pisania nowego kodu, który może być potencjalnie zduplikowany, zadaję sobie następujące pytania:

Czy jest to pojedynczy fragment wiedzy, który został zduplikowany, czy jest to tylko infrastruktura, która przypadkiem wygląda podobnie?

Więc przekopałeś się przez CSS i znalazłeś klasę, która po prostu ma style, które chcesz. To prawdopodobnie nie jest wystarczająco dobry powód, aby uniknąć definiowania innej klasy.

Ile razy ta rzecz została powtórzona?

Dopóki naprawdę zbędna rzecz nie pojawi się co najmniej trzy razy, byłbym bardzo sceptyczny wobec każdej redukcji powtórzeń, która zwiększa złożoność.

Czy redukcja duplikacji teraz utrudni dostosowanie poszczególnych przypadków w przyszłości?

Jest coś satysfakcjonującego w refaktoryzacji grupy kodu typu kopiuj-wklej w coś bardziej usprawnionego i wielokrotnego użytku. Ale zamknięcie kodu tak szczelnie, że każda zmiana wprowadziłaby specjalne przypadki, nie jest dobrym kompromisem.

Jeśli zredukuję tę duplikację, jaki jest stosunek między rozmiarem abstrakcji a liczbą parametrów, które ona przyjmie?

Biblioteki i frameworki są świetne, ponieważ zapewniają kod wielokrotnego użytku ze stosunkowo niewielką liczbą parametrów do dostosowania. Ale wyobraź sobie funkcję specyficzną dla aplikacji do prezentowania okna dialogowego, która się rozrosła i teraz przyjmuje 20 parametrów. Jakiekolwiek korzyści związane z redukcją powtórzeń istniały, gdy miała 2 parametry, już ich nie ma.

Wniosek

Jak w przypadku wielu zasad tworzenia oprogramowania, „nie powtarzaj się” jest bardziej wskazówką niż mantrą.

.