10.02.20225 min

Muhammad Rahmatullah IDSenior Backend Engineer

Poznaj piramidę 8 podstawowych zasad kodowania

Zamiast kierować się zasadą YAGNI na początku pracy, zastosuj zasady piramidy, dzięki czemu nie wpędzisz się w dług techniczny.

Poznaj piramidę 8 podstawowych zasad kodowania

Istnieje wiele procesów, które muszą zostać zakończone i kwestii technicznych, które należy rozwiązać, aby stworzyć w pełni funkcjonalną aplikację. Jedną z rzeczy, które możemy zrobić, aby nasze aplikacje działały poprawne i były szybsze jest wdrożenie poniższych zasad kodowania.

Oto odwrócona piramida podstawowych zasad kodowania wykonana przeze mnie, dzięki długoletniemu doświadczeniu w pracy w software house’ach. Miałem tam do czynienia z wieloma aplikacjami, które były trudne do utrzymania. 

Musiałem stwierdzić, co jest nie tak i dlaczego określam te aplikacje jako “trudne do utrzymania”. Jeśli jesteśmy przyzwyczajeni do implementowania zasad kodowania w naszych aplikacjach, to z dużym prawdopodobieństwem jesteśmy w stanie zidentyfikować czy aplikacja jest zła z perspektywy bazy kodu.

Oto zasady kodowania, do których stosowałem się w większości tworzonych przeze mnie aplikacji.


Spraw, że zadziała

Pierwszą zasadą przed wdrożeniem jakiejkolwiek zasady jest to, że najpierw musimy się upewnić, że nasza aplikacja działa. Jaki jest sens posiadania wygodnej w utrzymaniu bazy kodu, jeśli użytkownik nie może skorzystać z aplikacji?

Użytkownika nie będzie obchodziło, czy aplikacja jest zbudowana na supernajlepszym serwerze i stworzona z wykorzystaniem najlepszych zasad kodowania. Będzie go obchodziło tylko to, czy aplikacja działa, czy też nie.

Jeśli tak, możemy zacząć pracować nad wdrożeniem dowolnych zasad kodowania, które pasują do naszych aplikacji.


Nie będziesz tego potrzebował

Głupi ja. W czasach, gdy byłem jeszcze młodszym inżynierem oprogramowania, zachowywałem nieużywany kod, komponenty, czy komentarze tylko dlatego, że myślałem, że być może kiedyś się przydadzą.

Ale prawda jest taka, że nie używałem tego kodu przez wiele tygodni, a nawet miesięcy.

Po pierwsze, musimy pozbyć się z naszej głównej bazy nieużywanego kodu, a jeśli bardzo chcesz go zachować, bo może będziesz go potrzebował później, to po prostu odpowiednio skonfiguruj system kontroli wersji.

Jeśli usuniemy jakiś kod z naszej bazy, w systemie kontroli wersji zostanie zachowana historia i będziemy mogli łatwo wrócić i wtedy skopiować/wkleić stary kod, nie przechowując go cały czas w naszej bazie kodu.

Umówmy się, im większa baza kodu, tym większy wysiłek potrzebny do utrzymania.


Nie komplikuj, głupku

Tak, dobrze słyszałeś. Nie pogarszaj sprawy.

Jeśli możemy uczynić proces prostszym, to po co się trudzić, aby uczynić go bardziej skomplikowanym?

Najprostszym benchmarkiem jest to, czy nasze zmiany zmniejszają obciążenie serwera, czy też go obciążają, a także to, czy nasze kody są możliwe do utrzymania przez innych, czy też nie.

Jeśli nasz kod nie przeszedł benchmarku, oznacza to, że nasza baza danych jest zbyt skomplikowana i wymaga refaktoryzacji. Możemy łatwo refaktoryzować kod używając opensource’owej analizy krytycznej kodu lub bibliotek code smell, które automatycznie zasugerują nam zmiany w kodzie.


Nie powtarzaj się (DRY)

Czy kiedykolwiek potrzebowałeś akcji lub procesu, który musi być wykonany przed każdą akcją, np. musimy się upewnić, że użytkownik jest już zalogowany, zanim uzyska dostęp do jakichkolwiek stron użytkownika?

class HomeController 
  def index
    is_user_login?
  end
  
  def profile
    is_user_login?
  end
  
  private
  def is_user_login?
    redirect back if user.login == false
  end
end


