Vývoj WordPress projektů ve více lidech


Ptali jsme se na Twitteru, co by vás zajímalo z prostředí vývoje WordPressu, a dostal se k nám tip na ukázku toho, jak provádět vývoj složitějších projektů na WordPressu ve více lidech – třeba ve vlastním týmu. Dlouho jsme s kolegou Martinem přemýšleli, jak článek  pojmout, a co k tomu napsat. Nakonec jsme se shodli na několika bodech, které dodržujeme my a co nám funguje. Obecně pracujeme ve vývoji dvou lidí – tedy nemáme žádný tým o 30 programátorech.

Větších i menších projektů jsme pro WordPress napsali už mnoho a i my jsme museli řešit problém při práci více lidech (byť pouze 2) na jednom projektu zároveň. Je určitě mnoho cest jak to dělat a určitě najdete spoustu odlišných názorů a postupů, jak to dělají jiní. U nás jsme nehledali to nejlepší a nejdokonalejší řešení ani workflow, ale takové řešení, které bude pro velikost našich projektů dostatečné a zároveň ekonomicky dostupné. Ekonomicky dostupné v tom smyslu, aby nám po 6 hodinách práce nezabralo další dvě hodiny naši práci nějak sesynchronizovat a nebo nedejbože neustále něco opravovat, protože jsme si některé soubory přepsali.

Naše klíčové body

  1. Rozdělení dílčích prací mezi členy
  2. Struktura projektu
  3. Konvence samotného PHP kódu
  4. Komentáře!
  5. Verzování souborů
  6. Deploy – přesun na produkční server

Rozdělení dílčích prací mezi členy

Na začátku většího projektu byste si vždy měli projekt rozdělit a rozfázovat na jednotlivé etapy. Při této části byste měli velmi dobře myslet na vzájemné vazby úkolů. Jednotlivé úkoly by měly mít návazný postup tak, aby postupem času skládali celý komplet. Pravděpodobně nebude příliš moudré jednomu z členů zadat jako první hlavní úkol „košík“ vašeho prodejního systému, když jiný kolega bude programovat objekt produktu až za 14 dní. Obecně bude velmi složité košík připravit dobře, korektně a včetně testace, když nemá připravené dílčí části, které k tomu bude potřebovat.

Jednotlivé úkoly ve vašem týmu byste také měli odhadnout v časové náročnosti a snažit se naplánovat vše tak, aby jeden člen nezdržoval členy ostatní. Opět nebude moudré jednoho člena týmu zahltit složitou, dlouhotrvající prací a jako druhý úkol mu zadat část, na kterou již po týdnu budou všichni čekat. U termínů pozor – vždy je počítejte co nejreálněji a vždy k reálnému odhadu ještě něco „přihoďte“. Také byste neměli mít přístup na projekt takový, že chvátáte, není čas, musí to být rychle a že na to sednete na jeden den a jednu noc a bude to hotové. Nebude – pokud máte psát kvalitní kód, který bude na 100% fungovat, musíte být odpočatí.

Struktura projektu

Jako každý projekt by měl mít svou strukturu podle předem stanovených pravidel. Každý člen týmu by měl vědět, kde co najde nebo alespoň kde s hledáním začít. Ať zvolíte strukturu svou, nebo pracujete nad nějakým Frameworkem, je nutné, aby ji každý člen bez podmínek dodržoval. Nemělo by se vám stávat nic jako: „V tu chvíli jsem nevěděl, kam to napsat, tak jsem to napsal tady, protože jsem to potřeboval rychle“. S tímto přístupem budete mít za chvíli v projektu hokej a nikdo se v něm nevyzná. A za pár měsíců se už v něm nevyznáte ani vy sami, jakožto samotní autoři.

Protože využíváme vlastní framework, který také aktivně píšeme, řídíme se strukturou, kterou jsme předali do samotného frameworku. Obecně máme definované dvě struktury – jednu pro šablonu, která prezentuje frontend, a poté na vlastní sadu souborů, do které zapisujeme potřebné logiky, funkce, definice, modely atd. Díky tomu vždy celý tým ví, kde má co hledat, kde má co zapisovat a proč.

Nestane se nám, že potřebujeme upravit kus kódu a půlhodiny ho hledáme s myšlenkou, kam ho mohl kolega asi schovat. Díky tomu bude vaše práce mnohem efektivnější.

Konvence samotného PHP kódu

Pokud máte již definované dílčí úkoly a strukturu projektu, je na čase se s kolegy také domluvit na tom, jak budete obecně zapisovat a pojmenovávat funkce, proměnné a také to, kam jaké části kódu budete psát. To, kde budou umístěné jednotlivé funkce a části kódu velmi souvisí s předchozím bodem – Struktura projektu. Ať tak nebo tak, je nutné si stanovit, kam jaká logika bude patřit.

