Główne zasady programowania – o tym musisz pamiętać!

9 lutego 2019 9 minut czytania

Dzisiejszy temat, podobnie jak poprzedni, będzie nieco bardziej zbliżony do kodu. Jednak bez obaw, nie każę Wam programować. Opowiem Wam o podstawowych zasadach, do których powinien stosować się każdy programista. Tak więc tradycyjnie zachęcam do zajęcia wygodnej pozycji do czytania i zaczynamy!

Po co definiować jakieś zasady?

Najpierw musimy sobie powiedzieć, dlaczego w ogóle powstały jakieś zasady. Jeszcze zanim zacząłem programować, to myślałem, że programowanie po prostu polega na wpisywaniu wyuczonych formułek odpowiedzialnych za różne funkcjonalności. Według o wiele młodszego mnie istniał na przykład tylko jeden sposób dodania przycisku na ekran, czyli kodu odpowiedzialnego za to działanie trzeba było uczyć się na pamięć. Na szczęście rzeczywistość jest całkowicie inna. Nie musimy uczyć się kodu na pamięć, a jedną funkcjonalność możemy zaimplementować na tysiące różnych sposobów. To właśnie mnogość sposobów implementacji jest przyczyną powstania zasad dotyczących programowania. To, że mamy tysiące sposobów nie oznacza bowiem, że każdy jest dobry. Gdyby każdy pisał, tak jak mu pasuje, to w projekcie powstałby ogromny chaos. Odpowiednie zasady pomagają zapanować nad całym tym bałaganem.

Kiedy kod jest dobry?

Jest wiele różnych definicji, które odpowiadają na powyższe pytanie, dlatego napiszę, kiedy ja uważam, że kod jest dobry. Załóżmy, że mam ocenić kod odpowiedzialny za pewną funkcjonalność — na co będę patrzył przede wszystkim? Dla mnie najważniejsza jest jego czytelność. Jest to pojęcie dość abstrakcyjne, ale chodzi o to, żeby na pierwszy rzut oka było wiadomo, co dokładnie dany kod robi.

Sprawdzany przeze mnie kod powinien oczywiście działać, więc sprawdzam też, czy jest pokryty testami jednostkowymi (o testach jednostkowych pisałem w odcinku o testowaniu aplikacji). Kolejnym ważnym aspektem jest sprawdzenie, czy programista użył najnowszych dostępnych rozwiązań. Języki programowania i frameworki stale są rozwijane, dlatego warto stosować najnowsze funkcjonalności, a nie pisać kodu według wzorców, które odeszły do lamusa kilka lat temu. Na koniec, patrzę również czy kod jest otwarty na przyszłe zmiany, ponieważ oprogramowanie stale ewoluuje i zawsze powinniśmy zakładać, że dana funkcjonalność może się w przyszłości zmienić.

Jeśli te aspekty są spełnione, mogę z czystym sumieniem powiedzieć, że dany kod jest dobry. Oczywiście trzeba podchodzić do tego wszystkiego zdroworozsądkowo i jeżeli jest jakaś przyczyna, dla której musimy nagiąć jedną z zasad, to można na to przymknąć oko.

Zasada DRY — nie powtarzaj się!

Skrót DRY pochodzi os słów Don’t repeat yourself, co możemy przetłumaczyć jako po prostu „Nie powtarzaj się”. W kontekście programowanie jest to zasada niesłychanie ważna. Jej brzmienie jest dość proste, można je streścić zdaniem: nie powinniśmy dublować kodu odpowiedzialnego za jedną funkcjonalność. Jak to się przekłada na praktykę? Najlepiej pokazać to na przykładzie.

Wyobraź sobie, że masz aplikację służącą do kupowania biletów kolejowych. Bilety mogą kupować zarówno użytkownicy zalogowani, jak i goście. W przypadku użytkownika zalogowanego zakupiony bilet zostaje przypisany do jego konta, użytkownik taki dostaje również punkty lojalnościowe. W pewnym momencie klient stwierdził, że chciałby również dać możliwość logowania na końcu procesu kupowania biletu, tak aby gość już po zakupie mógł zdecydować, czy chce się zalogować i otrzymać dzięki temu punkty lojalnościowe. W celu implementacji takiej funkcjonalności mógłbyś po prostu skopiować kod odpowiedzialny za logowanie i wkleić go na ekranie kończącym proces kupowania biletu. Takie rozwiązanie będzie działać, jednak teraz za każdym razem jak klient zażyczy sobie zmiany w funkcjonalności logowania, będziesz musiał modyfikować kod w dwóch różnych miejscach (w logowaniu zwykłym i na końcu procesu kupowania biletu). W takiej sytuacji bardzo łatwo jest się pomylić lub zapomnieć o jednym z miejsc, gdzie dany kod występuje.

Stosując zasadę DRY w powyższym przykładzie, powinniśmy wydzielić kod odpowiedzialny za logowanie do jakiejś osobnej klasy i odwołać się do niej zarówno podczas normalnego logowania, jak i podczas logowania po zakończeniu procesu kupowania. Zalety DRY są widoczne dopiero po pewnym czasie, ponieważ przeważnie jest szybciej po prostu przekopiować kod, niż bawić się w jakieś wydzielanie go do innej klasy. Jednak stosując DRY, ułatwiamy sobie utrzymywanie kodu oraz jego przyszłe modyfikacje.

