Juniors

Dobre praktyki, dzięki którym staniesz się lepszym developerem

10 października 2018 Patryk Woziński

Czym tak naprawdę są dobre praktyki? To rozwiązania wiele razy sprawdzone u ludzi, którzy programują dłużej niż część z nas żyje. Ludzi, którzy zjedli zęby na Cobolu, wybuchali śmiechem na widok kolejnego NullPointerException i napisali więcej CRUDów niż jesteśmy sobie w stanie wyobrazić . To oni doskonale wiedzą jakie zasady, jakie nawyki są w stanie ułatwić nam pracę. Książki napisane przez legendy, dotyczące zasad programowania obiektowego, które dominowało już w latach 80-tych są ponadczasowe, a ich lektura naprawdę może uczynić nas lepszymi programistami, inżynierami. Dlatego w tym artykule zebraliśmy kilka najważniejszych praktyk.

Patryk Woziński. PHP Developer w ZnanyLekarz. W 2014 roku rozpoczął pierwszy staż na stanowisku PHP Developera. Przez te lata zdobywał doświadczenia w różnych firmach, głównie w Trójmieście. W 2017 roku przeniósł się do Warszawy, by rozwijać swoje umiejętności. Od marca 2018 roku jest Software Developerem w Docplannerze (w Polsce portal znany pod nazwą ZnanyLekarz).

I’m not a great programmer; I’m a good programmer with great habits — Kent Beck

W tym wpisie poruszę temat fajnych praktyk związanych z zarówno samym programowaniem, jak i umiejętnościami miękkimi, które warto rozwijać i doskonalić.

Spis treści

Code Review

Proces przeglądu kodu uważam za coś absolutnie obowiązkowego. Żaden kawałek kodu nie powinien trafić nigdzie poza Twoim lokalnym branchem bez code review. Nieistotne jest to czy w procesie bierze udział jeden, czy czterech developerów. Ważne, by kod, który napisałeś został zrecenzowany i — co bardziej istotne — zrozumiany przez inne osoby. Nie każdy potrafi wczuć się w rolę programisty piszącego konkretny feature, ale ogólna weryfikacja poprawności nowych kawałków aplikacji powinna być naturalnym krokiem w fazie developmentu.

Warto więc otwierać code review po pierwszym sensownym commicie, który dodaje już jakąś wartość. Dzięki temu inni developerzy będą widzieli to, w jaki sposób myślisz i rozwijasz swój branch. Dodatkowo będzie im znacznie łatwiej zrozumieć problem, który próbujesz rozwiązać, gdy dasz im możliwość „próbkowania” kodu w mniejszych porcjach.

Zobacz też

Juniors Jak rozwijać się tak, by czuć się spełnionym? Rozwój programisty

Nigdy nie akceptuj też kodu, którego nie rozumiesz. Nie chodzi tutaj o dogryzanie koledze z zespołu/projektu, tylko o to, że jedną z ważniejszych cech code review jest wspólna nauka. Czytający kod uczy się od piszącego i vice versa. Akceptując zmiany, których nie jesteś w stanie zrozumieć — sam stawiasz się w przegranym świetle. To Twój „zielony approve” będzie współodpowiedzialny za to, że nowe zmiany wywalą środowisko i będą powodowały błędy. Jeżeli masz problem z weryfikacją poprawności kodu — poinformuj o tym autora, usiądź z nim i porozmawiajcie o fragmentach, które są dla Ciebie trudne. Jeżeli tak jest, to prawdopodobnie feature został napisany w niepoprawny sposób.

Kiedyś seniorem nazywaliśmy autora pięciu linijek kodu, których nikt nie rozumiał. Dzisiaj to nie przejdzie — kod musi być jak dobra książka , czyli zostać napisany w taki sposób, by innym podczas czytania spędzało się miłe chwile. 😉 Swoje dwa grosze do tematu dodał Mathias Verraes, który stwierdził, że merge to odpowiedzialność całego zespołu i nie powinno do niego dojść w sytuacji, gdy któryś z developerów nie zgadza się, lub nie jest w stanie zrozumieć zmian.

