E-shop je hotov - je čas rekapitulace

A je to tu. Poslední díl malé reality show, která měla za cíl ukázat jak s pomocí PHP Jet z nuly vytvořit typickou webovou aplikaci s řadou zajímavých funkcí a to efektivně, za co nejkratší čas a při tom kvalitně a bez jakýchkoliv limitů  – lze “napsat” vše co si člověk zamane.

Poslední díl bude ale (trochu) jiný. Původně jsem zvažoval vytvoření posledního kroku objednávky tak, aby se vešel do časového limitu. Ale byla by to hrozná nuda. Ukazoval bych vám to všechno co jste již opakovaně viděli. Vytvoření entity, namapování formuláře, … Nic nového, nuda, nuda, šeď.

Objednávkový proces jsem tedy raději pojal tak, že jsem se inspiroval v připravované e-shopové platformě Jet Shop a vytvořil jsem objednávkový proces takřka plnohodnotný a zcela reálný. To mimo jiné znamená, že uvidíte například použití aplikačních modulů v roli modulů objednávkového procesu (metody dopravy a platvy, ale bylo by možné nejen to). Dnes již nebudu nic psát, ale více mluvit. Ostatně koukněte na video na konci článku.

A doprovodný článek závěru této minisérie bude také jiný a již to nebude pouhé “tak tady je video a nazdar!”. Sluší se udělat takový malý souhrn.

Tak co to vlastně za “jedno dopoledne” vzniklo?

Nejprve si zrekapitulujme, co za onen vymezený relativně krátký čas vzniklo:

• Základní entity každého e-shopu: kategorizace, produkty, objednávky
• Vše rovnou připravené na mezinárodní prostředí
• Administrace produktových kategorií, rovnou s veškerým logováním a kontrolou oprávnění pomocí rolí
• Administrace produktů, taktéž rovnou s veškerým logováním a kontrolou oprávnění pomocí rolí
• Možnost kdykoliv přidávat a odebírat další země
• Více měn, více nastavení DPH a tak dále
• Procházení produktového katalogu rovnou s podporou “hezkých” URL
• Práce s obrázky, nahrávání, generování miniatur
• Nákupní košík samozřejmě využívající session a také AJAX
• Objednávkový proces sám o sobě modulární (metody dopravy a platby jsou taktéž aplikační moduly)
• Vše jasně rozdělené do jednotlivých aplikačních modulů umožňujících jasně určit kompetence jak kódu, tak třeba i členů týmu.
• Vše by mohlo být výkonné, rychlé (i když to je vždy věcí vývojářů, jakýkoliv framework tomu může buď napomáhat, nebo i naopak škodit, ale sám o sobě framework nemůže vlastně celou kvalitu aplikace determinovat)

Samozřejmě reálný e-shop je ještě trochu jiná legrace. Např. musí obsahovat parametrizaci. Musí existovat správa objednávek, nějaké napojení na účetnictví, a asi tak miliarda různých marketingových funkcí a opravdu hodně dalších věcí.

Ale cílem bylo ukázat následující:

• V PHP Jet lze dělat naprosto cokoliv. Je to zcela univerzální framework pro tvorbu jakékoliv online / webové aplikace, zcela bez hranic a omezení.
• Práce je velice efektivní. Framework se vám neplete do cesty. Naopak vám pomáhá s tím co opravdu nikdo z nás nechce dělat tisíckrát, ale pomáhá řešit to co řešíme dnes a denně.
• Ano, za to jedno dopoledne můžete v pohodě udělat plně funkční a kvalitní prototyp čehokoliv. Nebo za den. A pak si dalších pár dnů “hrát” tak, aby vše bylo perfektní a při odevzdání práce panovala všeobecná spokojenost.
• Aplikace je tvořena jednotlivými prvky, které do sebe nejsou zamotané jak mísa špaget, ale které spolu jasně definovaným způsobem spolupracují. A jakýkoliv z těch prvků lze upravovat, či zcela vyměňovat, bez negativního vlivu na zbytek aplikace. Klidně můžete úplně změnit chování třeba košíku a vše pojede dál. Můžete někomu říct, ať se stará o správu produktů v administraci. A bude jasně dáno a ohraničeno kde to je a co to je. V neposlední řadě můžete jednotlivé komponenty aplikace (třídy, celé moduly) používat znovu a znovu.
• A jak jste viděli, tak to není jen nějaká teorie, ale praxe …