KISS — nie komplikuj

KISS jest skrótem od Keep it Simple, Stupid — tłumacząc to dosłownie, wyjdzie nam coś w stylu: Nie Komplikuj, Głupku. Jednak takie tłumaczenie jest bez sensu, bo nie oddaje przekazu tej zasady i wydaje się obraźliwe. Na polskiej Wikipedii znalazłem świetne przełożenie tego skrótu na język polski, mianowicie BUZI — Bez Udziwnień Zapisu, Idioto. Zasada ta nie ma na celu obrażania nikogo, nie jest też stosowana wyłącznie w branży informatycznej. Chodzi o to, żeby nie komplikować niepotrzebnie rzeczy, w naszym przypadku kodu, tak aby każdy inny pracownik mógł bez problemu zrozumieć, o co chodzi. Tak już wspominałem wcześniej, w programowaniu jedną funkcjonalność możemy napisać na wiele sposobów. Dlatego warto pisać kod w jak najprostszy sposób. Oczywiście nie oznacza to, że mamy robić to za wszelką cenę. Najważniejsze to podejść do tego zdroworozsądkowo (zresztą jak do każdej zasady) i zawsze pamiętać, że nasz kod czytają też inni programiści.

SOLID

Solid dla każdego programisty jest słowem niemal świętym. Tak naprawdę to nie jest jedna zasada, lecz 5, a sama nazwa Solid pochodzi od pierwszych liter każdej z nich. Oto one:

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

Zasady te są ściśle powiązane z programowaniem obiektowym, więc chcąc dokładnie wszystkie je wyjaśnić, musiałbym najpierw wytłumaczyć Wam koncepcję programowania obiektowego. Dlatego lepiej będzie, jak wyjaśnię ogólne przesłanie płynące z tych zasad.

Przede wszystkim chodzi o tworzenie jak najbardziej specyficznych klas, tak żeby każda z nich specjalizowała się tylko w jednej rzeczy. Wtedy minimalizujemy konieczność dokonywania zmian w takim kodzie oraz ułatwiamy czytelność kodu.

Bardzo ciekawa jest również zasada otwarte — zamknięte, jej definicja brzmi mniej więcej tak: Klasy oraz funkcje powinny być otwarte na rozszerzanie i zamknięte na modyfikacje. Z pozoru brzmi to trochę sprzecznie, nie? Jednak wbrew pozorom jest to bardzo sensowne. Chodzi o to, żebyśmy mogli rozszerzać funkcjonalności klas oraz funkcji bez potrzeby modyfikacji ich kodu. Można to osiągnąć między innymi, bazując na abstrakcjach, a nie na konkretnych implementacjach.

Stosując zasady SOLID, jesteśmy w stanie pisać małe, czytelne klasy spełniające standardy programowania obiektowego.

Zasady niepisane

Niektóre zasady nie są jakoś oficjalnie spisane, mimo to zna je oraz stosuje większość programistów. Tutaj do głowy przychodzą mi dwie, najważniejsze zasady. Po pierwsze odpowiednie nazywanie zmiennych, klas oraz funkcji. Niestety zasada ta nie jest praktykowana w szkołach i uczelniach, nad czym bardzo ubolewam. Pewnie nieraz spotkaliście się z parametrami funkcji o nazwach x, y, a, b, c itp. Takie zmienne nic nam nie mówią, dlatego powinniśmy nazywać je w sposób opisowy, na przykład wysokoscWynagrodzenia. Odpowiednie nazewnictwo mocno poprawia czytelność kodu, ułatwiając tym samym wprowadzanie do projektu nowych pracowników.

Kolejną zasadę mógłbym nazwać: poprawiaj kod, gdziekolwiek jesteś. Smutna prawda jest taka, że kod dość szybko się starzeje, szczególnie widać to w większych projektach. Dlatego dobrym podejściem jest poprawianie starego kodu, przy okazji wykonywania w nim jakieś modyfikacji. Dobry programista nie powinien bać się zmian i chętnie usprawniać starsze moduły aplikacji, tak aby utrzymywać cały kod na możliwie najwyższym poziomie.

Słowo na koniec

Oczywiście to nie jest tak, że masz teraz usiąść i uczyć się tych wszystkich zasad na pamięć. Po prostu warto być świadomym ich istnienia. Po pewnym czasie sam zauważysz, że stosujesz je niemal automatycznie. Dodatkowo warto wiedzieć, że większość kursów programowania, z jakimi się spotkałem — chociażby kursy w Coders Lab, ukierunkowuje kursantów na te zasady już podczas samej nauki. Tak więc będą one dla Ciebie czymś naturalnym.

Dzięki za dzisiaj, było troszkę dłużej niż zazwyczaj, ale mam nadzieję, że nikogo nie zanudziłem. Wracam już za tydzień z artykułem, w którym wyjaśnię, co takiego robią usługi Google Play z perspektywy programisty. Do zobaczenia!

Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie do kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.

Poprzednie odcinki:

Artykuł powstał we współpracy z Coders Lab