Již je to nějaký pátek co jsem ve firmě zavedl code review a za tu dobu mám zapsaných pár poznámek, které bych rád publikoval:
- úplně na začátku jsem měl snahu o čisté code review, ale s postupem času se více začalo jednat o pravidelnou programátorskou schůzku, kde je sem tam i "veřejné" code review. Důvody jsou asi dva - kvalitní code review vyžaduje přípravu a řekl bych, že délka přípravy celkem odpovídá výslednému efektu code review. Bohužel jsem vždy neměl pocit, že code review mělo ten výsledný efekt, který jsem očekával, takže postupně jsem i já sám do toho přestal dávat tolik času a energie. Dalším důvodem je pak nástroj Crucible, který jsme začali používat.
- současná podoba programátorské schůzky je asi tato: každý týden půl hodiny, kde probíráme změny v API, jaké koncepční změny se udály nebo teprve přijdou a samozřejmě probíráme i kód, který v pozitivním/negativním smyslu má cenu ukázat veřejně a nějak ho zhodnotit.
- všechny důležité a odsouhlasené věci je nutné vždy někde evidovat, protože hned druhý den si to nikdo nepamatuje. Navíc sem tam někdo chybí na schůzce, takže je potřeba toto publikovat pro všechny.
- schůzka má vždy jednoho moderátora
- procházení, komentování a veřejné ukazování zdrojových kódů je hodně o "sociálním cítění", o komunikaci, protože spoustu programátorů bere "svůj" kód za čistě svojí věc, navíc dost lidí není připraveno na veřejnou kritiku své práce. Vždy se tedy snažím před code review odmazat jakékoliv jména osob, aby hned na první pohled nebylo zjevné, komu daný kód patří. A musím prostě volit velice opatrný přístup, když něco/někoho chci kritizovat. Cílem těchto schůzek není někomu ukázat, že je špatný, ale ukázat možné chyby, problémy, které může dělat úplně každý. Tento bod hodně souvisí se složením týmu - dělal jsem v týmu, kde člověk mohl říci jakoukoliv kritiku, všichni to brali úplně v pohodě a všichni věděli, že jde hlavně o tým. Jiné týmy mají více individualistů, introvertů apod. a tyto věci tak dobře nefungují. To tak prostě je a zde je vidět, že vývoj není jen o technických znalostech, ale vůbec o schopnosti komunikace.
- programátorské schůzky mám často spojené se zaváděním nových věcí - nové konvence psaní kódu, nové API k použití apod. Pokud chci aplikovat nějaké nové pravidlo, tak musí být jasné a definované (ideálně bez výjimek) v jedné, dvou větách. Obrázky vše mnohem lépe vysvětlují. Jakmile je cokoliv složitějšího, úspěch je předem nemožný.
- pokud objevím nějakou chybu v mém kódu, která stojí za ukázání ostatním, tak ji vždy ukazuji - pokud se já snažím ostatním říkat, že něco mají špatně nebo mohli by mít lépe, pak musí všichni cítit, že každý dělá chyby (i já), a že je to naprosto normální. Jen je potřeba se toho vyvarovat do budoucna.
- pokud chci něco změnit v aplikaci resp. zavést nějaké nové pravidlo, tak se mi často vyplatilo, že jsem to sám v celé aplikaci upravil. Programátoři často bez přemýšlení kopírují kód a díky tomu se špatný kód šíří mnohem rychleji než ten dobrý.
1 komentář:
Myslím, že dělat code review ručně dává sice nejkvalitnější výsledek, ale dá se to dělat pouze v malém týmu, tak cca do 5 lidí.
My používáme na projektech Sonar. A obecně bych code review stavěl na automatizovaných nástrojích. Před Sonarem jsme používali Maven + PMD/FindBugs/Checkstyle + nějaké code coverage (Cobertura, EMMA). Ruční code review dělám jen občas, namátkově projedu komity ve VCS.
Zajímvý věci se dají najít i při refactoringu. Ale to už tam daný člověk nemusí být.
Okomentovat