Udržitelný vývoj

Některé skutečnosti si člověk uvědomí či plně docení až u projektů, které trvají několik let a vystřídá se na nich více lidí. Tento příspěvek je o tom, jak učinit takové projekty udržovatelné, tedy schopné odolat náporu času a zásahům programátorů.

Když jste na škole či pracujete na jednodušším projektu, tak je všechno krásné: začnete na zelené louce, projekt nějak uplácáte dohromady, aby více či méně fungoval, odevzdáte či hodíte na GitHub a hotovo. Jde se na další projekt. Tento přístup funguje do té doby, než začnete pracovat (či dokonce vedete) projekt, který má být vyvíjen mnoho let a na kterém pracuje více lidí. Každý z těchto lidí má svůj přístup k vývoji a vlastní úroveň znalostí a zkušeností. Ze začátku všechno klape, ale dříve či později se dostanete do stavu, kdy strávíte více času laděním a opravou chyb, které do projektu zavlečete s každou nově implementovanou vlastností, než užitečnou činností. Nejste si jisti, co některé části vyvíjeného systému dělají, protože odpovědný člověk váš tým dávno opustil. Něco nefunguje, a když se pokusíte zjistit proč, tak narazíte na funkci, která pouze vrací nějakou konstantu (např. false) s komentářem // TODO. Snažíte se pochopit a upravit cizí kód, ale jde to velmi ztuha, protože kód je napsán tak prasácky, že byste dotyčného nejraději nakopali do koulí. Stále máte pocit, že toto jste již řešili či opravovali, ale nejste schopni to nikde dohledat. Projekt se stane neudržovatelným a je zralý na kompletní přepis.

C'est la vie. A nebo, že by ne?

V tomto příspěvku bych se chtěl zaměřit na tři velmi důležité aspekty vývoje, které plně doceníte (a uvědomíte si jejich důležitost) až u takovýchto dlouhotrvajících projektů. Patří mezi ně dokumentace, testování a kvalita kódu.

Dokumentace

Strašák všech programátorů. Psaní dokumentace. Brr. Určitě jste se při pomyšlení na něco takového otřepali. Teď si představte, že máte použít/upravit kód, který není zdokumentovaný. Jak by se vám psalo ve vašem oblíbeném jazyce, kdyby k němu neexistovala dokumentace? Kdybyste se museli neustále dívat do kódu a zjišťovat, co která funkce dělá, co má za parametry a jaké záruky dává. Nehledě na to, že by chyběl vysokoúrovňový popis, jak to všechno funguje dohromady. Takže pevně věřím, že se shodneme, že dokumentace je velmi důležitá.

Nestačí, že je nyní vše ve vaší hlavě. Napsaný kód po vás může jednak převzít někdo jiný, např. když změníte práci či projekt, ale taktéž se k němu můžete vrátit za půl roku a přemýšlet, jak že to vlastně funguje. Možná si říkáte, že to, co jste vytvořili, se používá samo či že si vše budete za půl roku pamatovat. Není to pravda. Pokud váš program potřebuje specifická nastavení či kroky k jeho instalaci, sepište si je. V opačném případě pak za rok, kdy jej budete přesouvat na jiný server, si budete muset všechno vybavit či znovu dohledávat. A na něco určitě zapomenete.

Snažte se zdokumentovat vše, co děláte. Pokud jste napsali knihovnu, popište, jak ji nainstalovat či zakomponovat do build systému, jak se dá použít, co je v ní hotové a co zbývá udělat, jaké jsou známé problémy, jaká je její struktura a rozdělení do zdrojových souborů atd.

Udržujte si v projektu bázi znalostí (např. na privátní wiki). Když se ukáže, že něco nefunguje, popište proč. Když se vám něco podaří vyřešit, napište, co jste pro to udělali. Nejhorší je, když se o něčem s kolegy bavíte a vybavujete si, že daný přístup dříve nefungoval a tak jste jej změnili, ale nikdo již neví proč.

Psaní dokumentace je dovednost. Možná bych šel dál a dokonce řekl, že je to umění. Ať už píšete sebehezčí kód, pokud jej nezdokumentujete, tak jej buď nikdo nebude používat, nebo bude, ale ve skrytu duše vás bude proklínat. Zdokonalujte se v této dovednosti stejně, jako se zdokonalujete v psaní kódu.

Testování

Převzali jste po někom kód, který nemá testy? Vítejte v pekle. Do netestovaného kódu máte strach udělat změny, protože si nejste jisti, zda úpravou něco nepokazíte. Dokonce si ani nemůžete být jisti, že kód dělá v současné době to, co očekáváte. Časem se dostanete do stavu, že se pořád něco rozbíjí a opravou chyb strávíte většinu dne, takže to vypadá, že nic neděláte a že se celé dny flákáte.