Bylo to jednoduché, že? Ale vůbec ne!

Ano, kdo viděl videa mohl nabýt dojmu, že vytvořit webovou aplikaci je vlastně velice jednoduché. Zejména s PHP Jet, který tomu trochu pomáhá. Ten kdo obor nezná si může myslet “no jo, to jsou JEN ty weby” (na takové lidi a názory jsem v praxi parkát narazil …)

Ale úplný opak je pravdou. Předně náš obor je velice multidisciplinární a to možná ještě více než si zprvu sami uvědomujeme.

Však co musí umět / znát / při nejhorším alespoň trochu znát vývojář co se motá kolem online aplikací? Zkusme si to vyjmenovat:

• Síťařina: minimálně jak funguje DNS. TCP/IP, základy routování, vědět co to doopravdy je IP či TCP port, UDP, ….
• SSL, certifikáty atd atd …  Jak to funguje? Co s tím? Jak s tím?
• Servrařina: jak funguje webservery, jak a proč jej konfigurovat, to samé databázové servery, FTP, SSH, … ideálně i Linux samotný – nejpoužívanější OS na planetě, …
• Skriptovací jazyk běžící na serveru (v tomto případě PHP 8.x)
• Principy efektivního návrh SW architektury aplikaci. To co děláme může dlouhá léta znamenat obživu pro řadu lidí a musí se to dál rozvíjet a fungovat a reagovat na nekonečné nové požadavky a všechny okolní vlivy a to vše ve velice dynamickém a konkurenčním prostředí.
• Principy návrhu technicky opravdu efektivních (rychlých a výkonných) aplikaci. Na internetu prostě nikdo čekat nebude! Stejně jako náš klient / zákazník není zvědavý na to, že to za co zaplatil běží pomalu či padá…
• Principy bezpečnosti! Ano, to co děláme je vystavené větru a dešti divokého internetu. Úplně každý na to může útočit a útočí … Neděláme aplikaci, která si běží někde “v teplíčku a pohodlí” izolovaně.
• Principy testování (funkčnost aplikace, zátěžové testy, penetrační testy, … )
• Principy komunikace mezi systémy (jak napojování se na systémy jiné, tak návrh a realizace API vlastních)
• Principy autentizace a autorizace a všeho co s tím souvisí. Má někdo dneska projekt, kde je pouze jedna metoda autentizace a autorizace?
• XML, JSON a kdo ví co ještě ….
• Alespoň základy HTML a CSS (to je konkrétně můj případ).
• JavaScript – ať děláme co děláme, vždy na něj dojde.
• Pokud je člověk to čemu se říká “full stack developer” nebo “frontenďák”, tak musí umět nejen HTML a CSS (a to již tento krát mnohem lépe než základně …), ale i například otázky přístupnosti, další optimalizace UI/UX a tak dále a zároveň být i tak “ trochu” grafik – de fakto další podobor daného oboru (a já tyhle lidi fakt obdivuju!).
• Analytické schopnosti. Větu “Hodilo by se tam jen takové tlačítko” musíme být schopni transformovat efektivně nejen do pár řádek skriptů, ale především do kontextu toho všeho co jsem tu psal. Ale vlastně většinou ne jednu větu, ale mnohem více myšlenek, nebo při nejhorším hrobové ticho a podprahové informace … Prostě komunikace a někdy tak trochu psychologie.
• K tomu samozřejmě i nějaká ta potucha o problematice SEO, marketingových a měřících nástrojích a tak dále – prostě přesah do světa online marketingu je také potřebný.
• Schopnost pracovat efektivně, protože svět je v pohybu a nečeká na nikoho.
• … a sto-pro jsem na něco zapomněl.
• Schopnost z toho nezešílet … občas se na všechny “ty internety” vy-víte-co a jít si třeba zasportovat …

Prostě je toho tak jako tak opravdu hodně…