Všechny vaše funkce by měly mít stejný tvar. Nemělo by se stát, že jeden člen bude psát funkce s podtržítkem, druhý bude oddělovat slova Velkým písmenem a třetí to nebude dělat vůbec. Pokud nepoužíváte v rámci PHP jmenné prostory (namespaces), je dobré si také definovat některé prefixy funkcí. U nás například máme domluveno, že funkce začínající slovem „get“ vždy něco vrátí a že funkce začínající „render“ vždy rovnou něco „echují“. Když následně očima projíždíme kód toho druhého, z prvního pohledu víme, co funkce v základu dělá.

Vaše funkce by měly také na první pohled z 80% – 90% sdělit čtenáři, co asi tak dělají. Funkce getPostTitle() bude asi vracet titulek příspěvku, renderTermPagination() bude s velkou pravděpodobností vykreslovat stránkování termu (kategorie). Například funkce s názvem title() nám toho asi moc neřekne. Budeme sice vědět, že se bude jednat o nějaký titulek, ale nebude moc vědět čeho. Tato funkce nám sdělila sotva 30% své podstaty. Také to s názvem nepřehánějte – do funkce nepřidávejte věci, které nic neřeknou – getMainPostTitle() – V případě post je slovo „Main“ zbytečný, protože jich příspěvek stejně více nemá.

V podobném duchu byste měli pojmenovávat jednotlivé proměnné, které budete při své práci potřebovat. Proměnné jako $data, $data1, $args, $a, $value, $val atd. toho opět moc neřeknou. Je lepší použít například $postData, $queryArgs, $inputTextValue, atd. Na první pohled by mělo být zřejmé, co asi tak proměnná udržuje za hodnotu, aby druhý kolega nemusel hledat, jak a proč svou hodnotu nabyla.

Komentáře!

U funkcí, které jsou potřeba, byste měli vždy sepisovat řádný komentář. Komentář by měl v rychlosti popsat, co funkce dělá, nebo k čemu slouží. Dobré také je – pokud využíváte nějaké IDE – psát komentáře tak, aby byly případně součástí našeptávače využívaného IDE. Některé IDE také umí psát komentáře rovnou k parametrům funkce nebo také sdělit, o jaký datový typ se jedná. Obecně se držíme toho, že komentáři se nemá šetřit, je však také dobře uvažovat nad tím, zda je dobré je používat všude, kde vše o funkci řekne její název.

Verzování souborů

V současné době doporučujeme používat verzovací systém Git, především kvůli jeho možnostem a komunitě okolo projektu GitHub, anebo jeho velmi podobnou variantu Mercurial (HG), kterou je možné společně s Gitem provozovat i zdarma v rámci projektu BitBucket. Dále můžete narazit např. na SVN a další předpotopní záležitosti, které z vlastních zkušeností moc nedoporučujeme, především kvůli nepohodlné (týmové) spolupráci, nebo pak případně Team Foundation Server od Microsoftu, ale ten pro PHP asi používat nebudete… ;)

Náš model využití verzování je celkem jednoduchý a už se nám dobře osvědčil: všechny naše veřejné projekty máme v Gitu na GitHubu a naopak všechny neveřejné projekty máme v Mercurialu na BitBucketu. Vlastní servery tedy nemáme a plně důvěřujeme zmíněným provozovatelům. Díky tomu můžeme celkem snadno kombinovat privátní projekty projekty s veřejnými moduly (WP Framework) a kombinovat ignorační soubory obou verzovacích systémů najednou. Pro obsluhu je pak možné využívat např. program SourceTree, který umí pracovat s Gitem i Mercurialem nebo třeba kombinací TortoiseHG + GitHub for Windows…

Deploy – přesun na produkční server

Zde budou určitě mnozí z vás očekávat nějakou převratnou novinku, nástroj, který udělá vše za vás a nemusíte se o nic starat. Zde čtenáře asi bohužel trochu zklamu. Zkoušeli jsme a prověřovali možnosti mnoha nástrojů, které samotný deploy hodně automatizují. Bohužel jsme nenašli nic, co by odpovídalo naší velikosti, představě jednoduchosti a rychlosti provedení operace. Zatím jsme tedy skončili u prostého FTP, kde vždy udržujeme stav projektu / aplikace aktuální dle vývoje v repositáři verzovacího systému. Vždy, když nastane potřeba promítnout změny i na produkci u klienta, nastoupí hloupé FTP a data přenese.

Určitě nás teď považujete za barbary vývojáře, protože je přeci mnoho skvělých nástrojů, jak to dělat jinak. Ano, souhlasím s vámi a nebudeme se přít. Bohužel ale využívání těchto nástrojů je mnohem složitější a pro velikost našich projektů naprosto neekonomické. V našich rozměrech týmu a velikosti projektů nám na tuto funkci skutečně stačí prozatím FTP, které proces provede prakticky zadarmo, zadání operace trvá pouze několik vteřin a je hotovo.

Nicméně alespoň pro představu přidáváme několik odkazů na automatizační nástroje, které s deployem souvisí, pokud byste se tím někdo chtěli zabývat sami:

, , ,

  1. #1 Smety 31.8.2016 - 16:19

    Pěkný článek!

    Na automatický deployd ideálně VPS popř. u nás je Blueboard. Pak není FTP prakticky potřeba.

Komentáře jsou uzavřeny.