Přikázání vývojářského procesu

Motivací k sepsání textu je mi především fakt, že jak rosteme a hledáme lidi do našeho týmu, setkávám se s postupy i z jiných pracovišť. Často s postupy, které jsem považoval za vyhynulé. Bylo to nepříjemné překvapení, jaké vývojářské postupy jsou stále běžnou praxí (bože, chraň nás od FTP nahrávání kódu). I přes veškerá rozpočtová omezení, na která čas od času každá vývojářská společnost narazí, je několik přikázání, bez kterých se vývoj prostě obejít nemůže.

Přikázání první: GIT

Verzování projektu v gitu je povinnost a samozřejmost. Neexistují nevýhody, z využití gitu lze jedině těžit. Mezi hlavní výhody patří:

• verzování kódu,
• zálohování kódu,
• týmová spolupráce,
• navázané procesy na nahrání kódu - automatizované deploye,
• mnohé další.

A přesto lze nalézt případy, kdy pomalé nahrávání kódu přes FTP na produkční server slouží jako hlavní cesta, jak spustit nový kód. Při chybě se nedokážete rychle vrátit do původního stavu, nahrávání je pomalé a protokol není dostatečně bezpečný.

Přikázání druhé: stage server

Ano, pro každý produkční web, o který se staráme, máme připravený samostatně (paralelně) běžící stage server. Pro vybrané projekty připravujeme dokonce i třetí dev prostředí. Veškerý kód před nahráním na živý server plný návštěvníků je kontrolován a schválen i na stagi. Námitka, že dochází ke zpomalení nasazení, je oprávněná. To pro nás představuje velmi malou cenu za to, že máme mnohonásobně větší jistotu, že nasazený kód bude fungovat.

Přikázání třetí: kontrola kódu

Už jsem zmínil, že git může sloužit pro zjednodušení týmové spolupráce i pro spouštění scriptů. My využíváme obojí. Veškerý vlastnoručně napsaný kód prochází kontrolou Coding Standards. Tím získáváme jistotu, že i po příchodu dalšího vývojáře k projektu, nebude mít žadný problém se čtením kódu po předchůdci. Dodržování domluvených standardů je investice, která se v budoucnosti mnohonásobně vrací.

Merge/pull request

V různých verzovacích nástrojích se využívají oba výrazy, princip je stejný. Pokud chce vývojář, který přidává nový kód, aby byl kód schválen (a nasazen) vytvoří tzv. merge request. Česky bychom to mohli nazvat "požadavek na sloučení". Pointou je, že máme kód kontrolován dalším vývojářem.

Přikázání čtvrté: deploy není hračka

Automatizace nástrojů pro deploy (nahrání kódu) na produkční prostředí svádí často k tomu, že vývojáři "mačkají červené tlačítko" jak diví a nahrávají kód do produkce, jak se jim zlíbí. Správný release management zachovává štábní kulturu. U vysoce navštěvovaných webů dodržujeme okna s menším vytížením, neprovádíme deploy X-krát za den. 

Je to proces, ne nahodilé umělecké dílo

O programování se říká, že je to umění - musíte mít talent, chuť a dobře napsaná aplikace/web dokáže zaujmout davy. Ale z dlouhodobého hlediska je dodržování pravidel tou hlavní cestou ke spolehlivému výsledku, který podpoří váš business dlouhodobě a systematicky, aniž by vás při každém novém požadavku polil studený pot.

Zaujal vás náš proces vývoje kvalitního kódu? Řešíte neustále problémy s kvalitou a vaši vývojáři si neví rady jak projekt posunout ještě o kousek dál? Napište nám - rádi vám poradíme co s tím.