Na druhou stranu nás je málo, ale požadavků na nás je stále víc.

Tedy ne, není to ani trochu jednoduché. Nejsou to ani trochu “jen weby”. Naopak.

(Poznámka: Teď to neporovnávám s ničím a nikým jiným! O to vůbec nejde. Jde pouze o popis určitého podoboru vývoje SW a ne srovnání s podobory jinými – vše má své).

A otázka zní: Proč si to ještě víc komplikovat?

V našem oboru je opravdu klíčové, aby to co jde dělat jednoduše bylo možné dělat jednoduše, protože starostí máme i tak dost. A proto se před mnoha lety prosadilo zdánlivě jednoduchoućké PéHáPko (to je má teorie proč zrovna toto a ne něco jiného), na kterém dnes běží i věci, který by člověk neznalý vůbec nečekal.

A já se snažím přispět frameworkem, který neobsahuje zbytečnosti (které mohou v reálné praxi práci spíše komplikovat), ale řeší to co dnes a denně opravdu řešit potřebujeme.

Ale pojďme si to rozebrat detailněji – po jednotlivých faktorech co umožňují pracovat efektivně.

Jde to i efektivně, protože …

1) PHP 8.x

PHP je pro daný účel opravdu skvělý jazyk. Opakuji: pro daný účel! Nemá smysl hádat se který jazyk je lepší. Jsou to jen a pouze pracovní nástroje, které se pro daný účel hodí velice dobře, so-so, a nebo vůbec. V assembleru bych online aplikace fakt nepsal, stejně jako bych v PHP nepsal operační systém – extrémní příklady pro zdůraznění podstaty myšlenky.

Není to ani náboženství, ani fotbal, ani ženy, ani auta … Je to jen a pouze práce a pracovní nástroje. Nic víc.

(Mimochodem: Brunety jsou nejlepší! :-P A fotbal je nejlepší hrát se synem … ;-) No … Snad nebudu v roce 2023 za tyhle staromódní řeči a poznámky upálen … )

PHP je pro daný účel velice rychlý a efektivní nástroj. Ve verzi 8.x to opravdu perfektně dozrálo a hlavně bylo definitivně vyčistěno.

(Má osobní poznámka: Sem tam bych si přál namátkou například spřátelené třídy a další věci, ale dá se bez toho žít. Zase takové pojmenované parametry jsou parádní věc! A tak by se dalo pokračovat v samostatném článku … ).

Na PHP bylo a je boží to, že mohu dělat věci fakt jednoduše – když potřebuji dělat jednoduché věci. A stejně tak si mohu hrát s OOP architekturou velké aplikace. Mohu kouzlit rozhraní, abstraktní třídy a tak dále, ale stejně tak jiný kolega může ve view prostě a jednoduše udělat podmínku a cyklus pro vygenerování HTML (což byl prapůvodní účel PHP). Nic se nemusí kompilovat. Vše běží hned a rychle. A tak dále …

V neposlední řadě PHP je důvěryhodná a předvídatelná technologie. To je extrémně důležité! Vývoj PHP je jasně plánovaný, řízený, předvídatelný, má to pravidla a směr. Už je to profi práce.

To se bohužel nedá říct o světě různých frameworků a knihoven jak pro PHP, tak třeba pro JavaScript (tam se mi to zdá, čistě subjektivně, ještě markantnější), kde se někdo ráno probudí a rozhodne se dělat zásadní změny v setinkových verzích, nabourávající kompatibilitu … Jako by change management byl neznámé, či snad dokonce sprosté slovo (mimochodem – taky téma na článek). A největší bizár který mám ve své sbírce podivností je asi toto.

Ano, kolem PHP se často dějí divné věci. Vývojáři knihoven třeba i ignorují fakt, že mají zodpovědnost ke svým uživatelům a že prostě musí myslet na problematiku řízení a plánování změn a ne si dělat to co je ráno či večer napadne.

Ovšem to se naštěstí absolutně netýká PHP samotného. To jak během let prošla transformace z řady 5.x na řady 8.x bylo perfektní – žádná živelnost, ale jasný plán na roky.

