Zasady i jakosc kodu

Powtarzalne rozwiązanie problemu, które wydaje się skuteczne, lecz w praktyce przynosi więcej szkód niż korzyści.

Powierzchniowy objaw w kodzie sugerujący głębszy problem projektowy, np. zbyt długa metoda czy duplikacja, wskazujący kandydata do refaktoryzacji.

Skumulowany koszt przyszłych poprawek wynikający z wyboru łatwiejszego, gorszego rozwiązania zamiast lepszego, lecz pracochłonniejszego.

Miara liczby liniowo niezależnych ścieżek przepływu sterowania w programie, używana do oceny złożoności i testowalności kodu.

Stopień, w jakim elementy pojedynczego modułu są ze sobą funkcjonalnie powiązane i służą jednemu zadaniu; wysoka spójność jest pożądana.

Stopień wzajemnej zależności między modułami; niskie sprzężenie ułatwia zmiany i ponowne użycie, wysokie utrudnia utrzymanie.

Metoda określania wzajemnych zobowiązań komponentów przez warunki wstępne, końcowe i niezmienniki traktowane jak kontrakt.

Styl pisania kodu zakładający możliwość nieprawidłowych danych i stanów, chroniący program przez walidację wejść i obsługę błędów.

Zmiana wewnętrznej struktury kodu poprawiająca jego czytelność i strukturę bez modyfikacji obserwowalnego zachowania zewnętrznego.

Każdy element wiedzy w systemie powinien mieć jedną, jednoznaczną i autorytatywną reprezentację, bez powielania logiki.

Projektowanie modułu tak, by decyzje projektowe podatne na zmianę były niewidoczne dla pozostałych modułów.

Wyodrębnienie istotnych cech bytu z pominięciem szczegółów nieistotnych z danego punktu widzenia, dające uproszczony model.

Ukrycie wewnętrznego stanu i implementacji składnika za zdefiniowanym interfejsem, ograniczające bezpośredni dostęp z zewnątrz.

Zestaw pięciu zasad projektowania zorientowanego obiektowo (m.in. jednej odpowiedzialności, otwarte-zamknięte) wspierających utrzymywalność i rozszerzalność.

Klasa lub moduł powinien mieć tylko jeden powód do zmiany, czyli jedną odpowiedzialność wobec aktora.

Moduły wysokopoziomowe nie powinny zależeć od niskopoziomowych; obie warstwy zależą od abstrakcji, a nie od konkretów.

Obiekty typu bazowego można zastąpić obiektami podtypu bez naruszenia poprawności programu.