Blog

Aplikacja jaka jest każdy widzi. Ale co jest pod spodem? Jak to jest, że w niektórych projektach pracuje się przyjemnie, a w innych… no cóż, lepiej zmienić pracę na kamieniołom. Jedno trzeba powiedzieć sobie jasno i wprost. To nie Klienci, Product Ownerzy, Product Managerzy, Kierownicy czy Testerzy robią bajzel w kodzie. To my sami – programiści, developerzy, koderzy. Jak sobie pościelisz tak się wyśpisz, albo raczej jak sobie nakodzisz tak sobie będziesz pracował.

Wychodząc od tego, zastanówmy się jakie są nasze największe grzechy? Jakie jest 10 praktyk hańbiących developera?

1. Mój kod moją twierdzą

Mój kod, mój kod, mój bardzo wspaniały kod. No właśnie. Dość często czujemy osobisty związek z naszym kodem. Niby nie ma w tym nic złego, ale… czasem nie kończy się to ciekawie. Szczególnie, jeżeli nie dopuszczam nikogo do mojego kodu. Kto mi tu będzie bruździł i jeszcze, odpukać, refaktoryzował? Przecież ja i tylko ja wiem, jak to działa, i jak ma być napisane. Czy w takich warunkach można stworzyć dobry produkt? Oczywiście, że można, ale takim działaniem odcinamy cały przepływ informacji oraz wiedzy w organizacji. Nikt nie przyjdzie z dobrym pomysłem usprawniającym kod, nikt też nie nauczy się czegoś dobrego od autora. Dzielenie się kodem jest tak naturalne i oczywiste, że wydawałoby się, że nie ma o czym pisać, a jednak ciągle zdarzają się osoby, które swój kod traktują z większym namaszczeniem i sekretem niż własną bieliznę.

2. Nie commituję kodu do repozytorium

Pochodna wcześniej opisanego grzechu. Mój kod moją twierdzą, więc nie wrzucę go do firmowego repozytorium. Przecież ktoś mógłby ukraść moje genialne rozwiązania. Albo nie daj bóg, ktoś by się czegoś nauczył i wygryzłby mnie z mojej ciepłej posadki. Mój kod zostaje na mojej maszynie! KROPKA… Chyba nie muszę mówić, jak skrajnie głupie i nieodpowiedzialne jest takie postępowanie. Co jeśli Twój komputer się zepsuje? Co jeśli pójdziesz na urlop, a w kodzie będzie trzeba zrobić poprawkę? Na pewno chcesz, aby dzwonili do Ciebie z firmy w środku urlopu? Co jeśli złamiesz rękę i przez pół roku nie będziesz dostępny w firmie? Takie postępowanie jest bardzo nierozsądne i nieprofesjonalne, zarówno w stosunku do firmy – bo możemy nawet niechcący postawić firmę w bardzo nieciekawej sytuacji – jak i w stosunku do samego siebie, sabotując swój wolny czas. Czas, który powinien być czasem relaksu i odpoczynku.

3. U mnie wszystko działa

Wiadomo, u programisty zawsze wszystko działa. Dlaczego działa? Bo ma na swojej maszynie wszystko, co potrzeba. Zainstalowane wszystkie potrzebne biblioteki i narzędzia. Wszystkie o odpowiednich wersjach, których mieszanka idealnie współgra – niczym u alchemika. Firewall odpowiednio skonfigurowany (a czasem nawet wyłączony), konto użytkownika ma odpowiednie uprawnienia (a nierzadko pełne prawa admina lokalnego) i dostęp wszędzie tam, gdzie ma mieć dostęp. Dlatego też u programisty wszystko działa. Problem pojawia się, jak ktoś chce przenieść aplikację na inną maszynę. Wtedy zaczynają się schody. Bo node jest w innej wersji, bo IIS jest inny, bo admini poblokowali porty i jest milion innych powodów, dlaczego tam nie działa – a u mnie i owszem.