Od řady PHP 8.x mám “PéHáPko” fakt rád a nejen kvůli tomu, že je teď o hodně lepší, ale i to jak k jeho zrání tým autorů přistoupil.

A mimochodem … To masivní rozšíření PHP je taky fajn – umí / zná to více lidí … A má to super TCO.

PHP je prostě (pro daný účel!) moc fajn nástroj dělající to co od něj potřebuji. A pro řadu 8.x to platí násobně.

2): Open-source

Možná námět pro nějakého ekonoma: Jak moc zasáhlo obor IT a tedy aktuálně i celé lidstvo (ač o tom raději ani nechci moc přemýšlet, tak planeta se prostě digitalizuje a to fakt hodně a asi je to teprve začátek) to, že si vlastně každý může rozjet třeba server s čím potřebuje?

Vznikla by vůbec spousta technologií a služeb (namátkou Wikipedia, sociální sítě jako třeba FB, ale i Google staví na open-source…) kdyby jejich autoři na samém začátku neměli tak snadno přístupné potřebné technologie díky open-source?

Možná by stálo za to to rozpitvat.

A ne, open-source není komunismus. I kolem toho je business. Vlastně obří business. Pouze jinak koncipovaný.

Faktem je, že tahle myšlenka světem hodně pohnula a doopravdy to vše docení až historie. Teď si to možná ani neuvědomujeme.

Mimochodem … Na mém počítači s Linuxem běží pro testovací a vývojářské účely Microsoft SQL server … Kdysi možná nemyslitelné (kdo si ještě ty války pamatuje?), dnes naprosto boží a jsem rád, že samotné myšlenky spolupráce jsou nyní vlastně v IT takřka standardem.

3) Žádné šablonovací systémy a podobně věci …

Od jednoho kolegy jsem slyšel, že Rasmus Lerdorf, otec PHP, na jedné konferenci měl pronést větu: “Problémy začaly, když lidé začali psát šablonovací systémy pomocí mého šablonovacího systému”.

Ještě se mi nepodařilo dohledat nějaké video, kde by to bylo zaznamenáno. Ale souhlasím.

Vývojáři se často ohánějí slovíčky, někdy až s náboženskou posedlostí.

No jo, jenže vývoj SW není o psaní kódu. Jak jsem psal i v mém článku o AI, tak psaní kódu je jen jeden z prvků celého řetězce, kterému se souhrnně říká vývoj SW – softwarové inženýrství.

A to zahrnuje i ekonomiku a management. A tedy nejen “kódování”, ale i termíny jako například TCO – celkové náklady vlastnictví.

A popravdě toho kdo nás “prgače” platí nezajímají nějaké řeči, kterým dotyčný ani nemusí rozumět, ale právě TCO. Ne, naše žabomyší vojny zajímají pouze nás, přesjněji pouze některé z nás.

Šablonovací systémy v PHP jsou věc, které technicky prakticky takřka nic nepřináší, ale mají naprosto šílené a neobhajitelné TCO.

Proč bych měl byť jediného člena týmu učit technologii, která a) není standardní, b) nepřinese žádné měřitelné komparativní výhody, c) zkomplikuje práci a přinese nové překážky a problémy a stojí čas?

Čas člověka není zdarma. Naopak je to to nejdražší. A to jak po stránce filozofické. (Co je víc než kus pomíjivého života, který je konečný a nenahraditelný?) Tak v tomto kontextu je to hodně drahá legrace po stránce finanční.

Když už za něco dávat peníze, tak určitě třeba na nějaký kurz na téma bezpečnost, nebo na téma kterému se v anglicky mluvícím světě říká počítačové vědy a je to o tom jak počítače doopravdy fungují a tak dále. To má rozhodně cenu. Vzdělávání ve všeobecných znalostech má cenu. Ne zaměření se na znalosti učené pro jednu nestandardní technologii.

Ostatně ono se to dá krásně kvantifikovat:

