Jak využít GitLab merge requesty při revizi kódu

Věřím, že revize kódu (code review) je nedílnou součástí vývoje. Pokud tento termín ještě neznáte, jedná se o vzájemnou kontrolu kódů programátory mezi sebou. Používá se jako efektivní opatření ke zvýšení kvality produktu a zefektivňuje celý proces vývoje. V Ackee nám tento přístup pomáhá v unifikaci kódu, což jinými slovy znamená, že v našem kódu nejsou kvalitativní výkyvy v závislosti na kvalitě a senioritě vývojářů. V tomto článku se proto budu soustředit na metody zlepšení práce prostřednictvím revize kódu přes merge requesty v GitLabu, což je ekvivalent k pull requestům, pokud používáte Github.

Ještě než se dostanu ke způsobu provádění revize kódu, zkusme si společně představit, co by se mohlo stát, pokud bychom tuto důležitou fázi ignorovali.

Rozmanitá struktura vývojářského týmu

Projekty, kterými se v Ackee zabýváme, obvykle vyžadují 1-3 vývojáře. Je jasné, že v jakémkoli vývojářském týmu najdete lidi s různou úrovní odborných znalostí i schopností. Z toho důvodu existují i příslušné názvy pozic - vývojář iOS / Android / Backend úrovně junior, middle a senior. To samozřejmě nutně neznamená, že kód napsaný juniorním vývojářem má horší kvalitu než kód od seniora. Jisté však je, že každý programátor má jiný styl psaní kódu. Často se tím pádem stává, že je pro někoho jiného než autora obtížně číst kód aplikace, kterou nepsal.

Důvody mohou spočívat v nedostatku znalostí, nedostatku spánku, nedostatku kofeinu, možná v přemíře kreativity či motivace, rozdílnosti v mozkové struktuře či zvláštnostech charakteru a tak dále. V neposlední řadě také ve faktu, že k mobilním technologím lidé utíkají z různých odvětví vývoje softwaru a tedy i od různých programovacích jazyků a stylů.

Proč se tedy nepokusit tyto rozdíly překonat? Revize kódu je dobrý začátek!

Co se stane, pokud neprovedete revizi kódu

• Každý vývojář píše „osobní“ kód pro „osobní“ použití. To by mohla být výhoda, pokud vývojář buduje svůj vlastní projekt, aniž by musel spolupracovat s jinými vývojáři. V ostatních případech to pak většinou neocení klient, který bude muset utratit více peněz a času na odhalení tajemství, která se skrývají v řádcích onoho kódu.
• Ostatní členové týmu nemají úplnou představu o kódu, který projekt obsahuje.
• V projektu je několik částí kódu, které nikdo na Zemi (vyjma autora) nikdy neviděl a možná ani neuvidí.
• Nekvalitní kód pravděpodobně zůstane v tomto stavu nadlouho, ne-li navždy.
• Nikdo není zodpovědný za kód ostatních a někdy ani za ten vlastní.
• Pro členy týmu je obtížné získávat zkušenosti a zlepšovat se.
• Špatný kód v testovací fázi kope.
• Špatný kód má tendenci se kupit. Dříve či později to povede k mnoha obtížím s pokusy o jeho detekování a opravu.
• Juniorní vývojář je vystaven riziku, že tíha odpovědnosti za všechny problémy světa spadne právě na něj.
• Jeden a ten samý problém řeší různí vývojáři různě. Takže neexistuje nic jako znovupoužitelnost kódu.
• Provádět refaktoring po třech měsících vývoje projektu, který žije si svým vlastním životem, může být velmi složité.

Je tedy vidět, že pokud zanedbáme provedení revize kódu, vyhlídky nejsou nejpříjemnější.

Obecné zásady revize kódu

• Revize kódu je nedílnou součástí vývoje – to si vytiskněte a dejte si to na zeď, abyste si to pamatovali.
• Revize kódu se provádí přes malé logicky kompletní části kódu, jako například funkce, úloha, bug fix aj.
• Pouze kód, který prošel revizí, je poslán na testování.
• Všichni vývojáři projektu provádí revizi kódu bez ohledu na jejich senioritu (junior vývojáři by také měli zrevidovat kód zkušenějších specialistů na middle a senior úrovni).

K tomu, abyste mohli revizi kódu provádět efektivně, potřebujete nástroj, který vám umožní efektivní spolupráci nad zdrojovými kódy. My v Ackee používáme GitLab a proto se právě jemu budeme ve zbytku článku věnovat.

GitLab merge request jako nástroj k provádění revize kódu

Merge request je určen pro začlenění kódu z jedné větve do jiné. Hlavními parametry merge requestu jsou (parametry specifikujeme při vytváření):

• zdrojová větev,
• cílová větev,
• název,
• popis,
• přiřazený uživatel.

Jak postupovat při práci s merge requesty

1. Napište kód a proveďte push do oddělené větve.
2. Pro hlavní vývojovou větev vytvořte merge request. Přiřazenému uživateli a osobám uvedeným v poli pro popis a v komentářích bude e-mailem posláno oznámení o vytvořeném merge requestu. Pro uvedení vývojáře byste měli do pole pro popis vložit symbol @.
3. Počkejte, než dojde k přijetí či odmítnutí s komentáři o nezbytných opravách.
4. Zúčastněte se diskuze o opravách. (GitLab umožňuje odpovídat na komentáře)
5. Proveďte opravu.
6. Pushněte změny do své větve.
7. Otevřete nový merge request, pokud se ten poslední zavřel, v opačném případě práce pokračuje v původním merge requestu.
8. Podejte zprávu o provedených opravách prostřednictvím komentářů k merge requestu nebo jiným způsobem.

Komu přidělit merge request

Existují různé možnosti odvíjející se od počtu lidí pracujících na projektu a od jejich úrovně odbornosti. Takže pokud jste jediným vývojářem v týmu, přidělte merge request sami sobě. Konec konců můžete i ve svém kódu najít chyby, pokud se o to pokusíte.

Jinak si zkuste najít parťáka, dalšího vývojáře, který dělá na svém vlastním projektu, a nabídněte mu vzájemnou revizi kódu.
Pokud jste dva vývojáři pracující na společném projektu, přidělte merge requesty vzájemně jeden druhému. A pokud na projektu pracuje tři a více vývojářů, můžete si vybrat:

• Proveďte to jeden po druhém.
• Najděte jakékoli dva vývojáře, kteří jsou blázni do merge requestů, a přidělte jim je.
• Přidělte všechny merge requesty jednomu vývojáři a provádějte revizi kódu jednou denně se všemi členy týmu.
• Jakákoli jiná možnost,

Revizi kódu můžete provádět na začátku a na konci pracovního dne či kdykoli na požádání. Tým může rozhodnout, kdy je na revizi kódu vhodná doba, nejdůležitější je však neustálá spolupráce mezi členy týmu.

Provádíte-li průběžnou revizi kódu

• Problémy v kódu naleznete a opravíte hned.
• Každý člen týmu (nejen autor) je zodpovědný za kvalitu kódu.
• Předávání znalostí probíhá rychleji a efektivněji.
• Junior vývojáři se rychleji učí.
• Na testování odchází pouze dobrý kód.
• Špatný kód se nekupí.
• Kód nového vývojáře není hrozbou pro celkovou kvalitu kódu.
• Vývojáři znají dobře nejen svůj vlastní kód, ale i kód v rámci celého projektu.
• Finální produkt má dobrou kvalitu.