Programista na haju. O testach, czystym kod oraz over-engineringu.

Programista na haju :)

Programista na haju.

Programiści to tacy ludzie, którzy dużo o siebie dbają: zdrowa dieta, sport, okazjonalna pizza, bywająca często największą używką w życiu programisty. Dobrze wiedzą, że w zdrowym ciele mózg lepiej funkcjonuje 🙂

Dlaczego więc w tytule mowa o programistach „na haju”? Chodzi tutaj o przyjemność, o produkowanie endorfin, nasz wewnętrzny system nagradzania za dobrze wykonana pracę i zwiększanie poczucia szczęścia. Endorfiny są uzależniające, zawsze chcemy ich więcej. A oto kilka sposobów na ich produkcję.

 

Programista na haju. Uzależnienie od testów

Jest taka statystyka w świecie IT – code coverage czyli pokrycie kodu testami. Spotkałam się z opiniami, że jeśli mamy 50% pokrycia kodu testami, to wciąż za mało. To tak jakbyśmy nie mieli nic. Jest to statystyka, która zawsze wzbudza dużo emocji w dyskusjach, a podnoszenie wartości tej statystyki może okazać się uzależniające. Im więcej tym lepiej – będzie się czym pochwalić. Dodatkowo mamy wzmocnienie efektu przez naprawianie testów, które czyni je znów zielonymi. Ogólnie w kwestii ciągłego testowania i zwiększania ilości testów pomagają również narzędzia programistyczne np. zaznaczające kod, który jest objęty testami, a nawet na żywo sprawdzające wynik testów i oznaczający go kolorami (Live Testing Visual Studio).

 

Buildy

Kolor zielony oznaczający powodzenie podjętej akcji mamy również w buildach i releasach czyli elementach DevOps. DevOps i procesy nim opisane, definicje buildów i releasów służą produktom i zespołom w misji szybszego wytwarzania i dostarczania oprogramowania. Ułatwiają życie zespołowi wytwórczemu, dokumentują i automatyzują procesy. Jak największa automatyzacja oraz zielone wskaźniki buildów są uzależniające. To moje osobiste uzależnienie 😉

 

Czysty kod

Największe autorytety programowania promują czysty kod. To wiele technik i zasad poprawiających re-używalność i czytelność kodu. Jednak niektóry z nas posuwają się moim zdaniem odrobinę za daleko w tym dążeniu do ideału. Jedna z reguł mówi o wydzielaniu funkcjonalności do osobnych metod. Pojedyncza odpowiedzialność metody i jej dobre nazewnictwo zwiększają czytelność i testowalność oraz zmniejszają potrzebę zmian. Ale czasami podział sam w sobie staje się celem. Jak największa granularność staje się bodźcem do produkcji endorfin. Za to niekoniecznie pomagając w czytelności kodu i zdecydowanie utrudnia utrzymanie. Zwłaszcza w zespole gdzie nie każdy przestrzega tak rygorystycznie zasad podziału metod.

 

Over-enginering

Podobnym do czystego kodu problemem może się okazać over-enginering, czyli podejście „zróbmy to lepiej”, przygotowane na wszystkie ewentualności całego świata. Albo opcja druga: „zróbmy to w mniejszej ilości linijek kodu” (zoptymalizowanej liczbie linijek kodu). Over-enginering  we wszystkich odmianach jest uciążliwy na dłuższą metę, zwłaszcza w zespołach z wysoką statystyką praktykantów. A jest jeszcze gorzej gdy staje się uzależnieniem.

 

Podsumowanie

Podążanie za zasadami, ułatwianie pracy zespołu, podążanie za trendami, ciągle doskonalenie. Wszystko to jest jednym z wyznaczników dobrego programisty. Uzależnienia, produkcja endorfin, zwykłe zadowolenie z pracy. Wszystko to pozwala nam programistom przeżyć dzień, brnąć dalej. Przetrwać rok lub kilka w nudnym niesatysfakcjonującym projekcie.

Jednak jeśli przekroczymy granicę zdrowego rozsądku, staje się uciążliwością lub nawet problemem, nie tylko dla nas samych, ale również dla zespołu, z którym współpracujemy i dla nowych ludzi, którzy muszą mierzyć się z naszym kodem. Często zapominamy o tym, że na końcu każdego łańcuszka pokarmowego jest klient płacący za naszą pracę. Nawet jeśli pracujemy nad własnymi projektami po godzinach, wtedy zazwyczaj klientem jest nasz sen.

Niektóre religie mówią o szukaniu złego środka. Ale o takich poszukiwaniach mówi się teoretycznie. Gdy skupiamy się na jakiejś myśli, celu, często tracimy poczucie środka. Przestroga i rada dla nas jako ludzi współpracujących z innymi pełnymi pasji programistami: zwracajmy uwagę na niepokojące sygnały. Rada dla nas samych: zatrzymajmy się czasami na chwilę, aby opowiedzieć innym o swojej pracy i posłuchajmy gdy mówią „chyba się zagalopowałeś”.

Bądźmy dla siebie nawzajem „sanity check”!

 

programista

Szybki kontakt

Billennium Warsaw
pokaż kontakt

Billennium Kuala Lumpur
pokaż kontakt

Billennium Lublin
pokaż kontakt

Billennium Łódź
pokaż kontakt

Billennium Olsztyn
pokaż kontakt

Billennium Bytom
pokaż kontakt

Billennium Pune
pokaż kontakt

Billennium New York
pokaż kontakt