Vývojové standardy

Každá práce má svá pravidla. I my máme svoje a snažíme se je ze všech sil dodržovat

1. Standardy kódu

• PHP kód musí být validní
• PHP kód musí být PSR-2 kompaktibilní
• Kód používá k odsazení mezery 1tab = 4 mezery
• Všechny třídy musí být buď abstract nebo final (výjimku tvoří Doctrine Entity a Unit testy)
• kód musí používat vstupní i výstupní typehinty (výjimku tvoří situace při použití kódu třetích stran), multiple typehintům se snažíme vyhýbat

2. Standardy aplikace

• používá se architektuře M-V-P (model-view-presenter)
• používá se v maximální míře systém eventů
• používá se v maximální míře komponentový model
• všechny texty, které zobrazuje frontend jsou překladatelné
• aplikace nesmí záviset na konfiguraci (s výjimkou konfigurace služeb)

3. Standardy modelů

Používá se pětivrstvá architektura

• entita - objekt obsahující data (např. Doctrine entita)
• repositář - objekt zajišťující CRUD s entitami (zajišťuje Doctrine)
• mapper - zajišťuje propojení mezi databází a repozitářem (zajišťuje Doctrine DBAL)
• service - konfigurovatelný objekt provádějící akce nad repozitářem jedné entity
• fasáda - objekt s jednorázovými metodami propojující akce jednotlivých service do funkčních celků

Přímé volání je povolené pouze u fasád. Přímé použití je pouze v presenterech nebo při volání událostí (event subscribery)

Entity

• musí být SmartObject
• měli by podporovat fromArray(), fromStdClass(), toArray() a toStdClass()
• všechny vlastnosti musí mít staticky dostupný název konstantou
• všechny vlastnosti musí být private
• přístup je povolen pouze pomocí setterů a getterů
• settery musí provádět validaci vstupů
• settery a gettery musí být definovány pomocí @property, @property-read, @property-write
• každá entita musí vyhazovat svou vlastní validační výjimku
• každá entita musí být jednotkově testovatelná
• sdílené vlastnosti entity se kombinují pomocí traitů

Repozitář

• repozitář je zcela v gesci Doctrine ORM

Mapper

• mapper je zcela v gesci Doctrine DBAL

Service

• jedna služba obsluhuje pouze jednu třídy entity
• každá služba musí obsahovat akce pro čtení, zápis, vyhledávání, změnu a mazání entit
• každý služba musí mít staticky dostupný název třídy entity konstantou
• každá služba musí mít staticky dostupný název aliasu entity
• služba jako jediná vrstva modelu přijímá konfiguraci z neon souborů aplikace
• služba vyhazuje pouze výjimky entit
• služba nesmí obsahovat žádné texty z frontendu
• každá služba musí být jednotkově testovatelná
• služba nesmí generovat událost

Fasáda

• sdružuje funkcionalitu jednotlivých servisů
• servisy jsou závislostmi fasády
• každá metoda fasády slouží pouze jednomu účelu
• fasáda nemá vlastní konfiguraci, ale může přejímat konfiguraci ze služeb
• každá akce fasády, která provádí změnu dat v entitě musí generovat událost
• každá akce fasády musí provést všechny úkony nezávisle na presenteru nebo události
• fasáda musí být jednotkově testovatelná
• názvy událostí fasády musí být staticky dostupné konstantou

4. Standardy presenterů

• presenter může mít maximálně 10 akcí
• každá akce může mít maximálně 30 řádků
• každá akce musí mít v anotaci, co dělá
• presenter nesmí provádět žádné změny entit, pouze smí předávat kolekce nebo datasource do view nebo komponent
• při potřebě změny dat entit generuje událost
• presenter nemá vlastní konfiguraci, ale smí přejímat konfiguraci ze služeb
• každá akce musí mít kompletní název staticky dostupný pomocí konstanty
• každý komponenta vytvořená v presenteru musí mít název staticky dostupný pomocí konstanty
• každý text frontendu musí být překladatelný a staticky dostupný pomocí konstanty

  5. Standardy komponent

• každá komponenta musí být znovupoužitelná
• každá komponenta musí mít svou továrnu (buď automaticky generovanou nebo manuální)
• komponenta nesmí obsahovat více než jednu úroveň dat v opačném případě musí být použity subkomponenty
• komponenta nemá vlastní konfiguraci, ale smí přejímat konfiguraci ze služeb
• komponenta nesmí volat žádnou vrstvu modelu
• komponenta smí přijímat kolekci dat nebo datasource
• komponenta smí přijímat další akce pomocí callbacku
• komponenta musí při potřebě změny dat v entitách generovat událost
• komponenta musí mít staticky dostupnou cestu k šabloně (konstantou)
• komponenta musí mít staticky dostupný název všech subkomponent (konstantou)
• kompomenta musí mít staticky dostupný název (konstantou) všech událostí, které generuje
• komponenta musí mít všechny texty frontendu překladatelné
• komponenta musí mít všechny texty i jejich kotvy staticky dostupné (konstantou)

  6. Standardy událostí

• každá událost musí mít svůj jedinečný název (ve formátu modul.třída.onUdálostiKteráNastala)
• zachycení a zpracování událostí zajišťuje subscriber
• data se při vyvolání události předávají do subscriberu pomocí entity události
• každý presenter, komponenta nebo fasáda musí mít svou vlastní třídu entity události a svůj subscriber
• události smí generovat presentery, komponenty, fasády a subscribery událostí
• subscriber má fasády jako své závislosti
• subscriber smí jako jediná součást aplikace přímo volat akce fasád, které mění data v entitách
• každá událost sí volat právě jednu akci subscriberu
• všechny texty frontendu v subscriberu musí být překladatelné
• všechny texty nebo kotvy frontendu subscriberu musí být staticky dostupné konstantou
• každá akce subscriberu končí ukončením aplikace, přesměrováním nebo forwardem na jinou akci presenteru
• akce subscriberu musí zachytit všechny výjimky, které vyhazuje fasády a vrstvy pod nimi