7 najpopularniejszych zasad programowania
7 najpopularniejszych zasad programowania

Im więcej ludzi, tym więcej pomysłów — zawsze tak jest, programowanie nie jest wyjątkiem. Było wiele podejść do tego, jak tworzyć lepszy kod. Jedne pomysły były lepsze, inne gorsze. W końcu postanowiono stworzyć pewne zasady, reguły postępowania z kodem. Te założenia nie są wymagane same z siebie, lecz pomagają tworzyć czysty i dobry kod, często ułatwiając też lepsze jego pisanie czy zrozumienie. Oto najważniejsze zasady.

1. DRY – Nie powtarzaj się

DRY, czyli Don’t Repeat Yourself to zasada mówiąca o tym, aby nie powtarzać kodu odpowiedzialnego za jedną funkcjonalność. W praktyce, jeżeli musimy w paru miejscach użyć jednej funkcjonalności, np. policzyć opłaty, i za każdym razem jest zmieniona tylko jedna rzecz, lepiej jest wynieść tę funkcjonalność do oddzielnej funkcji i ją wywoływać. Z logowaniem to samo — zamiast od zera pisać kod dla każdego przypadku logowania (user, admin itp.), należy użyć tego samego kodu z odpowiednimi parametrami. Ogólnie — nie powtarzamy takiego samego kodu.

2. KISS – Kod musi być prosty i czytelny

KISS to skrót od Keep it Simple, Stupid lub Keep it Super Simple. Zasada ta mówi o tym, żeby nie komplikować kodu, aby każdy mógł go bez problemu przeczytać i zrozumieć. W praktyce — piszmy prosty i czytelny kod, zamiast jednolinijkowców na 300 znaków, lepiej zapisać to prościej i czytelniej. Zamiast posługiwać się za krótkimi lub za długimi nazwami, niech będą dla nas zwięzłe, ale znaczące. Zamiast trzymać wszystko w jednej klasie czy funkcji, rozbijmy to na odpowiednie bloki kodu. Czytelność przede wszystkim.

3. SOLID – 5 zasad programowania obiektowego

SOLID to 5 zasad programowania obiektowego, niemal podstawa obiektowości. SOLID to skrót od pierwszych liter tych reguł:

Single responsibility principle – zasada pojedynczej odpowiedzialności
Open/closed principle – zasada otwarte – zamknięte
Liskov substitution principle – zasada podstawiania Liskova
Interface segregation principle – zasada segregacji interfejsów
Dependency inversion principle – zasada odwrócenia zależności

Zasady te są ściśle związane z programowaniem obiektowym, więc wytłumaczę je prosto, niemniej i tak potrzeba chociaż minimalnej wiedzy z obiektowości, żeby wiedzieć, o co chodzi:

Single responsibility principle – Zasada mówiąca o tym, że każda klasa/moduł/funkcja powinna zawierać kod odpowiadający tylko jednej specyficznej funkcjonalności. W przypadku funkcji może to być np. obliczanie odległości, w przypadku modułu/klasy to może być obliczenie całej trasy od A do Z, gdzie w środku znajdziemy funkcje z poprzedniego przykładu. Jeżeli w tej klasie obliczamy trasę, to nie sprawdzamy też pogody czy wagi auta, obliczamy tylko i wyłącznie trasę. Częściej spotykany przykład – moduł logowania odpowiadać powinien tylko za logowanie i nic więcej. Po zalogowaniu idziemy w inne miejsce w kodzie i tam sterujemy dalszymi akcjami – logowanie to tylko i wyłącznie logowanie.

Open/closed principle – zasada mówiąca o tym, że klasy, funkcje czy obiekty powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje. W praktyce chodzi o to, żeby można było zmienić działanie klasy/funkcji/obiekty bez zmiany jego kodu. Można to osiągnąć np. poprzez odpowiednie parametry przekazywane do funkcji czy używanie abstrakcji.

Liskov substitution principle – zasada mówiąca o tym, że klasa dziedzicząca powinna tylko rozszerzać możliwości klasy bazowej. Nie powinna za to zmieniać tego, co robiła już wcześniej. Jeżeli klasa A posiada funkcję X, a klasa B dziedziczy z klasy A, to wywołanie B.X powinno dać te same rezultaty co wywołanie A.X.

Interface segregation principle – zasada ta mówi o tym, że klasy implementujące interfejsy nie powinny mieć dostępu do funkcji, których nie używają, lub z drugiej strony, klasa implementuje tylko te interfejsy, które są niezbędne do wykonania operacji. Chodzi o to, żeby interfejsy rozbić na jak najmniejsze logicznie spójne wiele interfejsów (zasada pojedynczej odpowiedzialności) i implementować tylko te, które są potrzebne, oraz nie wrzucać do interfejsu funkcji niepotrzebnych.

Dependency inversion principle – zasada ta mówi o tym, że wysokopoziomowe moduły nie mogą zależeć od modułów niskopoziomowych. Chodzi tutaj o to, aby w module wysokopoziomowym, którym może być np. Auto, nie dodawać w implementacji bezpośredniej zależności od modułów niskopoziomowych, np. Drzwi, Lusterka itp. Zamiast tego można przekazać te obiekty już gotowe z innego miejsca w kodzie jako parametry funkcji.