Jak widać w powyższym kodzie, staram się wywołać is_user_login?, w każdej akcji kontrolera i powinno to być zoptymalizowane, na wypadek zmiany nazwy metody lub zmiany logiki itp.  Taka metoda będzie nieefektywna, ale możemy coś z tym zrobić.

Możemy stworzyć konstruktor / warstwę pośrednią / before action, które będą wywoływać funkcję is_user_login? za każdym razem, gdy któraś z funkcji zostanie uruchomiona.

class HomeController 
  before_action :is_user_login?
  
  def index; end
  
  def profile; end
  
  private
  
  def is_user_login?
    redirect back if user.login == false
  end
  
end


Możesz zobaczyć różnicę po refaktoryzacji kodu, kod będzie łatwiejszy w utrzymaniu i bardziej czytelny.


Czysty kod

Założę się, że słyszałeś już wiele razy o zasadzie czystego kodu, a ja chcę Ci powiedzieć, że czysty kod jest raczej zasadą ogólną.

Pierwszą zasadą czystego kodu jest zawsze tworzenie jasnego i zwięzłego kodu z wyraźną intencją, na przykład, gdy tworzymy funkcję, metodę, moduł lub nazwę zmiennej.

Nazwa powinna przedstawiać wartość lub logikę jako całość. Nie zapomnij o przestrzeganiu istniejących konwencji kodowych, ponieważ każdy język programowania działa na własnych zasadach.

Nie jestem w stanie opisać ich wszystkich w tym artykule, ale jeśli chciałbyś zgłębić temat, to gorąco polecam Ci przeczytanie tej książki "Clean Code: A Handbook of Agile Software Craftsmanship" Roberta C. Martina.


Stojąc na ramionach olbrzymów

Wykorzystaj standardy branżowe i sprawdzone technologie zamiast własnych standardów.

W wielu źródłach można znaleźć informacje o tym, jak stworzyć boilerplate przy pomocy niektórych narzędzi, jaka jest najlepsza metoda kodowania i z jakim narzędziem itd. itp.

Gorąco polecam stosowanie się do istniejących konwencji, najlepszych praktyk i standaryzacji, ponieważ nie powinniśmy budować żadnego rozwiązania na własnych zasadach, chyba że daje nam to przewagę nad konkurencją.


Zasada skautów

Jaka jest jedna z głównych przyczyn spadku produktywności u programistów?

Tak, zgadza się. Główną przyczyną zmniejszającej się wraz z upływem czasu produktywności jest sytuacja, w której musimy utrzymywać lub kontynuować rozwój projektu zbudowanego z niechlujnego kodu.

Oczywiście będziemy musieli poświęcić więcej czasu, gdy będziemy mieli do czynienia z czyimś niechlujnym kodem lub nawet naszym niechlujnym kodem (wstydźmy się).

Jak więc sobie z tym radzić? Możemy wykorzystać “Zasadę skautów”. Jak powiedział wujek Bob w swojej książce: „Zawsze zostawiaj obóz czystszy, niż go zastałeś”.

Tak więc za każdym razem, gdy musimy rozwijać nowe funkcje lub utrzymywać istniejące, powinniśmy dodać jakieś ulepszenie do naszej bazy kodu. Nie musi to być poważna zmiana, możemy wykonać również drobne poprawki. Przykładem może być zmiana nazwy zmiennych, usunięcie białych znaków, sprawienie, że kod będzie miał takie same wcięcia itp.


Zrób to szybko

Po uporaniu się z wyzwaniem, jakim jest uczynienie naszego kodu łatwiejszym w utrzymaniu, zoptymalizowanym i czytelnym, możemy skupić się na przyspieszeniu działania naszej aplikacji.

Może to być np. optymalizacja indeksowania bazy danych, modyfikacja architektury, czy strategia pamięci podręcznej.

I wreszcie, znakiem rozpoznawczym dobrego rzemieślnika jest zrozumienie, że refaktoryzacja kosztuje czas i lepiej jest zbalansować wszystkie zasady współbieżnie. Nie kieruj się zasadą YAGNI już na samym początku pracy.

Mam tu na myśli stosowanie tych zasad w tym samym czasie w każdej iteracji / kluczowym momencie pracy, ale przeznaczanie minimum czasu/uwagi na elementy znajdujące się na dole piramidy.

W przeciwnym razie skończysz z ogromnym długiem technicznym, zanim jeszcze zdasz sobie z tego sprawę.



Oryginał tekstu w języku angielskim przeczytasz tutaj.

<p>Loading...</p>