Jak vyvíjíme Shopio?

Tento příspěvek je trochu techničtějšího rázu, než je na našem blogu obvyklé. Rád bych vám v něm přiblížil některé zajímavé postupy, které používáme při vývoji Shopia.

Práce na Shopiu je rozdělena na dvě části – práce na samotné platformě a práce na úpravách pro konkrétní zákazníky. Abychom mohli zákazníkům dodávat úpravy v odpovídajícím čase a za přijatelné ceny, potřebujeme mít pro úpravy stabilní základ, na který se můžeme spolehnout. Proto je pro nás kvalita základního kódu velmi důležitá.

Společné vlastnictví kódu

Pokud pracujete ve větší společnosti, určitě to znáte – kusy kódu, o kterých nikdo netuší jak fungují, a jejich úprava je za trest. Takové kusy kódu na Shopiu prakticky nemáme. Vzhledem k tomu, že w3w je velmi svobodná firma, tak potřebujeme, aby mohl kdokoli kdykoli pracovat na jakémkoli kusu kódu (někdo může být na cestách, nebo mít doma výpadek internetu a někdo ho musí zastoupit). Základním kamenem společného vlastnictví kódu jsou coding standards – tedy způsob formátování zdrojového kódu, pojmenovávání tříd, proměnných a souborů.

Nepoužíváme žádný ze zavedených coding standardů, ale pro naše potřeby jsme si upravili Zend coding standard tak, aby nám zbytečně nepřidělával práci, ale aby nám pomáhal. Při zavádění coding standardů je důležité, aby s jeho zavedením souhlasili všichni a byl výsledkem shody. Jedině v tom případě ho budou všichni svědomitě používat a bude přínosem. Nám se to podařilo, a tak dokonce často nastávají vtipné situace, kdy člověk najde chybu v kódu, udělá git blame a zjistí, že ji napsal sám. Po čase se totiž z pohledu do kódu prakticky nedá poznat, kdo ho napsal. A to je základ společného vlastnictví kódu.

Problém coding standardů je, že kontrolovat je nikoho nebaví. Je to otravná práce. Ale nebyli bychom vývojáři, kdybychom si nedokázali pomoct skriptem! Takže coding standardy za nás hlídá phpcs. Automatizované kontroly nasazujeme postupně, jak postupně opravujeme standardy. Pokud si na běžícím projektu vymyslíte standard a začnete ho kontrolovat pomocí phpcs, nejspíš to bude epic fail. Proč? Protože každé spuštění vrátí Found 1000 violations, too many violations. Je potřeba to dělat postupně od nejzásadnějších věcí, které dodržujete už teď a postupovat k detailům. A jednou za čas udělat big bang a přepsat něco napříč projektem. Za dobu, co nám phpcs běží, se počet pravidel poměrně dost rozrostl a myslím, že zachytí většinu běžných chyb.

Git

Před časem jsme celou naší codebase zmigrovali z SVN do gitu. Zpětně to bylo velmi dobré rozhodnutí, protože nám umožnilo zavést množství různých postupů, které nám pomáhají zlepšovat kvalitu kódu. Při vývoji Shopia používáme upravený Github workflow. Veškeré úpravy probíhají v oddělených větvích a poté jsou pomocí pullrequestů integrovány zpět do hlavní vývojové větve. Pullrequesty (PR), pokud nevíte o co se jedná, jsou vlastně požadavky na zaintergrování nějakého kódu. Vytvořením PR říkáme „žádám tě, abys kus kódu, který je ve větvi XY, přidal do větve ABC“. A to je přesně situace, kdy je ideální čas na code review.

Pullrequesty a Code review

Základní pravidlo: Nikdy si nikdo nemergne vlastní PR.

I kdyby to mělo být přejmenování jedné proměnné. Za každý kus kódu v hlavní vývojové větvi jsou tak vždy zodpovědní dva lidé – ten, kdo to vytvořil, a ten, kdo ho mergoval. Před mergnutím PR si tak dotyčný kód vždycky pořádně zkontroluje, když je za něj zodpovědný.

Prvním krokem review je kontrola samotného kódu – v rámci PR na Githubu je na to samostatná záložka, ve které jsou zobrazené změny v kódu, které PR přináší (diff). U menších změn většinou stačí změny v kódu jen přečíst a pro sebe si je vysvětlit. Tím člověk odhalí většinu zjevných chyb – špatně pojmenované třídy a proměnné, nesmyslné konstrukce atp. Jakmile při review narazím na něco, u čeho si řeknu „co vlastně tohle dělá?“, tak tomu dám chvilku, a pokud to nepochopím, tak přidávám komentář, že je třeba kód přejmenovat, přestrukturovat nebo aspoň doplnit komentář. Díky tomu se nám daří mít v hlavní větvi minimum kódu, který by byl nepochopitelný. A to nám dál pomáhá ve společném vlastnictví kódu.

Kontinuální integrace