• Kolik času potřebuje člověk aby se opravdu efektivně naučil Twig, Blade, či Latte? Kolik času je na člověka a kolik na tým?
• Kolik času je třeba věnovat novým členům týmu ze strany tzv. seniorů?
• Kolik času přináší kontrola zda dané technologie jsou používány správně?
• Kolik času přináší komplikace v případě, že se daná technologie živelně změní?
• Kolik strojového času a prostředků serveru ta technologie “sežeře”? (perpetum mobile neexistuje – tomu nevěřte)
• Kolik je to v přepočtu na peníze? (času zjištěné třeba monitoringem a reportingem x hodinová sazba = cena kolik mě to stojí)
• A na druhé straně: Co za to dostanu? Tedy kolik mi to ušetří času a tedy peněz? Jsem ve finále v plusu, nebo mínusu?

Tedy nejde o to, že někoho napadne udělat další “super-boží-cool” šablonovací systém. Jde o to, jestli se to alespoň zaplatí a ideálně nějakou tu zlatku vydělá.

Obávám se, že tady jsme drsně v mínusu. A na takové věci nedám ani korunu …

4) Žádné nestandardní datové formáty a podobné věci …

Různé YAMLy a podobně …  

Co na to říct? Opět: TCO, TCO, TCO … Viz předchozí bod.

A nebo víte co? Názorně malá etuda:

Přijde za mnou kolega a povívá: Mirku! Uděláme si vlastní datový formát! Třeba na konfigurace a tak …”

Já: “OK, ale nejsme univerzita. Nemáme žádný výzkumný program. Co nám to přinese?”

Kolega: “Bude to lépe čitelné pro lidi!”

Já: “Počkej … Od kdy koncový uživatel má co číst konfiguraci?”

Kolega: “Ne, pro ně ne … Pro nás!”

Já: “Kolik času na projektu trávíš tím, že se hrabeš v nějaké konfiguraci?”

Kolega: “No … Nevim přesně …”

Já: “Řekl bych že moc ne, ale dá se to změřit. Tak to když tak zjisti. Pokud by to ušetřilo hodně času, tak by to bylo super. Ale já se obávám, že jsou to minuty … Přece jen mám už nějaký ten pátek vyvojařiny za sebou … Ale pokud se pletu, dokaž mi to. Rád se nechám poučit o svém omylu. Ale chci čísla a ta si chci ověřit.”

Kolega: “No jo no …”

Já: “No a kolik to bude stát?”

Kolega: “Nic hroznýho! Už jsem si s tím hrál. Mám parser, trvalo to pár hodin …”

Já: “No dejme tomu … A co to další?”

Kolega: “Jo, zase to tvoje TCO, žejo?”

Já: “Přesně tak … Kolik času bude stát naučit to ostatní? Kolik tam předpokládáme chyb? Jak to případně ovlivní výkon našich aplikací? Máš to změřené? A bude to dobře čitelné v IDE, které používáme, nebo si budeš hrát i s nějakým pluginem pro IDE? A co Franta a Honza? Ti mají jiné IDE. Zvažoval jsi to? Máš na to všechno čísla? Dělal jsi komparaci s technologiemi, které již máme k dispozici? Jak to vychází? Jak to vychází technicky i finančně?”

Kolega: “#@%$%@#%#$ ach jo … %@%#$%#%”

Já: “Nezlob se, ale jde o to, aby každý z nás zaplatil bydlení a fajn život pro naše rodiny … Vážím si tvé inteligence a nesporných schopností, ale mnohem víc nám pomůže na něčem, co bude podle TCO v plusu. Máme tu spoustu jiných výzev. A uvidíš, že jiné výzvy jsou nejen zajímavé, ale mohou být i super zaplacené. Ale díky za tvůj nápad … Pokud přijdeš s čísly co mi nevyvratitelně omlátíš o hlavu, tak beru.”

To je prostě realita. Existují otravové, kteří mají tento pohled na věc a je to legitivmní. A já jsem takový otrava co kazí zábavu. Žijeme v kapitalismu (díky Bohu!) a o peníze jde až v první řadě.

Ostatně … Technické srovnání pitvající celou úvahu jsem také dal do dokumentace.

5) Modulární architektura, mikro-aplikace

Na to že velký projekt prostě musí být nějak rozdělen již všichni přicházejí. Např. pro Laravel (a nejen pro něj) jsou různé balíčky.

