Nie powtarzaj się - Don't repeat yourself

„ Nie powtarzaj się ” ( DRY lub czasami „ nie powtarzaj się ”) to zasada tworzenia oprogramowania mająca na celu zmniejszenie powtarzalności wzorców oprogramowania, zastąpienie ich abstrakcjami lub wykorzystanie normalizacji danych w celu uniknięcia nadmiarowości.

Zasada DRY jest sformułowana jako „Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie”. Zasadę tę sformułowali Andy Hunt i Dave Thomas w swojej książce The Pragmatic Programmer . Stosują ją dość szeroko, obejmując „ schematy baz danych , plany testów , system budowania , a nawet dokumentację ”. Gdy zasada DRY zostanie z powodzeniem zastosowana, modyfikacja pojedynczego elementu systemu nie wymaga zmiany innych logicznie niepowiązanych elementów. Ponadto wszystkie elementy, które są powiązane logicznie, zmieniają się w przewidywalny i jednolity sposób, dzięki czemu są zsynchronizowane . Oprócz używania metod i podprogramów w swoim kodzie, Thomas i Hunt polegają na generatorach kodu , automatycznych systemach budowania i językach skryptowych, aby przestrzegać zasady DRY na różnych warstwach.

Alternatywy

MOKRY

Naruszenia DRY są zwykle określane jako rozwiązania WET, powszechnie uważane za „napisz wszystko dwa razy” (alternatywnie „napisz za każdym razem”, „lubimy pisać” lub „marnować czas wszystkich”). Rozwiązania WET są powszechne w architekturach wielopoziomowych, w których programista może mieć na przykład zadanie dodania pola komentarza do formularza w aplikacji internetowej. Ciąg tekstowy „komentarz” może być powtórzony w etykiecie, znaczniku HTML, nazwie funkcji odczytu, zmiennej prywatnej, DDL bazy danych, zapytaniach i tak dalej. Podejście DRY eliminuje tę nadmiarowość, używając frameworków, które redukują lub eliminują wszystkie te zadania edycyjne z wyjątkiem najważniejszych, pozostawiając możliwość dodawania nowych zmiennych wiedzy w jednym miejscu.

AHA

Innym podejściem do abstrakcji jest zasada AHA. AHA to skrót od „Avoid Hasty Abstractions”, opisany przez Kenta C. Doddsa jako najpierw optymalizacja pod kątem zmian i unikanie przedwczesnej optymalizacji. i był pod wpływem Sandi Metz „preferuj powielanie niż niewłaściwą abstrakcję”.

AHA opiera się na zrozumieniu, że im głębiej zainwestowaliśmy w wyabstrahowanie fragmentu oprogramowania, tym bardziej dostrzegamy, że koszt tej inwestycji nigdy nie może zostać odzyskany ( błąd o zatopionych kosztach ). Dlatego inżynierowie mają tendencję do kontynuowania iteracji na tej samej abstrakcji za każdym razem, gdy zmienia się wymaganie. Programowanie AHA zakłada, że ​​zarówno rozwiązania WET, jak i DRY nieuchronnie tworzą oprogramowanie, które jest sztywne i trudne w utrzymaniu. Zamiast zaczynać od abstrakcji lub abstrahować od określonej liczby duplikatów, oprogramowanie może być bardziej elastyczne i niezawodne, jeśli abstrakcja jest wykonywana wtedy, gdy jest potrzebna, lub gdy sama duplikacja stała się barierą i wiadomo, jak abstrakcja potrzebuje. funkcjonować.

Zobacz też

Bibliografia

Zewnętrzne linki