Udržování projektu v PHP: 5 chyb, kterým se vyhnout

PHPmá stejně jako jiné jazyky některé nevýhody, které jsou však při správě systému zbytečné. IT projekt kde PHP je hlavním jazykem.

Níže uvádíme jejich seznam a tipy, jak se jim vyhnout.

1. Nedodržení doporučení norem PHP

PHP je považován za "snadný jazyk", protože má velmi nízkou vstupní bariéru. To má za následek velké rozdíly ve standardech kódování a způsobu implementace globálních rozhraní v různých externích knihovnách. Ve snaze zavést pořádek byl zaveden soubor standardů. Ty popisují sadu způsobů, jakými může vývojář implementace splnit libovolnou sadu omezení požadovaných standardem. Jednoduchý příklad pro Dispečer událostí:

Posluchač - Posluchač je jakýkoli PHP callable, který očekává, že mu bude předána událost. Stejná událost může být předána nule nebo více posluchačům. Posluchač MŮŽE zadat nějaké jiné asynchronní chování, pokud se tak rozhodne.

Pomocí tohoto standardu může každý vývojář, který používá nomenklaturu PSR, snadno nejen komunikovat, ale také kód s ostatními vývojáři.
Zavedení těchto standardů do praxe, například pomocí PHP Správný způsob pokyny a knihovny, které podporují globální rozhraní PSR, umožňuje Vývojáři PHP rychleji se přizpůsobovat změnám funkčních, architektonických a infrastrukturních požadavků.

Jak se tomu mohu vyhnout?

Jako správce kódové základny vždy pamatujte na používání ověřených a stabilních verzí externích knihoven, a pokud jste nuceni použít vlastní řešení, implementujte je pomocí PSR PHP.
Seznam všech dostupných norem je k dispozici na hlavní webové stránce. PHP-FIG. Rozšířené normy s praktickými popisy jsou k dispozici v různých formátech na stránkách PHP Správný způsob domovské stránky.
Nejlepší knihovny, které odpovídají standardům PHP-FIG, jsou uvedeny na seznamu PHP Liga webové stránky.

2. Nezamykání verzí závislostí v souboru composer.json

V projektech, které používají správce závislostí Skladatel často dochází k situaci, kdy po dlouhém období podpory a udržování produkt v produkčním prostředí je potřeba implementovat funkční změny bez nutnosti přestavby celé architektury. Nejčastěji pak projekt přebírá programátor, jehož úkolem je spustit lokální vývojové prostředí a začít pracovat na tiketech. Na základě composer.lock je vývojář schopen obnovit projekt do stavu, v jakém byl v produkčním prostředí, ale jakákoli změna v souboru composer.json souboru, např. přidáním knihovny, způsobí kaskádu chyb, které prodlouží skutečnou dobu implementace nového souboru. tým člena organizace, stejně jako doba vývoje řešení.

Jak se tomu mohu vyhnout?

Jakmile je aplikace stabilní, měl by správce kódu uzamknout verze knihoven v adresáři. composer.json a vytvořit jasný postup popisující, jak v případě potřeby v budoucnu aktualizovat jejich verze.

Zvažte také spuštění mechanismu pro kontrolu stavu zabezpečení používaných knihoven a automatizaci procesu poskytování aktualizací zabezpečení.
Pomocí bezplatných nástrojů, jako je např. Dependabot, můžeme udržovat konzistentní a spravovatelnou infrastrukturu pro správu verzí závislých knihoven a zároveň poskytnout záruku zabezpečení naší aplikace.

3. Špatné shromažďování požadavků

> Je to jen CRUD, proč se tím zabývat?

> Existuje knihovna, která přesně tohle dělá!

V PHP doméně, je snadné se při implementaci obchodní logiky produktu dostat do víru zapomnění. V průběhu let vznikly stovky projektů, které [vytvářejí administrativní panely pro správu datových modelů](https://backpackforlaravel.com/), [generují pohledy podobné Google Analytics](https://github.com/Kunstmaan/KunstmaanDashboardBundle) nebo [řeší asynchronní problémy PHP](https://laravel.com/docs/9.x/octane) jako mávnutím kouzelného proutku (dobře, jedním dotazem z příkazového řádku).
Svět PHP je plný hotových implementací, které fungují v 99,9% případů.
V tomto případě se obchodní logika střetává s funkčními omezeními použitých knihoven.
Právě tyto takzvané "throw-iny" jsou na konci projektu nejobtížněji realizovatelné.

Jak se tomu mohu vyhnout?

Bez správného pochopení obchodní oblasti produktu není možné najít zlatou střední cestu mezi nadměrným a nedostatečným inženýrstvím.
Tím, že začnete vývojový tým členů v rané fázi vývoje produktu a proaktivním přístupem při spolupráci s vlastníkem produktu můžete minimalizovat riziko problému, že použijete řešení, které nebude fungovat jako dlouhodobá investice.

4. Snížení nákladů tím, že se vyhnete psaní testů

PHP není dokonalý, to je jisté. Jeho nedostatky v podobě statického typování, chybějící podpory generik a přetrvávající podpory archaických metod jsou stále zdrojem vtipů mezi programátory. Nicméně už nějakou dobu Vývojáři PHP dostávají stále výkonnější nástroje, jako je PHPStan, Xdebug, PHP-CS-Fixer které jim umožňují zachovat konzistenci a statické typování - a tím se vyhnout mnoha chybám. Přesto se testům věnuje příliš málo pozornosti a ty, pokud jsou správně implementovány, vedou k rychlé návratnosti investice v podobě
- snížení regresních chyb
- zvýšené povědomí o možnostech produktu
- zvýšení pocitu vlastnictví kódu vývojáři

Jak se tomu mohu vyhnout?

Nesnižujte náklady na testování. Psaní jednoduchých skriptů Behat opravdu není tak těžké, nemusíte hned psát složité end-to-end testy nebo se pouštět do implementačních detailů a testovat každou metodu.
Jednoduchý test Behat popsaný přirozeným jazykem domény má často větší hodnotu než ten nejpečlivěji napsaný end-to-end test.

5. Nezohlednění moderních vzorů architektury

Na stránkách Jazyk PHP a její dva nejvýkonnější rámce Laravel a Symfony jsou plně vhodné pro vytvoření moderní, funkční a hlavně vysoce výkonné architektury. Podpora různých systémů front zpráv a stále se zrychlující PHP zlepšení výkonu od verze k verzi umožňuje nás snadno vytvořit mikroslužby založené na mikrokrajích. Z velké části se však stále spoléháme na monolitické systémy. Na tom není nic špatného, ale při úvahách o vývoji takových systémů musíme věnovat velkou pozornost hranicím domény a určit místo rozhraní mezi novými řešeními a staršími částmi systému.

Jak se tomu mohu vyhnout?

Při vývoji jakéhokoli PHP webové stránky, je vhodné se podrobně podívat na současná řešení, vytvořit globální rozhraní pro datovou komunikaci a implementovat nové funkce s využitím nejnovějších technik a postupů. Jedním z nejoblíbenějších řešení používaných v praxi je např. Vzor škrtiče.