Hodně se mluví o architektuře mikro-služeb, kde by někteří nejraději pustili každou třídu (záměrně torchu přeháním) na vlastním virtuálním serveru …

Dá se o tom hodně debatovat (např. o tom co je efektivní a co může být již kontraproduktivní), ale jistá je jedna věc: Projekt od určitého rozsahu nemůže být tvořen jako monolit … To je prostě neudržitelné.

Mimochodem … To je jedna z věcí, které na jiných frameworcích nechápu. Například ona definice rout. Nedokážu si představit takový routes/web.php pro velký projekt … (nehledě na to množství operací při samotné inicializaci aplikace …)

Prostě a jednoduše: Říkejme tomu jak chceme, teoretizujme jak chceme, ale rozdělení velkých projektů na malé části potřebujeme.

A přesně to je integrální součástí frameworku PHP Jet.

Vše se od začátku přirozeně rozpadá a rozděluje do jednotlivých kopoment a modulů. Je to samotný návrh architektury.

Běh aplikace postavené na Jetu je vlastně jako průchod grafem, kde se požadavek dostane efektivně k těm komponentám aplikace, které jsou pro danou situaci relevantní.

No a možnost jednoznačně určitě kde má kdo pracovat a za co zodpovídá? Možnost vědět co nasadit? Co testovat? A nebo znovu používat celé kompomenty a to velice jednoduše? Já bych řekl, že to je celkem fajn …

6) MVC pojaté jinak …

Jak jste měli možnost vidět, tak PHP Jet nemá žádnou hromadu routovacích pravidel na „jedné hromadě“ a podobně. Nejen že to jde proti modularitě (například), ale tento přístup ani nevystihuje reálnou podstatu webových aplikací.

Ano, také jsem cca 13–15 let zpět měl období, kdy jsem koketoval s aplikacemi tvořenými jednou stránkou, s hromadou JavaScriptu. Ale tudy cesta nevede.

Ovšem pozor! Například pro střih videa jsem si našel jednu super webovou aplikaci a to je jedna stránka s hromadou JavaScriptu a podobnou věc by ani jinak udělat nešlo – prostě správný přístup na správném místě.

Ale věci jako jsou právě e-shopy (včetně jejich administrace, kde jsou desítky nástrojů) jsou tvořeny velkým množství zcela odlišných stránek, na nich běží různé prvky a to vše je mezi sebou provázané navigací a celkovým uspořádáním. Velký celek je tvořen řadou různých komponent. Stejně jako reálný stroj (třeba auto: motor, nápravy, převodovka, elektronika – každý prvek je o úplně něčem jiném, ale společně tvoří celek)

To je realita. Web je tvořen stránkami – samozřejmě již dynamickými, ale stránkami. Mezi nimi je nutné navigovat a tak dále. Ale stále jsou to stránky s hromadou aspektů ne nějaké routy (i když třeba pojmenované) nevystihují stoprocentně podstatu dané věci.

No a v neposlední řadě jsme v Evropě (díky Bohu!). Tedy věci jako lokalizace, překlady a tak dále potřebujeme a budeme potřebovat stále víc … Tak proč to nemít již v základu architektury?

7) Využívání nesporných přínosů OOP a ne užívání dobrých návrhových vzorů na nesprávných místech …

Ano, ano. Na toto téma už jsem tu psal několik článků. Ale místo teoretizování a debatování jsem raději připravil praktickou ukázku. To mi připadá efektivnější.

V posledních letech jsem často zaznamenal kritiku objektově orientovaného programování samotného. Mimochodem toto je zajímavý text.

Jako by OOP pro některé byl sám Satan. Jasně, jako všechno OOP není univerzální spása na cokoliv. Prostě v technice platí, že správný problém vyžaduje správný nástroj. Jasně že matku na šroubu taky povolím kombinačkami, ale nebude to žádná příjemná práce (budu se s tím “mordovat”) a tu matku dosti “ožvejkám” a tedy znehodnotím.

Ale jsou účely, pro které je OOP přímo stvořené. A ano, je to velká část projektů (ne nutně všechny) v našem oboru.

