PHP + BUSINESS = MONEY!

V dnešnom článku by som rád voľne nadviazal na predchádzajúce dva blogy, v ktorých sme sa s vami podelili o viaceré naše nové poznatky získané na odbornej konferencii PHPCE 2017, ktorá sa konala ešte v novembri minulého roka v Poľsku. 

Počas jednej z prednášok bol prezentovaný v celku zaujímavý pohľad na súčasný vývoj v programovacom jazyku PHP. Autor v nej poukázal na zásadné rozdiely vo vnímaní tohto vývoja samotnými vývojármi a manažérmi. Ako príklad uviedol, že jazyk PHP v očiach niektorých manažérov zrejme nepatrí medzi najnovšie a “najsexy” programovacie jazyky (ako napr. jazyk Go alebo Ruby), z riadiaceho hľadiska je však dôležité najmä to, že tento jazyk je časom overený, pomerne jednoduchý, dá sa rýchlo naučiť a programuje v ňom veľké množstvo ľudí.

 

7 rád, ako možno zlepšiť vývoj softvéru

Za veľmi užitočnú zároveň považujem druhú časť spomínanej prednášky, v ktorej zaznelo 7 rád, ako možno zlepšiť vývoj softvéru. Poďme si ich stručne zrekapitulovať:

  1. Kolektívne znalosti (Collective knowledge). Tieto poznatky by podľa autora nemali byť koncentrované len u jedného vývojára. Ideálnym riešením je oboznámiť s nimi všetkých vývojárov participujúcich v tíme. Vhodné je podľa jeho slov používať napríklad párové programovanie, code reviews a im podobné nástroje. Ich výhodou je aj to, že pomáhajú odstraňovať chyby, ktoré robí každý vývojár a vo finále skvalitňujú kód.
  2. Testy. Nevyhnutnou súčasťou každého dobrého kódu je aj testovanie. Na jednej strane je to automatizované testovanie, ktoré sa spúšťa pred nasadením každej zmeny softvéru do produkcie. Akceptačné testy,  ktoré umožňujú otestovať vyvinutú funkcionalitu ako celok (napr. umožňujú zistiť, či funguje pridanie produktu do nákupného košíka a dokončenie nákupu). Na druhej strane je to regresné testovanie, ktorého cieľom je otestovať, či sme jednou zmenou nespôsobili úplne nové chyby.
  3. Menšie frekventovanejšie releasy (Small releases). Cieľom tohto postupu je namiesto vykonávania veľkých zmien realizovať sériu menších zmien.
  4. Snažiť sa predvídať chyby (anticipate errors). Faktom je, že chybám vo vývoji softvéru nemožno celkom predísť. Je preto dôležité vždy počítať aj s tým, že chyby sa vyskytnú a vopred sa na tieto situácie pripraviť.
  5. Opatrnosť (awareness, benefits vs. risks). Každé rozhodnutie je spojené s určitými rizikami, ktoré je na druhej strane vyvážené určitými benefitmi. Vždy je preto dôležité zvážiť, či sme ochotní podstúpiť určité riziko s vidinou získania určitého benefitu. Typická situácia môže vyzerať i nasledovne: Oplatí sa v piatok poobede nasadiť zmenu na e-shop? Benefit - napr. vyššia predajnosť, riziko - čo ak zmena nasadená v piatok poobede úplne odpáli e-shop a cez víkend to nebude mať kto opraviť?
  6. Monitorovanie (monitoring). Toto pravidlo je veľmi dôležité a hovorí nám o tom, že vždy je potrebné monitorovať čo najviac možných parametrov – napríklad, či prudko neklesá počet používateľov, aký je počet chýb a rôzne iné. Len na základe dôsledného monitoringu je totiž možné včas zareagovať na prípadné vzniknuté problémy.
  7. Neustále zlepšovanie (improve). Siedma zásada nám hovorí o tom, že celý vývojový proces je potrebné neustále zlepšovať a zdokonaľovať. Je to neustály cyklus inovácií a zlepšení, ktorými reagujeme na nové trendy i vývoj na trhu.

Ďalšiu zaujímavú dilemu priniesla prednáška Why is CRUD a bad idea , z ktorej vzišla polemika o tom, či je vhodnejšie používať Anemic Domain Model alebo Rich Domain Model. Je to téma, ktorá sa pomerne často objavuje v rôznych odborných diskusiách. Niektorí developeri sa pritom prikláňajú skôr k prvému modelu, iní sa radia medzi priaznivcov druhého variantu. Pozrime sa teraz na niektoré základné fakty v oboch uvedených prípadoch:

Anemic Domain Model

  • tento model slúži najmä ako prostriedok na získanie dát, neobsahuje však žiadnu logiku,
  • slúži len ako objektovo-relačný mapovač, nerieši však konkrétne správanie,
  • logika preto musí byť umiestnená v Controlleroch, Manageroch, Helperoch,
  • z pohľadu objektovo-orientovaných princípov je to anti-vzor,
  • jeho výhodou je však menšia komplexita tried a metód,
  • napríklad pri pripočítavaní peňazí k bankovému účtu samotný model by riešil len zápis transakcie do databázy a neriešil by aktualizáciu zostatku na účte.

Rich Domain Model

  • tento model už obsahuje aj doménovú logiku,
  • okrem toho, že rieši objektovo-relačné mapovanie, odhaľuje aj správanie,
  • samotný model zaručuje, že dáta sú uvedené v správnom a konzistentnom tvare,
  • spĺňa tiež objektovo-orientované princípy - enkapsulácia, zapúzdrenie,
  • napríklad pri pripočítaní peňazí k bankovému účtu by model zapísal transakciu do databázy a zároveň by aktualizoval aj zostatok na účte.

Po zhodnotení všetkých výhod a nevýhod tak vychádzam z toho, že pri jednoduchých aplikáciách možno použiť aj Anemic Domain Model. Pri komplikovanejších aplikáciách by som však uprednostnil model s komplikovanou logikou Rich Domain Model. Ideálnym riešením môže byť  napokon aj kombinovaný prístup, pretože pri niektorých veciach je výhodnejšie zvoliť model Anemic a pri iných zase Rich Domain. V niektorých prípadoch tiež môže byť zaujímavým riešením najprv zvoliť používanie Anemic a neskôr ho zrefaktorovať na Rich-domain modul.

Už teraz sa tešíme na ďalšie vzdelávacie podujatia.

Zaujal vás tento článok a chceli by ste sa o niečom informovať? Napíšte nám a radi sa vám ozveme späť.