Jak pisać kod by po tobie nie przeklinali?

Długość życia kodu oraz programów jest długi. Powoduje to często, że osoby które zaczynały go pisać i znają go od podszewki nie prowadzą go do końca. Myślę, że każdy programista z dłuższym stażem dostał kod nad którym miał ochotę przeklinać ponieważ był nieczytelny, zagmatwany i praca z nim to była udręka. Dziś chciałbym się pochylić nad rzeczami które najczęściej wkurzają i jak nim zapobiegać by inni nie musieli po nas przeklinać.

Długi kod
Chyba nie ma nic gorszego niż projekt, który próbujesz zrozumieć i trafiasz na metody które liczą po kilkadziesiąt lub nawet kilkaset linijek. Jest to według mnie rzecz, która odrzuca od projektu na samym początku. Co z tego, że autor potrafił się w tym odnaleźć, skoro to nie on musi w nim teraz pracować. Dlatego podczas pisania kodu, starajmy się aby było on możliwie jak najmniejszy. Jeśli widzimy że coś możemy wydzielić i użyć w innym miejscu zróbmy to bez zastanowienia. Takie coś się zwróci w przyszłości z nawiązką.
Magic numbers
Kolejna rzecz, która potrafi przyprawić o ból głowy czyli pojawiające się nagle w kodzie jakieś liczby. Niech pierwszy rzuci kamieniem kto nie spotkał w kodzie wolnostojących liczb i zastanawiał się co one robią, po co i dlaczego akurat taka wartość. Czasami można znaleźć w takim kodzie informacje w komentarzu ale jest niebezpieczeństwo, że informacja tam jest nieaktualna. Dużo lepszym pomysłem jest umieszczenie takich liczb w stałych którym nadamy odpowiednie nazwy. Dużo lepiej wygląda takie coś
```
rows = ITEMS_NUMBER/ ITEMS_PER_ROW
```
Od czegoś takiego
```
rows =  50 / 4  
```
Kolejną zaletą jest łatwość zmiany takiej wartości jeśli występuje kilka razy w kodzie.
Brak testów
Tego chyba najbardziej brakuje podczas wchodzenia do nowego projektu kiedy nie znamy struktury i wszystkich zależności. Bez testów ciężko sprawdzić czy czegoś przez przypadek nie zepsuliśmy. Można powiedzieć, że wtedy błądzimy we mgle. Dobrze napisane testy nie tylko pomagają nam podczas tworzenia oprogramowania ale również ułatwiają dodawanie nowych funkcjonalności.
Brak Readme
Zanim zaczniemy dłubać w kodzie musimy postawić całe środowisko. Aktualnie gdy używamy w większości Dockera może to być skomplikowane i wtedy dobry plik Readme jest na wagę złota. Warto go pisać ponieważ znowu to co jest dla nas oczywiste nie musi takie być dla innych. Jeszcze gorszym przypadkiem jest nieaktualny plik, który został napisany na starcie projektu ale nie był aktualizowany a architektura zdążyła się już kilka razy zmienić. Może to poważnie spowolnić postawienie środowiska. Nie zaniedbujmy pliku Readme tylko aktualizujmy wraz z rozwojem aplikacji tak aby nowa osoba była w stanie na jego podstawie postawić nowy projekt
Niekompletne fixtures
No i na koniec coś co jest związane z poprzednim punktem a mianowicie fixtures czyli fałszywe dane. Jest to bardzo wygodna rzecz ponieważ możemy sobie w prosty sposób wygenerować poprawne dane dla naszej aplikacji. I wszystko jest dobrze o ile kod generujący fałszywe dane rozrasta się wraz z rozwojem naszej aplikacji i bazy danych. Jeśli tak się nie dzieje próba wygenerowania fixtures może się skończyć błędem i zostaniemy bez żadnych przykładowych danych. Dbanie o fixtures daje również poczucie bezpieczeństwa ponieważ nawet jeśli coś przekombinujemy podczas pisania kodu to możemy przywrócić sobie czystą bazę danych.

A wy coś byście jeszcze dodali do listy? Co was najbardziej denerwuje jak dołączacie do istniejącego kodu? Zastanawialiście się kiedyś co by można było poprawić by inni nie marudzili na nasz kod? Zapraszam do komentowania.