No właśnie… może zamiast kupować koszulkę „dziwne, u mnie działa”, zainwestować pół godzinki dziennie, aby zbudować sobie środowisko – inne niż developerskie – na którym będzie się buildowało rozwiązanie na podstawie tego, co jest w repozytorium kodu i uruchamiało podstawowy zestaw testów. Takich nawet prostych smoke-ów. Nie trzeba wiele, nie trzeba zaczynać od wielkiego rozbudowanego CI/CD. Na początek wystarczy prosty automat, ale niech działa na innej maszynie. Wtedy okaże się, ile jest wart kod w repozytorium – czy naprawdę da się z niego zbudować rozwiązanie bez potrzeby angażowania programisty. To oszczędza bardzo dużo nerwów i stresu, gdy trzeba na szybko wydać wersję, a w czasie kiedy uruchamiają się smoke testy, można iść na kawę. Robota się sama robi.

4. CTRL+C, CTRL+V, czyli metoda Copy’ego Pejsta

Proste i szybkie narzędzie do generowania kodu. Skoro już coś podobnego zostało napisane w innej części systemu, na szybko skopiuję to i wkleję: gotowe, commit, DONE. No niezupełnie. Nikt nie płaci programistom wierszówki, nie płaci od linii kodu. Płaci się za myślenie, za to, że kod jest napisany tak, że ma ręce i nogi. Stosując metodę „Copy’ego Pejsta” idziemy po prostu na skróty, a to najczęściej kończy się źle. Co jeśli w kodzie, który został skopiowany, jest błąd? Właśnie powieliliśmy ten błąd na wiele różnych miejsc w systemie. Fajnie by było, gdyby podczas poprawiania tego błędu, można było odszukać wszystkie jego kopie i zaaplikować poprawkę. Są nawet narzędzia, które wyszukują takie duplikaty, ale z ręką na sercu, kto wyszukuje duplikatów kodu przed zaaplikowaniem poprawki? A może lepiej by było nie kopiować kodu. Może lepszym rozwiązaniem byłoby zastanowienie się, czy to, co chcemy skopiować lepiej byłoby uwspólnić? Może też to, że kod wydaje się taki sam jest złudzeniem, bo rozwiązuje inny problem i podobieństwo jest przypadkowe? Polecam zaznajomić się z zasadą DRY – don’t repeat yourself. W 99% kopiowanie kodu jest złe i przynosi szkodę.

5. Brak wcięć – brak formatowania kodu

Niby niewielka rzecz, co tam jakieś wcięcia i spacje. W szale kodowania czasem się zapomina o tym, że kod nie tylko musi działać, ale i wyglądać tak, aby był czytelny. Warto poświęcić tę minutę lub dwie, aby sformatować cały ten tekst tak, by był łatwo czytelny dla WSZYSTKICH w zespole, a nie tylko dla autora. Co to znaczy czytelny? Dla każdego języka programowania są pewne ogólnie przyjęte zasady, których warto się trzymać. Oprócz tego każdy zespół jest w stanie zbudować własne, spójne zasady. Tych zasad należy się trzymać.

Warto sobie uświadomić, że programowanie to głównie czytanie kodu, więc postarajmy się, aby to, co wychodzi spod naszych palców wyglądało tak, że chce się czytać. Niektóre języki programowania wprost wymagają odpowiedniego formatowania, bo to jest część składni. Używający ich programiści nie mają takiego problemu. Jeśli jednak pracujesz w języku, gdzie białe znaki nie mają znaczenia, to wiedz, że nie mają znaczenia dla kompilatora. Dla osoby, która będzie to czytała, ma ogromne znaczenie. Wiedz również, że osobą, która to będzie czytała będziesz również Ty.

Za tydzień kolejna porcja hańbiących praktyk, tymczasem czekam na Wasze komentarze.

Przeczytaj część drugą