Ovšem problém nastal tehdy, když někdo někde začal razit kouzelné termíny typu “pěkný kód”, “čistý kód” a začal všem tvrdit, že toho “čistého kódu” dosáhnete právě tak a tak.

Co je to vůbec ten “čistý kód”? Ne, nepřekvapím vás. Jasně že to je kód přehledný. Jasně že to je kód znovu použitelný. Jasně že to je kód testovatelný. To je vše bez debat a to chceme, protože jsou to jednoznačně pozitivní faktory.

Ale jak zjistím, jestli je kód opravdu “čistý”? Kouknu do hvězd? Budu slepě následovat něco co někde někdo někdy napsal a třeba i v úplně jiném kontextu v naději že tak získáme onen “čistý kód”? Absolutně ne!

Je to jednoduché:

Čistý kód = kód mající dobré TCO.

Jo … Už jsem tu s tím TCO zas. Jenže ono měření TCO nemusí být žádná věda. Bohatě stačí to, že místo efektivního vytváření nové funkcionality pro klienty trávíme čas pátráním jak to či ono udělat aby to vyhovělo nějakému dogmatu. Už v tuto chvíli je jasné, že TCO jde … vy-víte-kam … Jak něco nejde hladce, ja jasné co se děje s TCO a tedy i s faktickou kvalitou aplikace. Jak je moc zádrhelů, moc neproduktivního času, tak ani není nutné šermovat s tabulkami kolem TCO a ani žádnou enciklopedickou znalostí různých pouček … Časté řešení toho co nevede přímo k cíli = utíká nám čas a peníze.

OOP je super. Ale účelem jeho vzniku bylo učinit naší práci na rozsáhlejších projektech efektivnější. Pokud OOP neplní daný účel, tak je objektivně prostě špatně používáno – prostě neplní to k čemu je určeno (nebo je použito na nevhodném místě).

Je to úplně stejné jako ono již zmíněné nesystematické použití kombinaček na povolování matek. Jde to a někomu může připadat fakt cool že místo sady klíčů stačí jedny kombinačky. Ale je to prostě špatně a to z objektivních a ne subjektivních důvodů.

A framework (jakýkoliv) má poskytovat pomyslné sady klíčů a má nechat na odbornosti, zkušenostech a potřebách vývojáře jaký postup a nástroj zvolit. Vývojář to bude vždy vědět líp než autoři frameworků, protože žádný autor žádného frameworku nikdy neviděl a neuvidí tak  širokou škálu projektů a výzev které projekty přinášejí. Nehledě na to, že řada autorů frameworků se již z práce pro klienty vymanila a jsou mimo tuto praxi … Tedy: framework má být něco, co vám nabízí ony pomyslné sady klíčů i kombinaček a nechá na vaší odbornosti co a jak použít. Framework vás nemá vést či snad vychovávat. 

(Poznámka: Považuji za nevhodné, když se nováček v oboru začne učit rovnou nějaký framework. Podle mého názoru by se programátor měl nejprve naučit prostě programovat. Bez ohledu na framework.)

Jak je kód “čistý” je již samozřejmě na vývojáři a jeho zkušenostech a schopnostech. Sebelepší nářadí dobrého řemeslníka nedělá a vice versa. 

A pochopitelně s „nářadím“ je nutné se seznámit. Ne že ne.

V ukázce bylo jasně patrné, že lze efektivně vytvořit modulární aplikace, ve kterých si mohu dlouhodobě během životního cyklu projektu s jednotlivými prvky “hrát”, modifikovat je, nebo zcela vyměňovat, ale třeba i je opětovně použít na jiných projektech. To je OOP. To je to co potřebuji. Tedy troufám si drze tvrdit, že zde OOP plní svůj účel.

A jde to jednoduše, přímočaře, efektivně, s využitím jen a pouze standardních technologií a postupů, bez dogmat a “hackování”.  

A to je vše … Ještě to video :-)

Pochopitelně zde je poslední díl této reality show:

PS:

PHP Jet už má podporu MS SQL v ORM a vylepšené UI Jet Studia. Vše bude součástí květnového vydání.

Mějte se krásně!