Duplikacja kodu vs. błędne abstrakcje
Programiści często stają przed wyborem.
Musisz wybrać między zasadą Don't Repeat Yourself a dopuszczeniem pewnej duplikacji kodu.
DRY to fundamentalna zasada projektowania oprogramowania. Jednak zbyt gorliwe dążenie do niej tworzy nowy problem: tworzysz błędną abstrakcję.
Błędna abstrakcja kosztuje więcej niż duplikacja kodu.
Chcemy pisać elegancki kod. Chcemy budować reużywalną logikę. Chcemy naprawić błąd w jednym miejscu i widzieć, że został on naprawiony wszędzie. Ten cel wydaje się słuszny.
Jednak przedwczesna abstrakcja zabija tempo prac nad projektem. Psuje łatwość utrzymania kodu.
Kiedy dokonujesz abstrakcji zbyt wcześnie, mierzysz się z następującymi problemami:
- Zwiększona złożoność. Złe abstrakcje dodają kolejne warstwy niejasności.
- Sztywny kod. Trudno staje się zmienić jedną część bez psucia innych.
- Ukryta logika. Więcej czasu spędzasz na śledzeniu kodu niż na jego pisaniu.
Czasami duplikacja jest pragmatycznym wyborem. Pozwala zachować kod prostym i przejrzystym. Umożliwia niezależną zmianę poszczególnych części systemu.
Nie buduj generycznego rozwiązania dla problemu, którego jeszcze w pełni nie rozumiesz. Poczekaj, aż wzorzec stanie się jasny.