Když naimplementujete novou funkcionalitu, přidejte na ní testy. Když opravíte chybu, přidejte na ní test. Přítomností testů si ověříte nejen to, že vše funguje tak, jak očekáváte, ale i zaručíte, že kdokoliv, kdo po vás bude kód opravovat, ponechá onu funkcionalitu funkční či nezavleče tu stejnou chybu, kterou jste opravili.

Mnoho programátorů vyvíjí kód tím stylem, že má vstupní data (např. soubor) a upravuje kód do té doby, než z danými daty funguje. Pak tato data přepíše jinýma a pokračuje ve vývoji tím, že opět kód upravuje tak dlouho, dokud nezačne s novými daty fungovat. Nakonec onen testovací soubor zahodí. Co ale v budoucnu, když někdo kód upraví? Jak si ověří, že stále funguje? Musí si vytvořit vstupní data a na všech program spustit ručně znovu. To je značně časově náročné a náchylné k chybám (opravdu se odzkoušelo všechno?). Mnohem lepší způsob je každá taková data či soubor implementovat jako test, který bude v repozitáři společně s kódem. Každý si tak bude moct ony testy spustit a ověřit, že vše stále funguje.

Je potřeba mít automatizované řešení. Nespoléhejte se na to, že programátoři testy vždy spustí. Chybovat je lidské a snadno se na to zapomene. Nahoďte si systém průběžné integrace, který po každém commitu systém přeloží, spustí na něm testy a v případě, že některý z testů neprojde, zašle upozornění emailem.

V nepolední řadě nezapomeňte, že existuje mnoho typů testů, z nichž každý se hodí na něco jiného. Jednotkové testy využijete při implementaci jedné komponenty (funkce, třída atd.) v izolaci. Integrační testy využijete na ověření, že komponenty lze propojit a fungují společně tak, jak očekáváte. Výkonnostními testy si lze ověřovat, že výkon vašeho systému je stále dostačující. A tak dále.

Kvalita kódu

Na tom, že kvalita kódu je velmi důležitá, se asi všichni shodneme. Proto je potřeba na ni dávat dobrý pozor. O kvalitním kódu jsem zde již psal a proto zmíním jen některé postřehy navíc, které s udržitelností projektu velmi úzce souvisí.

Dejte si opravdu záležet na návrhu. Nesnažte se hned implementovat první řešení, které vás napadne. Promyslete, co by daná změna znamenala a zda by nezpůsobila více problémů, než užitku. Zvažte jiná řešení. Diskutujte kód o ostatními. Nejhorší jsou frajeři, kteří když něco potřebují, tak si to prostě nakódí bez ohledu na to, kolik kódu rozvrtají a zda je to elegantní řešení z hlediska celkového konceptu. Typicky se jedná o studenty či junior developery, kteří si plně neuvědomují, co svými změnami mohou v důsledku způsobit a že déle trvající projekt se liší od školních projektů. Je potřeba jim vysvětlit, proč tento přístup nelze uplatňovat. Všichni se postupem času učíme a každý dělá chyby.

Snažte se dodržovat štábní kulturu. Doporučuji se v rámci projektu domluvit a dodržovat alespoň základní kódovací standard (jak odsazovat, kam přijdou závorky atd.). Usnadní to spolupráci. Pokud žádný standard nemáte, tak při úpravách alespoň dodržujte styl, který je v měněném souboru zavedený. Není nic horšího, než když se v rámci jednoho souboru mixují mezery s tabelátory, camelCase se snake_case a co řádek, to unikát.

Domluvte se na revizích kódu. Vaši kolegové si mohou všimnout něčeho, co jste nepostřehli. Pokud jste senior developer, určitě procházejte každý commit svých podřízených (studenti, junior developeři) a pište jim poznámky. Chybami se člověk učí. Pokud jste naopak student či junior developer, nebojte se klást otázky. Pokud se vám něco v některém commitu nezdá, zeptejte se. Ukažte, že kvalita kódu vás zajímá.

Pište kód tak, abyste na něj byli hrdí a nestyděli se za něj. Myslete na ty, kteří s vámi spolupracují a kteří po vás kód v budoucnu převezmou. Pro nás programátory platí, že kód je naší vizitkou.

Související příspěvky

Níže uvádím odkazy na dva z mých příspěvků, které s diskutovaným tématem velmi úzce souvisí.

• Důvody, proč psát jednotkové testy - Tento příspěvek je určen především programátorům, kteří zatím nevidí důvod, proč psát jednotkové testy.
• Vysoce kvalitní kód - Co je to vysoce kvalitní kód, proč je důležitý a na co si dát při jeho psaní pozor.