Kolejną dobrą praktyka związaną z code review jest branie ich na poważnie. Wszyscy wiemy, że zajmuje to chwile, ale to część naszej pracy. Zanim rozpoczniesz pracę nad nowym zadaniem — spróbuj przejrzeć powiadomienia z GitHuba, GitLaba czy innego BitBucketa i poświęć trochę czasu na przejrzenie kodu, do którego weryfikacji zostałeś przydzielony. W ten sposób usprawnisz pracę innych osób, które szybciej otrzymają feedback. Ba, dodatkowo jeżeli pracujecie agile, to będziesz miał świetny update swojej wiedzy na temat postępu prac kolegów i koleżanek z zespołu.

Testy, testy, testy — temat wałkujemy wszyscy od dawna, niektórym wychodzi on już bokiem. Jednakże, gdy pull request dotyczy funkcjonalności, która jest stosunkowo istotna i będzie wykorzystywana w wielu miejscach aplikacji — warto zastanowić się, czy autor nie powinien ich dopisać. Oczywiście wtedy, gdy nie pracuje w podejściu TDD. Dopisanie Unit testów to chwila pracy, a może uratować nasz tyłek, a później utrzymać go w całości, gdyby ktoś postanowił wprowadzać zmiany w naszym kodzie.

Kultura refaktoringu

Nieodłączną częścią pracy programisty jest refaktoring istniejącego już kodu. Uwielbiam zasadę skautów: „Zawsze zostawiaj obozowisko czystsze niż je zastałeś” — znamy ją wszyscy doskonale, każdy związany z oczyszczaniem kodu o tym mówi, ale jak jest w rzeczywistości?

Temat czystego kodu, porządkowania go jest bardzo problematyczny do uzasadnienia przed działem biznesowym w firmie. Nikt przecież nie będzie chciał płacić za coś takiego, bo nie wnosi to najczęściej produktowych korzyści.

Refaktoring warto zaczynać tam, gdzie akurat się znajdujemy, delikatne poprawianie nazw zmiennych, przesunięcie i likwidacja niepotrzebnych złożoności w kodzie. To bardzo subtelne, a poprawiające czytelność kodu zmiany. Sprzątajmy tylko dookoła siebie, nie wchodźmy w las. Jeżeli widzimy, że jakiś większy kawałek aplikacji sprawia problemy lub mógłby być rozwiązany w inny (oczywiście lepszy!) sposób, to zmierzmy wpływ zmian w nim i skonwertujmy na wartości biznesowe. Przyspieszenie ładowania elementu X to poprawa konwersji oraz mniejsza liczba użytkowników, którzy odstąpią od korzystania z modułu z uwagi na wydajność. Warto mierzyć też częstotliwość edycji danego fragmentu systemu. Świetnym narzędziem w PHP do takich operacji jest Churn. Pokazuje on informacje o klasach, które są często zmieniane, oraz to jak wysoka jest ich złożoność cyklomatyczna. Doskonałym argumentem jest nawet wskazanie samej częstotliwości edycji klasy — oznacza to, że wielu developerow często ją odwiedza, a nieczytelna klasa to klasa, której utrzymanie jest droższe. Bonusowym argumentem dla nas jest sugestia, że klasa może być zbyt obszerna i może łamać zasadę Single Responsibility — każda klasa powinna mieć tylko jeden powód do zmiany. Jako, że zmian tutaj mamy dużo, to zaczynamy czuć code smell.

Refaktoring to także świetna, jeśli nie najlepsza forma nauki o tym, jak działa aplikacji. Aby zmienić jakiś kawałek kodu należy najpierw go zrozumieć, a także zrozumieć kontekst, w ramach którego on funkcjonuje. Każda kolejna akcja porządkowania bałaganu w systemie to wartość dodana w postaci nauki i wiedzy o aplikacji. Dodatkowo, aby zacząć większe akcje refaktoryzujące niezbędne będą testy. Z jednej strony możemy wiele nauczyć się z samej analizy testów, a z drugiej pisząc je — utrwalamy sobie w głowie sposób działania konkretnych klas i zależności między nimi. Bajecznie!

