Zasady dobrego “code review”

Zrzędzenia na tłumaczenia
Jako, że pojęcie code review pochodzi z czasów, kiedy programowaniem w naszym kraju zajmowali się nieliczni pasjonaci i wysokiej klasy specjaliści, do tego pochodzący z pokolenia, które dbało o swój rodzimy język, jest to nieliczne ze sformułowań z kręgu IT, dla których mamy swój rodzimy językowy odpowiednik, który nie razi – inspekcja kodu. I wszystko fajnie – tylko, że chyba nikt już o nim nie pamięta. Raz, że inspekcja to słowo niekoniecznie istniejące w słowniku współczesnych, znających więcej słów w języku angielskim, niż rodzimym. Dwa, że jednak kojarzy się negatywnie – z nadzorem, z kontrolą celem znalezienia uchybień. I z jednej strony – słusznie, bo wszak chodzi tutaj o dodatkowy poziom zabezpieczenia, upewnienia się, że wszystko zadziała “jak należy”. Z drugiej jednak, przy pracy zwinnej (“agile”), przy odchodzeniu od hierarchicznych systemów zarządzania, nie do końca to oddaje ducha tej czynności, aż prosi się o prostsze – przegląd kodu. I tego sformułowania będę się trzymał w dalszym wywodzie, posiłkując się jednakże anglosaską nazwą jako synonimem.

• • •

Niepokorny deweloper

Scrum to gra zespołowa, działa dobrze, jeżeli wszyscy przykładają się na równym poziomie, bo oczywistym jest, że na efekt pracy zespołu składają się ludzie go tworzący. Co jeśli jeden z członków zespołu deweloperskiego zaczyna przysparzać problemów, psując atmosferę? Nie chciałbym się w tym momencie rozpisywać nad przyczynami takiej sytuacji, może być ich bardzo wiele –  od znużenia projektem, wypalenie zawodowe, po kwestie relacji panujących między członkami zespołu czy też kwestie ich charakterów. Skupmy się na samej sytuacji, gdzie problemem staje się komunikacja oraz egzekwowanie zobowiązań od takiej osoby.

• • •