Jeszcze do dość niedawna pojęcie czysty kod było mi obce, ale po przeczytaniu książki o tym samym tytule autorstwa Roberta C. Martina (która jest adresowana przede wszystkim do programistów Javy), zrozumiałem że czas zmienić swoje podejście do pisania. Po zmianie podejścia, promień światła padł na moją twarz, tak jakbym wyszedł z jaskini na zewnątrz. Zrozumiałem jaki byłem zacofany i należy dokształcić się bardziej, aby osiągnąć jako taki poziom.
Nie będę prezentował żadnego kodu, ale zacytuje szereg wypowiedzi które należy pamiętać podczas tworzenia kodu, bo inaczej można wejść znowu w kupę.
Zasady Becka dot. prostego kodu
- przechodzi testy,
- nie zawiera powtórzeń,
- wyraża wszystkie idee projektowe zastosowane w systemie
- minimalizuje liczbę encji, takich jak klasy, metody, funkcje itp.
Już w pierwszym punkcie widać, że wciąż mam opory to zmiany starego podejścia, acz nie jest tak źle, staram się testować kod, jeżeli jest nowy, bo stary niestety nie jest przygotowany do testów jednostkowych, bo niestety został źle zaprojektowany na samym początku.
Wielki dąb rośnie z małego żołędzia.
Zasada 5S
Pięć japońskich słówek które odpowiadają porządkują własną pracę, ale także zespołu:
SEIRI |
Organizacja |
SEITON |
Porządek |
SEISO |
Czystość |
SEIKETSU |
Standaryzacja |
SHUTSUKE |
Dyscyplina |
Dotyczy to nie tylko kodu, ale także otoczenia wokół nas, a tutaj także mamy wiele do ponarzekania na siebie, ale także innych, bo nie znam żadnego programisty który spełniałby te 5 zasad.
Niezależnie od tego jak czysty jest dom,
bałagan na biurku psuje dobre wrażenie.
Porządkowanie starego kodu
Jednym z zasad jakie sobie postanowiłem, to zmarnowanie czasu na poprawienie kodu aplikacji które są najczęściej używane przeze mnie i przez innych. Bo sam zauważyłem że jeżeli rozumiałem chaotyczny kod wcześniej, to teraz gubię się po zmianie podejścia. Głównie gdy kod jest stary i wychodzący jeszcze z pod ręki innego programisty.
Czy zrobiliśmy wszystko,
aby zostawić obozowisko czystsze,
niż je zostawiliśmy.
Kilka prawd o czystym kodzie
Zdolność do odróżnienia czystego kodu od niedbałego
nie oznacza, że wiemy, jak pisać czysty kod!
To prawda, pisanie czystego kodu nie nauczymy się po przeczytaniu jednej książki, należy obserwować innych programistów np. dzięki takim miejscom jak GitHub czy stosowaniu standaryzacji pisania kodu jakim jest PSR.
Ale lepiej starać się pisać czysty kod, niż nie pisać go w ogóle.
Czytanie kodu powinno wywoływać uśmiech na twarzy,
podobnie jak dobrze skomponowana muzyka czy
dobrze zaprojektowany samochód.
W moim zespole raczej innym nie przynosi to uśmiechu, może dlatego że nie rozumieją obiektowego programowania. Bo nagle coś co zrobiło się proste w kodzie, zrobiło się także tajemnicze, bo doczesny kod znikł, a nadal daje ten sam wynik jak wcześniej. Wtedy to daje uśmiech ale mi z dobrze wykonanego zadania 🙂
Zły kod kusi do powiększania bałaganu!
To prawda i nie kusi, ale jest jak rak, który napada na kolejne komórki, którego później trudno wyleczyć bez chemicznej terapii. Właśnie jestem na etapie takiej terapii w swoim projekcie, gdzie mając za zadanie dodanie nowych usług, okazało się że zarażony kod nie pozwolił sprawne dodanie usług. A naprawa kodu, pokazała tylko jak daleko sięga zarażony kod i konieczna jest terapia szokowa.
Zmiany przeprowadzone w złym kodzie zwykle prowadzą do tego,
że staje się on jeszcze gorszy.
Nie do końca zgadzam się z tym cytatem, ale rozumiem o co chodzi. Chodzi o to że każda kolejna rzecz, prowadzi do tego że prawdopodobieństwo wywołania nieoczekiwanego błędu jest większe niż wcześniej.
Czytanie kodu na głos, jest dobrym sposobem na lepsze zrozumienie kodu lub poznanie kontekstu kodu.
Jest to jeden z moich ulubionych narzędzi pracy w zespole. Wystarczy komuś przeczytać kod, nawet jeżeli nie specjalizuje się w twojej dziedzinie, a szybciej znajdziemy rozwiązanie na nurtujące nas pytanie, lub nawet znajdziemy błędy w kodzie lub źle nazwane zmienne, metody i własności.
Programowanie lingwistyczne
Na koniec coś co wyciągnąłem z Confitury chyba z 2015 roku. A mianowicie chodzi o przestrzeń nazw. Że należy nazywać klasy, metody zgodnie z zasadami gramatyki języka natywnego.
[słowo -> znaczenie -> reguły]
[ kontekst ]
Przykład, rezerwacja biletu:
Rezerwacja. dodajProdukt (ilość, rabat)
Podmiot.Orzeczenie (dopełnienie, przydawka)
Obiekt.Metoda (parametr, extParametr)
rezerwacjaBiletu.kupBilet (1, [10,5613]) [rabat: 10%, userId: 5613]
Czyli naszą klasą jest rzecz ogólna, która jest rzeczownikiem, ale unikając tzw. worków, uniwersalnych klas gdzie można wrzucić wiele metod.
Metody są czynnościami jakie wykonuje się, więc metoda o nazwie bilet, czy kasaBiletowa nie nadaje się jako nazwa takiej funkcji. Dlatego warto przeczytać, taki kod aby bez problemu i błędów językowych mogli użyć takiej klasy w innym miejscu kodu.