Odpowiedź na pytanie „czy warto być empatycznym” jest dość oczywista. Empatia, zarówno w życiu zawodowym, jak i prywatnym jest ważna i myślę, że nie ma potrzeby nikogo o tym uświadamiać. Empatyczne środowisko pracy zdecydowanie sprzyja komfortowi psychicznemu, a także może wpływać na tempo i jakość dostarczanych rezultatów. W tym wpisie podzielę się z Tobą moimi przemyśleniami co do istotności empatii w pracy programisty.

Dla kogo programujesz?

Przede wszystkim programujesz dla tego, kto Ci płaci. W tym przypadku mowa nie tyle o empatii, ile o uczciwości. Skoro ktoś za ten kod zapłacił, to prawdopodobnie oczekuje, że będzie on dobrej jakości. Przez kod dobrej jakości mam na myśli postawienie na sprawdzone technologie i rozwiązania. Płacąc za oprogramowanie, myślę, że nie chciał(a)byś, by Twój projekt stał się polem doświadczalnym dla programisty, gdzie testuje niecodzienne rozwiązania i egzotyczne technologie. Oczywiście nie należy tu popadać w drugą skrajność i wykorzystywać technologicznych staroci. Gdybym chciał nauczyć się nowej technologii lub wypróbować nowinkę techniczną, postawiłbym na prywatny side project i dopiero po zdobyciu doświadczenia rozważał wdrożenie zdobytej wiedzy w kodzie, za który ktoś mi płaci. Chyba że Twoje miejsce zachęca do eksperymentowania. Wtedy nieskorzystanie z okazji to wręcz grzech!

Kod tworzysz dla użytkownika docelowego aplikacji. Aspektami, które są związane z kodem i mają wpływ na użytkownika to wydajność aplikacji, jej dostępność oraz doświadczenie użytkownika. Nie każdy użytkownik ma czas czekać 10 sekund, aż aplikacja się załaduje. Umiejętności obsługi aplikacji użytkowników są różne. Również nie każdy użytkownik tak samo dobrze widzi, słyszy i rozpoznaje kolory.

Kod tworzysz również dla swoich kolegów i koleżanek z pracy. Mowa tu nie tylko o tych, z którymi pijesz kawę na przerwie. Weź pod uwagę też tych, których być może nigdy nie poznasz. Nawet jeśli nie zostaniesz w danym projekcie na lata, git blame doskonale pamięta, kto przygotował dany kod. Branża IT wciąż jest na tyle małym rynkiem, że może się to zemścić w najmniej oczekiwanym momencie 😉

Warto zastanowić się kilka razy nim wypchnie się na mastera/maina jakiegoś algorytmicznego potworka, dzikie funkcje mapujące, czy inny kod przyprawiający o ból głowy twórcę i każdego, kto go czyta. Nawet jeśli owiniesz ten kod w funkcję o perfekcyjnej nazwie, to pewnego dnia ktoś będzie potrzebował coś w nim zmienić. Wtedy komuś, kto będzie siedział obok tego nieszczęśnika, który dostąpił tego wątpliwego zaszczytu, mogą zwiędnąć uszy.

Jeszcze gorzej, jeśli takiego potworka opublikujesz w jakimś projekcie open source. Abstrahując od tego, że taki kod może nie przejść code review, to publikując paździerz w publicznie dostępnym repozytorium, możesz wystawić sobie piękną laurkę. Projekty open source w wielu przypadkach nie płacą swoim maintainerom. Tym bardziej warto postawić na empatię, gdy pracujemy w projekcie, gdzie ktoś za darmo poświęca czas na rozwój projektu.

Na sam koniec zostawiłem jeszcze jedną osobę, dla której piszesz kod. Jesteś to Ty z przyszłości. Kiedyś usłyszałem, że jeśli patrzysz na swój kod sprzed roku i nie stwierdzisz „co za gówno”, to znak, że czas popracować nad swoim rozwojem. Osobiście nie jestem aż tak krytyczny, ale coś w tym jest. Dlatego też myślę, że warto dać z siebie 100% i maksymalnie ułatwić pracę przyszłemu sobie. Jeśli pracujesz z danym fragmentem kodu, to istnieje spora szansa, że w przyszłości naprawianie i rozbudowa go przypadnie Tobie. Ostatnim czego chcesz, to sprzątanie min, które sam sobie zostawiłeś jakiś czas temu.

Nieempatyczny kod

Nieempatyczny kod, mówiąc krótko, określiłbym jako kod, z którym sam nie chciałbym pracować. Pierwszym z grzechów, jakie składają się na nieempatyczny kod to kod nieczytelny. Wyobraź sobie nazwy zmiennych funkcji i klas, które nic ci nie mówią, tony if-ów, pętli i gęstą sieć zależności, od których zaczyna boleć głowa. Często nawet komentarz w kodzie nie poprawia sytuacji. Zresztą komentowanie nieczytelnego kodu również dalekie jest od idei empatycznego kodu. Praktyki programowania takie jak SOLID, DRY, YAGNI czy KISS nie wzięły się znikąd. Za wieloma dobrymi praktykami programowania stoi właśnie empatia.