Dema technologiczne

W ZnanymLekarzu funkcjonują regularne dema technologiczne. To kolejny bardzo fajny sposób nauki i poszerzania wiedzy na temat aplikacji. Spotkania takie różnią się od zwykłych dem produktowych tym, że prowadzone są na tematy dotyczące rozwiązań technologicznych w całym produkcie. To tutaj developerzy, administratorzy i inni członkowie teamu IT prezentują swoje najświeższe dokonania i odkrycia. Zarówno osoba, która przygotowuje prezentacje jest w stanie lepiej zobrazować sobie osiągnięte cele, jak i odbiorca może dowiedzieć się, co i w jaki sposób dzieje się w innych zespołach. Zakres obowiązków tych teamów jest dla słuchacza często zupełnie obcy, więc TechDemo przybliża mu wiedzę o wyzwaniach prelegenta oraz o ewentualnych punktach styku projektów, na których oboje pracują. Wartością dodaną z tego jest także łatwiejsza możliwość rotacji developerów w zespołach, gdy zajdzie taka potrzeba. TechDemo często mają dużo luźniejszy charakter niż dema produktowe, dzięki czemu każdy czuje się swobodny w zadaniu pytań, co skutkuje ciekawymi dyskusjami nad rozwiązaniami.

StackOverflow od drugiej strony?

StackOverflow, to miejsce do którego najczęściej zaglądamy w momencie, gdy napotykamy barierę podczas developmentu i potrzebujemy pomocy. Najczęściej kończy się na wyszukiwaniu podobnych problemów, bo przecież jeśli Twojego problemu nie było na Stacku, to znaczy, że on nie istnieje. Moim zdaniem warto stworzyć konto i dodać do obserwowanych wybrane tagi, w których czujemy się mocni. Późniejszym krokiem jest wyszukiwanie tematów, w których moglibyśmy pomóc. Oczywiście wiele pytań jest zadawanych bez przemyślenia i brakuje tylko moderatorów ze słynnego forum Elektroda, którzy zamknęliby takie wątki, ale czasami znajdziemy bardzo ciekawe problemy. Pomagając innym użytkownikom sami się uczymy, często są to przypadki, których nie spotykamy tak często w swoim miejscu pracy, także jakkolwiek by to nie brzmiało: „poszerzamy horyzonty”.

To wszystko działa podobnie jak kata w karate (ciekawostka: coding dojo), czyli seria powtarzanych ćwiczeń dążących do perfekcji. Czasami błędy i problemy użytkowników powtarzają się, a także bywa, że sami je napotkaliśmy w czasie pracy, ale przez pomaganie utrwalamy sobie sposoby rozwiązań. Dzięki temu, gdy później podejdzie do nas młodszy programista, to będziemy w stanie naprowadzić go na rozwiązanie dużo szybciej, a także zasugerować mu wiele różnych opcji.

Aktywne uczestniczenie w projektach Open Source

Rozwój aplikacji z otwartym i dostępnym dla wszystkich kodem, to kolejny sposób na zdobycie doświadczenia, które na co dzień w pracy może okazać się na wagę złota. Podczas kontrybuowania innych (open source-owych) projektów możemy nie tylko wiele się nauczyć, ale także pokazać się jako eksperci w konkretnych rozwiązaniach. To namacalny dowód na to, że rozumiemy i znamy zewnętrzne narzędzia. Dodatkowym plusem jest możliwość wdrożenia zmian, na których nam zależy i które rozwiążą nasze problemy. Korzystny jest także wkład w zmniejszenie czasu realizacji nowej wersji projektu, który wykorzystujemy na co dzień.

Praca profesjonalnego developera związana jest z nieustanną nauką zarówno nowinek technologicznych, jak i umiejętności miękkich. Słowa Kenta Becka idealnie opisują prawdziwego specjalistę — ma on świetne nawyki, które czynią go zauważanym w społeczności.