Zasada DRY (don’t repeat yourself)

Co warto wiedzieć

DRY dotyczy jednej wiedzy biznesowej utrzymywanej w jednym miejscu. Zbyt wczesne łączenie podobnego kodu tworzy trudną abstrakcję, dlatego powtórzenie bywa rozsądne, dopóki wspólny wzorzec nie jest stabilny.

Rola w projekcie

Zasada DRY (Don’t Repeat Yourself) pojawia się w projektowaniu, programowaniu i utrzymaniu aplikacji internetowych. Sposób użycia trzeba dopasować do celu, ryzyka i technologii danego projektu.

Na co zwrócić uwagę

Dobre rozwiązanie powinno być zrozumiałe dla zespołu, możliwe do przetestowania i dopasowane do skali systemu. Dokumentacja oraz pomiar przed i po zmianie ograniczają ryzyko ukrytych kosztów.

Praktyczna checklista

1. Krok 1: Zapisz problem i kryterium poprawnego wyniku.
2. Krok 2: Wybierz rozwiązanie pasujące do danych i środowiska.
3. Krok 3: Przetestuj przypadki typowe, błędne oraz graniczne.
4. Krok 4: Wdróż zmianę i monitoruj jej wpływ na system.

Najczęstsze pytania

Gdzie wykorzystuje się zasada DRY (don’t repeat yourself)?

To pojęcie pojawia się w projektowaniu, programowaniu i utrzymaniu aplikacji internetowych. Konkretne zastosowanie zależy od architektury serwisu, danych i potrzeb użytkowników.

Czy zasada DRY (don’t repeat yourself) wymaga kontroli po wdrożeniu?

Kontrola pozwala potwierdzić działanie w środowisku produkcyjnym i wykryć skutki uboczne. Jej zakres oraz częstotliwość powinny odpowiadać ryzyku zmiany.

Źródło i dalsza lektura

MDN Web Docs