Nieempatyczny kod to też taki ze wspomnianymi już minami. Przez minę mam na myśli błędy i pułapki w kodzie pozostawione intencjonalnie. Taką pułapką może być na przykład celowo pozostawiony błąd w kodzie. Może to też być niestabilny test lub test z niepoprawną asercją. Jeszcze gorszy przypadek, to celowo pominięty w testach fragment kodu. Daleki jestem od wyznawania idei 100% code coverage. Jednak pozostawiając istotny fragment kodu bez weryfikacji w postaci testu, dorzucamy kolejną minę do naszego codebase-u. W końcu może to też być „TODO fix later” lub „TODO do it better” zostawione w kodzie tylko po to, by po kilku latach je usunąć. Zachęcam również do walki z podejściem, że „ktoś to naprawi”. Zawsze, gdy w głowie pojawia mi się myśl, żeby odpuścić jakiś prosty fix czy dodanie małych usprawnień przypomina mi się jeden z klasyków polskiego YouTube.

Jeśli zostawiasz w kodzie błąd, którego jesteś świadom(a), to zostaw komentarz, informację, cokolwiek. Może to być wspomniane już TODO, ale z kontekstem, opisem problemu i linkiem do ticketa w issue trackerze. Może to być nawet test oznaczony jako skipped lub pusty test suite. Cokolwiek wskazującego, że w danym miejscu w kodzie można spodziewać się problemów, jest lepsze niż nic. Nie zachęcam jednak do tworzenia kodu jakości godnej pana Wiesia z Blok Ekipy. Świadomie zaciągnięty dług technologiczny jest okej, ale klepanie kodu po linii najmniejszego oporu już nie.

Zatem czym jest empatyczny kod?

Tu również można by odpowiedzieć krótko, empatyczny kod to kod, do którego nie pasuje opis z wcześniejszej części tego artykułu. Pisząc empatyczny kod, warto zacząć od oczywistości, czyli czytelnych nazw zmiennych, funkcji i klas. Empatyczny kod to kod pozbawiony skomplikowanych zależności, zgodny z dobrymi praktykami, takimi jak wspomniane już SOLID, KISS i DRY. Taki kod może też korzystać ze wzorców projektowych, ale w sposób uzasadniony i odpowiedzialny. Empatia w programowaniu to także konsekwencja, stosowanie jednolitego stylu, konwencji i rozwiązań w kodzie.

Empatyczny kod to kod przetestowany. Nie wystarczy jednak sam fakt istnienia testów. Testy powinny być stabilne, szybkie, proste w rozbudowie i utrzymaniu, a także faktycznie testować dany fragment kodu. Testuj nie tylko główne ścieżki, ale też przypadki brzegowe, możliwe błędy i inne przypadki zasługujące na sprawdzenie ich testem.

Empatyczny kod to kod udokumentowany. Możesz pomyśleć o dodaniu dokumentacji dla kluczowych elementów systemu. Rozważ również udokumentowanie kluczowych komponentów i aspektów systemu. Szczególnie użyteczne będą diagramy, możesz w tym celu wykorzystać np. diagramy przygotowane w Mermaid. Znacznie ważniejsze jednak to odpowiednie udokumentowanie zmian dodawanych do repozytorium z kodem. Każdy commit dodany do repozytorium zawiera message. Zadbaj o to, by zawierał on wszystkie niezbędne informacje.

Podsumowanie

Bardzo chciałem uniknąć narzekania jacy Ci programiści są źli i niedobrzy. Moim celem było dołożenie cegiełki do budowy projektów pełnych empatycznych programistów i programistek. Mam nadzieję, że ten wpis wzbudził w Tobie przemyślenia i refleksje. Jeśli tak, to zachęcam do udostępnienia go, gdzie uważasz za stosowne. Daj znać w komentarzu, czy empatia w kodzie jest dla Ciebie ważna i czym dla Ciebie jest empatyczny kod!

Materiały dodatkowe i źródła

• SOLID, KISS i DRY
• Wzorce projektowe – czym są i dlaczego warto je znać?
• Komentarze w kodzie
• Testy jednostkowe FIRST
• Mermaid – Diagrams as a Code
• Coding with Empathy blog
• How Empathy Can Make You a Better Software Engineer
• Empathy-Driven Development: How Engineers Can Tap into This Critical Skill
• Top 10 Best Practices For Empathetic Coding
• From Good to Great: The Power of Empathy in Programming
• just add an if

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!