V poslední době je hodně moderní vést nové projekty agilní metodikou. Tento přístup nám, jako vývojářům umožňuje tvořit malé, iterativní změny v kódu, kterými postupně budujeme finální produkt. Často tyto malé kousky kódu vkládáme do takzvaných Pull Requestů, neboli PRek, jak jim někteří vývojáři rádi říkají.
Pull Request obsahuje v podstatě určitou změnu oproti zdrojovému kódu (nehledě na to, jak bude malá), která má za úkol implementovat nějakou feature, případně opravit bug. Takováto změna se ovšem okamžitě nepromítne do kódu, ale zůstane nejprve “viset” v Pull Requestu. I kdybychom měli v týmu samé profesionály, dělili vývoj na větve (release, development, atd.), není moc dobrý nápad sypat nový kód rovnou do repozitáře.
Občas se stává, že některý vývojář udělá nevědomky chybu (běžně nazývané jako “bugy”) a bez řádné kontroly by tato chyba putovala rovnou do produktu, kde bychom ji pak museli složitě lovit. Zkušenosti a praxe nás naučili, že je nejlepší, když změny v kódu zkontroluje ještě někdo jiný. Tím značně redukujeme chybovost a množství nasekaných bugů.
Proto vznikly Pull Requesty. Jako vývojáři vytváříme nové Pull Requesty ve svém oblíbeném verzovacím systému (beztak všichni používáme Git) a sypeme do nich změny zdrojového kódu, které chceme poslat do repozitáře. Tím naše práce končí, ačkoliv se změny ještě vůbec nedostaly k cíli. Nyní je totiž na řadě další vývojář, který musí přijít, manuálně kód ověřit, zda je v pořádku a následně kliknout na tlačítko “Approve & Merge”, které změny aplikuje.
Tahle sranda není zadarmo a sežere nemalé množství času a pozornosti. Vývojáři na to věčně nemají čas, protože nemůžete vinit těch pár seniorních lidí ve firmě, kteří jsou zahlceni požadavky, že nekontrolují kód do posledního puntíku. Stává se, že to prostě odklikají a kód nekontrolují, ale tím dávají prostor pro přemnožení bugů.
A tady přichází náš technický tip: Automatizujte!
V posledních letech se hodně rozmáhají CI/CD pipeliny (Continuous Integration/Continuous Delivery = samo se to zabalí, otestuje a nasadí). Překvapivě částí takovéto pipeliny může být i nástroj pro statickou analýzu kódu, jakým je například SonarQube! Integrace takových nástrojů je až dětsky jednoduchá, takže není důvod nedat šanci.
Samozřejmě to není samospásné řešení, ale může to dost pomoci. Obzvlášť pokud si člověk v tom nástroji napíše pár svých vlastních pravidel pro analýzu kódu.
Pokud máte vlastní Github/Bitbucket/AzureDevOps/GitLab účet a repozitář, nastavíte to asi za 5 minut. Stačí otevřít https://sonarcloud.io/, zalogovat se, propojit repozitář a voilá! Nové Pull Requesty budou nyní validovány i pomocí tohoto nástroje. Samozřejmě se nemusíte omezit jen na SonarQube. Na trhu jsou spousty nástrojů pro statickou analýzu kódu. Namátkou třeba PullRequest nebo Codacy. Můžete si vybrat.
Buďte ovšem opatrní. Jsou to sice šikovné nástroje, ale nikdy by neměly plně nahradit kontrolu jiného vývojáře. Existují způsoby, jak psát kusy kódu, které při statické analýze svítí zeleně, ale ve skutečnosti jsou pekelně nebezpečné. Můžete se insiprovat mým malým experimentem: https://github.com/apelttom/java_and_sonarQube/pulls
To je vše. Přeji dobrý lov.
