Czysty kod w praktyce - część 2

hotdeejay · Marzec 4, 2020

Reguła KISS, DRY oraz inne zasady dobrego programowania

Reguła KISS (ang. Keep It Simple, Stupid), dosłownie zrób to prosto, idioto – Prostota (i unikanie złożoności) powinna być priorytetem podczas programowania. Kod powinien być łatwy do odczytania i zrozumienia wymagając do tego jak najmniej wysiłku. Większość systemów działa najlepiej, gdy polegają na prostocie, a nie na złożoności. Należy się więc starać, aby nasz kod podczas analizy nie zmuszał do zbytniego myślenia. Gdy po jakimś czasie do niego wrócimy i nie wiemy co tam się dzieje, to znak, że musimy nad tym popracować. Dobrą metodą jest również pisanie naszych programów raz jeszcze gdy już poznaliśmy dokładnie proces, wprowadziliśmy wszystkie zmiany jakie zgłosił nam klient w trakcie odbioru oraz po wyprowadzeniu wszystkich początkowych błędnych założeń w trakcie programowanie offline.

Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac »
Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay.

Spis treści serii artykułów:

DRY (ang. Don't Repeat Yourself, pol. Nie powtarzaj się) – reguła stosowana podczas wytwarzania oprogramowania, zalecająca unikanie różnego rodzaju powtórzeń wykonywanych przez programistów - na przykład unikanie tych samych czynności podczas kompilowania, unikanie wklejania (lub pisania) tych samych (lub bardzo podobnych) fragmentów kodu w wielu miejscach. Wielokrotne użycie tego samego kodu to podstawa programowania (Zmiana implementacji tylko w jednym miejscu oraz lepsza czytelność kodu oraz łatwość w utrzymaniu).

Code for the Maintainer – czyli programuj tak jakbyś to robił dla osoby, która będzie później utrzymywać ten kod. Praca przy cudzym kawałku kodu to (przeważnie) najbardziej wymagająca i największa część pracy każdego programisty. Nie powinniśmy utrudniać sobie tego zadania. Zadbajmy więc o to, aby nie trzeba było się zbytnio głowić nad kawałkiem Twojego kodu. Pisz kod w taki sposób w jakim chciałbyś go otrzymać od kolego po fachu.

Boy scout rule – zawsze pozostaw po sobie kod czystszy niż go zastałeś.

REP - Reuse-release equivalence principle – ponowne użycie kodu to nie kopiowanie funkcji czy podprogramu z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie kod, to należy go wydzielić do biblioteki, którą później możemy użyć ponownie. Klasy oraz funkcje, które są przeznaczone do ponownego wykorzystania, powinny być w jednej paczce, aby mogła stać się reużywalną biblioteką. Nie powinny się tam znaleźć te, które nie są przeznaczone do ponownego wykorzystania. W skrócie - albo wszystkie są reużywalne, albo żadne. Zdecydowanie ułatwi to edycje biblioteki oraz rozbudowę.

Nie zawsze zasada KISS lub DRY jest słuszna!

Weźmy np. zasadę DRY – Don’t Repeat Yourself – piszemy kod, który jest reużywalny, nie powtarzamy logiki zawartej w jednym miejscu w aplikacji, w innym. Tylko, że z tego rodzą się czasem klasy czy funkcje potwory. Okazuje się, że mają wiele rozglłęzień, skomplikowaną strukturę – tylko po to, żeby nie powtórzyć się w innym miejscu.

I tu mamy problem – jest to świadome naginanie reguły KISS – Keep It Simple Stupid – która mówi o tym, żeby kod był tak prosty, jak to tylko możliwe.

Wniosek nasuwa się jeden – nie istnieje srebrna kula. Nie istnieje też żaden złoty środek. Nie ma idealnego scenariusza, w którym weźmiemy garść złotych myśli (nasze reguły) i mamy gotowy przepis na sukces. Trzeba pamiętać o tym, żeby nie mieć klapek na oczach. Należy umiejętnie żonglować poszczególnymi zasadami, żeby osiągnąć satysfakcjonujący, końcowy rezultat. Zasady tylko wspomagają nas jako programistów, są narzędziem, które musimy umiejętnie wykorzystać.

Zmiana osoby w projekcie a jakość kodu – jaki ma to wpływ na projekt i dochód?

Wraz ze wzrostem bałaganu w oprogramowaniu niewątpliwie spada efektywność zespołu, co w znacznym stopniu paraliżuje projekt. Wobec spadku efektywności osoba odpowiedzialna za dany projekt zwykle dodaje do projektu więcej osób w nadziei, że podniesie to wydajność zespołu i uda się wyprowadzić problem tak, aby klient odebrał oprogramowanie. Jednak nowe osoby nie są zaznajomione z projektem oraz procesem jaki się tam odbywa, zasadą działania współpracujących ze sobą klas, czujników itd. Nie wiedzą, na jakie zmiany projektu mogą sobie pozwolić, a jakie spowodują jego naruszenie czy też zaprzestanie działania innych części kodu projektu. Dodatkowo, tak jak wszyscy pozostali w zespole, są pod ogromną presją zwiększenia wydajności swojej pracy, często w nadgodzinach czy dniach dla nich domyślnie wolnych. Należy tutaj pamiętać, że praca programisty to nie to samo, co człowieka na produkcji. Efektywność programisty to ok 6 godzin na dobę, ponieważ jest to praca umysłowa, wymagająca skupienia oraz kreatywnego myślenia.

Należy mieć również na uwadze fakt, że to nie kierownictwo, ale programista jest fachowcem w programowaniu i zarządzaniu kodem i to programista musi umieć wywrzeć na swoich przełożonych świadomość jak ważny jest czysty kod. Nic nie ma tak głębokiego i w długim czasie degradującego wpływu na prowadzenie projektu, jak zły kod.

Po pierwszym nieudanym projekcie spowodowanym złym kodem, lider projektu powinien wyciągnąć wnioski, aby zapobiec podobnym sytuacjom w przyszłości. Jednym z działań mającym zapobiegać bałaganowi w kodzie jest refaktoryzacja. Spowoduje to wprawdzie dodatkowe obłożenie czasowe (refaktoryzacja jest kosztowna czasowo, ale jest istotnym elementem zarządzania projektem informatycznym), które należy wziąć pod uwagę w trakcie ustalania harmonogramu projektu, ale zmniejsza prawdopodobieństwo pisania całego kodu od nowa.

Podsumowanie

Podsumowując, nie istnieje coś takiego, jak szablon dobrych zasad projektowania. Styl pisania kodu należy dostosować do projektu jaki jest tworzony, jego zagadnień czy problematyki – należy jednak być w tym bezwzględnie konsekwentnym. Jeśli będziemy w taki sposób pracować, efektywność naszej pracy będzie stale rosnąć. Jeśli czytelnik artykułu jest początkującym programistą, to stosując powyższe metody zoptymalizuje i uporządkuje swój kod, a co za tym idzie, jego projekty będą bardziej satysfakcjonujące i być może dzięki temu stanie się zawodowym programistą czego z całego serca życzę.