4. YAGNI – nie będziesz tego potrzebować

YAGNI to skrót od You Ain’t Gonna Need It, czyli Nie będziesz tego potrzebować. Zasada ta mówi o tym, żeby nie zatrzymywać w aplikacji nieużywanego kodu. Jeżeli nie wykorzystujemy jakiejś funkcji czy klasy – usuwamy ją. W końcu mamy jakiś system kontroli wersji i możemy do tego wrócić. Inny przykład – nie zaciągajmy całej biblioteki tylko po to, żeby użyć tylko jednej funkcji. Cała reszta biblioteki będzie nam wtedy nie potrzebna, a i tak będzie ściągana za każdym razem. Jeżeli nie jest to coś bardzo skomplikowanego, można samemu to zaimplementować.

5. Separation of Concerns – Separacja zagadnień

Zasada mówi o tym, aby podzielić cały program na oddzielne moduły, które jak najmniej pokrywają się, jeżeli chodzi o funkcjonalności. Inaczej – modułowa budowa projektu. Pozwala to na łatwiejszą rozbudowę systemu, poprawia czytelność kodu oraz re używalność elementów.

6. Avoid Premature Optimization – unikaj przedwczesnej optymalizacji

Zasada ta mówi o tym, żeby unikać przedwczesnego skupiania się na ekstremalnej optymalizacji. Po pierwsze, lepiej poświęcić mniej czasu, ale skończyć więcej aplikacji, a po drugie, często ta optymalizacja jest niepotrzebna. Owszem, w krytycznych punktach aplikacji musimy ją zrobić, ale nie jest to konieczne zawsze i wszędzie. Być może naszą aplikację będzie używać 100 osób i jakakolwiek implementacja będzie odpowiednia. Poczekajmy z optymalizacją na odpowiedni moment i faktyczną potrzebę.

7. Odpowiednie nazwy

Zasada bez konkretnej nazwy, mówiąca o odpowiednim nazywaniu zmiennych, funkcji, klas itp. Bardzo często nazwy są po prostu złe: za krótkie, za długie, nic niemówiące itp. Każdy spotkał się z nazwami w stylu a,b,c,zxc,asd, test, tmp itp. Z drugiej strony, zbyt szczegółowe nazywanie też jest złe, np. variableForHandlingAsyncResponseFromServer. Powinniśmy nazywać zmienne, funkcje i klasy możliwie jak najkrócej, ale jak najbardziej treściwie. Zwykle, jedno czy dwa słowa o tym, co dana rzecz robi. Nie tylko poprawia to czytelność kodu dla nas, ale też dla zespołu pracującego nad tym samym kodem.

Podsumowanie

Powyższe zasady są najpopularniejsze, ale oczywiście to nie wszystkie. Ich znajomość powinna jednak pomóc Ci przejść rozmowę kwalifikacyjną. Polecam zapoznać się ze wszystkimi oraz używać ich w swoich projektach – uprości to twoje developerskie życie.

Jeżeli uważasz, że czegoś tu brakuje, zapraszam do komentarzy 🙂

4 KOMENTARZE

  1. „Inny przykład – nie zaciągajmy całej biblioteki tylko po to, żeby użyć tylko jednej funkcji. Cała reszta biblioteki będzie nam wtedy nie potrzebna, a i tak będzie ściągana za każdym razem. ”

    Co z tego, że ściągasz? Internetu nie zbraknie 🙂 Problemem jest budowanie, ale od tego jest tree shaking, żeby się pozbyć nie potrzebnych rzeczy w buildzie.

    • „Internetu nie zbraknie 🙂” – tutaj się nie zgodzę, teraz bardzo dużo starań idzie w mobilki, a strony na komórkach fajnie jakby ważyły jak najmniej. Internet komórkowy nie wszędzie jest dobry, a strony, które się długo ładują, są nie najlepsze w odbiorze dla potencjalnych odbiorców czy klientów. Są oczywiście wyjątki, ale niestety ogólnie lepiej jak jest mniej do ściągania.
      Zgodzę się za to z tree shaking 😀 można eliminować każdy niepotrzebny kod. Pytanie brzmi – czy zawsze i wszędzie wyeliminuje 100% niepotrzebnego kodu? I czy poza kodem usunie niepotrzebne pliki, np. zdjęcia?

  2. Całkiem zgrabne podsumowanie. Brakuje mi tu jednak jeszcze jednej zasady, która jest dość istotna. Chodzi mi o zasadę „przedkładaj kompozycję nad dziedziczenie” :). Ale chyba najważniejsze są zasady SOLID szczególnie myślę, że istotna jest zasada pojedynczej odpowiedzialności, z którym my programiści często mamy kłopot. Wyczerpujące omówienie tych zasad można znaleźć na https://javadeveloper.pl/solid/. Dość szczegółowo też tam została omówiona zasada podstawień Liskov i technika DBC, która pozwala egzekwować tę zasadę.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here