Martin v rámci své bakalářky (doporučuji k přečtení) pro w3w zprovoznil CI server Jenkins, ten nám umožňuje automatické kontroly jak běžících projektů, tak vývojových větví. Pro každou větev beží v Jenkinsu build, který zkontroluje PHP/JS coding standardy, zkontroluje, jestli PHP/JS/twig/SASS neobsahuje syntaktické chyby (lint) a spustí testy. Nedávno jsme také zprovoznili přímé napojení na Github, takže se nám automaticky buildují pullrequesty a přes API se označují. Situace, kdy člověk pushne na Github, chvilku počká a u githubu se mu objeví zelená fajfka, že build proběhl bez chyb, je super!

Párové programování

Čas od času narazíme na problém, který je tak velký, že si s ním člověk láme hlavu a vůbec se nikam neposouvá. V praxi se ukázalo, že než se celý den trápit sám, tak se vyplatí pozvat kolegu, ať jde programovat se mnou.

Rozdíl mezi párovým programováním a „zeptáním se kolegy“ je zásadní. Ptát se jednou za čas není efektivní – kolegu rušíte z jiné práce, musí přerušit to co dělá, začít se soustředit na váš problém, pochopit ho a pak poradit. Při párovém programování si oba vyhradíme čas, ten kus kódu máme v hlavě a plně se soustředíme na to, co děláme.

Nestává se příliš často, že by výsledek rychleji hotový (když se sečtou hodiny obou vývojářů). Ale párové programování přináší jiné hodnoty než rychlost. Vyšší kvalitu kódu, skutečně „společné“ vlastnictví kódu a je to vlastně i teambuilding.

Pokud jste ještě párové programování nezkoušeli, určitě mu dejte šanci. V práci, na Code Retreatu, nebo zajděte na Coding Dojo. Nebo si něco naprogramujte pro zábavu u jednoho PC s kamarádem.

WF

Pokud jste až doteď znali všechny použité zkratky, tak tuhle asi přeci jen neznáte. Za magickou zkratkou WF se skrývá Wopruz Faktor.

Jako každá aplikace, která má za sebou nějakou historii, i Shopio má části, které jsou méně kvalitní než jiné. Protože v rámci zákaznických úprav zasahujeme často do spousty míst kódu, stane se, že je třeba něco upravit i v těch „ošklivějších“ končinách. A podle toho, jak moc „ošklivý“ ten kód je, tak vysoký je Wopruz Faktor, který je úpravě přiřazený. Wopruz Faktor tedy udává, jak moc se nikomu do dané úpravy nechce („protože to bude wopruz“). Pozor aby nedošlo ke zmatení. WF není to samé jako splácení technologického dluhu. Má mnohem blíž spíš ke zvyšování developer experience (z frameworků DX prosazuje nejvíc asi Symfony).

Dobrou zprávou je, že snižování WF je jednou z priorit během rozvoje Shopia. I během nejnabitějších měsíců věnujeme alespoň několik hodin snižování WF. Za poslední rok jsme udělali v tomto ohledu dost práce a vymetli jsme i ta nejzatuchlejší místa, takže nám teď vývoj dělá o dost větší radost.

Přístup managementu, důraz na kvalitu kódu, svědomité splácení technologického dluhu a zlepšování developer experience je podle mého jednou ze zásadních výhod práce ve w3w.

Možná to vypadá, že se w3w stará víc o vývojáře než o klienty. Ale opak je pravdou. Protože většinu úprav účtujeme hodinově podle reálné náročnosti, tak má snížení WF přímý vliv na výslednou cenu (a termín). Rozdíl mezi „to bude wopruz na celé odpoledne a dneska se mi do toho už nechce (4 h)“ a „to bude celkem snadný, udělám to večer (1 h)“ může být výsledkem jedné nebo dvou hodin snižování WF.

Jak nám to funguje?

Nemůžu mluvit za ostatní, ale z technického pohledu vývoj Shopia funguje skvěle. Především společné vlastnictví kódu nám umožňuje si vzájemně pomáhat a sdílení kódu člověka obohacuje. Tu člověk objeví zajímavou konstrukci, jindy zas elegantní řešení složitého problému. Code review mě donutil víc přemýšlet nad kvalitou kódu a DX už během psaní. Poskytuje také určitou jistotu v tom, že se do produkce nedostane nějaká hloupá chyba z nepozornosti.

Co se chystá?

Nejžhavější věc na Shopiu je momentálně nová šablonovací vrstva, která by měla umožnit grafikům mnohem širší možnosti, co se úprav designu týče. A také nová serverová infrastruktura, díky které se nám otevírá možnost používat nové zajímavé nástroje (redis, fronty, replikované databáze a další). Myslím, že příští rok bude pro rozvoj Shopia velmi zásadní a posune ho hodně dopředu.

Říkáte si teď v duchu, že byste chtěli také programovat takhle? Nebo si říkáte, jak můžeme fungovat bez [doplňte skvělý nástroj pro týmový vývoj]? Dejte nám vědět na info@www.shopio.cz. Neustále hledáme nové posily do týmu a rádi se něco nového naučíme.