Vlákno názorů ke článku PHP Jet - Dependency Injection, továrny a tak dále od Mirek Marek - Díky za zajímavou diskuzi, Udělám si čas a projdu...

Díky za zajímavou diskuzi,
Udělám si čas a projdu to.

Ale souhrnně bych rád řekl jednu věc. Jsem technik. Vzděláním i celoživotní praxí. A krom toho hodně dlouho i manažer.

S veškerou úctou ke všem názorům ... Názory mě zajímají, protože mne mohou nějak posunout. Od toho názory jsou.
Ale pro vyhodnocení správnosti názorů znám v mém oboru pouze jedno kritérium:

Čísla!

Tvrdá a ověřitelná čísla. Programování je technický obor. Není to grafika, kde máme subjektivní pojmy líbí / nelíbí.

V technice jsou rozhodující fakta a fakta jsou v technice reprezentována čísly.
Tedy nezajímá mě jestli je něco dobře nebo špatně subjektivně, ale jen a pouze objektivně.

Jaká lze v našem oboru stanovit KPI?
* Kolik času zabere realizace dané úlohy?
* Jak je použitelná odvedená práce a kolik tedy ušetří času?
* Kolik času musí třeba nový člen týmu strávit učením se něčeho? (například šablonovacího systému atd)?
* Jak rychle "běží" reálná aplikace?
* Jak je možné na projektu pracovat v týmu a kde jsou riziková místa kolizí?
* Jak technologie umožňuje samostatnou práci, ale i kooperaci?

= celkově vzato: Jak bude vývoj a práce efektivní?
To se dá změřit. Na to jsou postupy. A použitá technologie v komerční praxi musí v první řadě toto zohledňovat.

To je reálná praxe. Obávám se, že různí aktivní teoretici jsou od praxe tak trochu odtrženi ...

Tedy při vší úctě: Nezajímá mě slovíčkaření. Nezajímá mě teoretizování.
Zajímají mě případové studie vyjádřené ve financích.

Tedy kolik daný postup vývoje a daná technologie ušetřila peněz, jak zlepšila efektivitu.
Ano ... Musím to říct: Zajímají mě peníze. Protože za naše programování nám někdo platí. A ten někdo nás platí, aby sám vydělal peníze.

Tedy: Pokud mi chcete dokázat, že je něco "lepší", tak mi to prosím transparentně přepočtěte na peníze a ukažte na konkrétním případu.

Já mohu z praxe oponovat mnoha případy, kdy konkurence nechápala, jak je možné něco vytvořit lépe a levněji, než to dokáže ona.

Díky za reakci. To, co jste napsal, se ale nijak nevylučuje s kritikou, kterou vám tady napsali jiní (včetně mě).

Naprosto věřím, že při vývoji projektů typu, na kterých pracujete, jste si postupně vyvinul sadu nástrojů, která vám práci zefektivňuje. To se stává běžně, ve vašem případě tato sada nástrojů je Jet, a práci vám usnadňuje, zdá se, až extrémně. Je to velmi dobrý nástroj na zefektivnění vývoje projektů tohoto typu. Ale není to obecný framework, je to spíše "lightweight CMS", a na projekty jiného typu se zdaleka tolik hodit nebude.

Vaše čísla jsou prostě měřená na malém vzorku dat - pouze na projektech, které jste v Jetu vyvíjel a při vývoji kterých se postupně vylepšoval. Tam opravdu může vycházet lépe než cokoliv jiného a nijak to nerozporuju.

Ale například u větších projektů opravdu nezáleží na tom, jestli kostru třídy s entitou Product mi Jet Studio vygeneruje za 2 minuty nebo ji napíšu ručně za 10 minut. To absolutně není to místo, kde se stráví největší množství vývojového času. U úplně malých projektů "napiš a zahoď" zase možná dokonce bude lépe vycházet čistý špagety kód.

Takže obecně mám v článcích problém hlavně s používáním absolutních kvalifikátorů typu "takhle je to správně", "tohle je mýtus", "je lepší mít všechno v jedné třídě", "Jet je intuitivní" (například toto tvrzení vy jakožto jeho autor nejste schopen posoudit vůbec - pro mě například intuitivní není ani trochu).

Každopádně za články díky, vždycky se na ně těším - i když s filozofií Jetu nesouhlasím a nikdy ho používat nebudu, tak je vždycky zajímavé vidět, jak se věci dělají "jinde".

Pane kolego, já dělám pouze velké projekty. Opravdu hodně velké.
Malých projektů jsem za kariéru moc neudělal.
Jsem si naprosto jistý, že i Vy jste někdy někde narazil na to, co já jsem dělal.

A nejsou to projekty charakteru prezentační web, mnohem častěji informační systémy, e-shopy (a hlavně nástorje pro ně) a tak dále.

Stejně tak se potýkám s tím, že jsem si svou práci vždy musel obhájit. A to jako šéf celého oddělení a de facto části firmy, nebo teď když jedu "sám na sebe".

Já neteoretizuji. Za ty desítky let prostě vím co se v praxi na opravdu velkých a dlouhodobých projektech (bavím se i projektech i pro velké korporace) opravdu vyplatí a co funguje.

Proto chci, aby jakýkoliv technický argument byl podložen čísly a to čísly převedenými na finance. To mě zajímá.

Protože právě to jsem mockrát obhajoval. A opakuji že i na úrovni obřích korporací.

Stejně tam mám zkušenosti se spoluprací se slušnou řádkou kolegů, s projekty na kterých pracovala celá řada lidí a tak dále.
Tedy když něco tvdím, tak to vím. Vím to z praxe. Vím to z úspěchů i nezdarů. Vím to z toho, co jsem zažil.

Jet je obecný framework. Pouze je tak efektivní, že už ve svém malém základu má vše, co na reálných projektech potřebujete.

Obávám se, že zde posuzujete a hodnotíte něco, co jste vůbec nepochopil a patrně ani pořádně nenastudoval.

Já mám tu "drzost" psát "tohle je mýtus", protože to prostě mohu dokázat na reálné praxi. Vím to z každodenní reality.

Vy tvrdíte o obecném frameworku, že je to CMS. Při tom je to mnohem obecnějši a flexibilnější framework, než Nette, Laravel a Symfony dohromady.

Prosím více si to prostudujte a vyzkoušejte. Tomu jste se bohužel moc nevěnoval.

A pak si s Vámi klidně rád někde sednu a porovnáme si čísla. Tedy jaká konkrétní sitauice je v čem jak konkrétně řešitelná a jak to umožňuje dodat klientovi v čas a v rozpočtu projekt a o ten se následně roky starat.
To jsou pro mě kritéria a rád se o tom budu s kýmkoliv bavit.

Ale na to si opravdu musíte nastudovat o čem to vlastně je. To jste bohužel evidentně zatím neudělal. Budu rád, když to napravíte a bude možné se bavit konkrétně a vše si demonstrovat na reálných sitiacích z praxe.

> Ale na to si opravdu musíte nastudovat o čem to vlastně je.

Jste v poněkud nezáviděníhodné situaci. Prezentujete nástroj/FW, ve které my od praxe poznáváme ty bolestivé zkušenosti, které jsme si museli zaplatit. To, s čím jsme si za drahé peníze prošli, a zjistili že je to špatné, vy prosazujete jako tu správnou cestu. A vaše argumentace je založena na "musíte mi věřit". Můžete se na nás zlobit, ale to je slabé.

Já připouštím, že je možné, že jste dokázal objevit způsob jak to dělat, který je natolik invenční, že se tím DI stane zastaralé. Bohužel se vám to nedaří popsat a vysvětlit. Popisujete způsoby, které z praxe známe, a víme, že dlouhodobě nefungují.

Vy jste ten, který musí dokázat, že jste objevil něco lepšího. Popisujete ale způsoby které známe. V čem je tedy to kouzlo? Kde je ten detail, který z nepoužitelného udělá použitelné?

Možná nevíte, že Nette bylo původně také navrženo podobným způsobem jako máte navržen vy svůj php-jet. Pak se na základě zkušeností zjistilo, že to byla chyba, a dlouhou dobu se to přepisovalo.

Zajímají vás tvrdá data? Jedny vám mohu poskytnout:
Vždycky se objeví nějaký zajímavý projekt, který je rychle rychle vytvořen, bohužel se špatným základy. Chvíli to roste, a dříve či později už to programátoři nedokážou dál udržovat, protože jim schází skill.
Zkušení programátoři se tomu nechtějí věnovat, protože to není příjemné.
A tak si najmou mě, a já jim pomáhám ten kód vzpamatovat. Obvykle to trvá několik let. A jsem drahej.

Možná máte pocit, že toto není problém php-jet. Možná ne. Ale ukázky kódu a principy které prezentujete mě v tom nepřesvědčují. Vypadá to na super práci pro mě za pár let.

Můžete se hněvat, že nemáme pochopení pro vaši myšlenku. A že vám nedůvěřujeme. Možná vám křivdíme. Ale to se nedá nic dělat. php-jet vypadá jako špatný systém, a tak se podle toho budeme rozhodovat.

Tvoje práce zní zajímavě :-) Jak s něčím takovým člověk začne? Když už máš reference, tak si dokážu představit, že je to pohoda, ale jak jsi našel tu první firmu, která potřebovala pomoct? A jak jsi je přesvědčil, že to dokážeš?

Kromě toho, že naprosto souhlasím s tím, co napsali Jan Judas a BoneFlute, tak jenom ve zkratce:

$price = $product->getFinalPrice­WithVAT();

Tohle nevypadá na velký projekt, to se zhroutí už když budu mít zákazníka v jiném státě (jiném daňovém pásmu). Doplňte si tam Brazilský daňový systém a jste totálně v háji. Pokud si tedy neuložíte sourceAddress a zákazníkův shippingAddress (a spoustu dalších detailů, které Brazilský daňový systém ovlivňují) někam do Product před zavoláním funkce, což by v Php fungovalo (neznamená, že je dobrý pattern). Můžete argumentovat, že Brazílie je daleko, ale požadavek na EU je rozhodně běžný.

class Application_Admin ... static init()...

A co když ten modul budu chtít použít někde jinde a jenom změnit logger nebo authentication filter? Jsme zpátky u toho - píšete o velkých projektech, ale nemáte ani kousek reusability.

Rozdíl je právě v tom (jak píše BoneFlute), že vaše verze bude fungovat do nějaké míry a možná bude i rychlejší. Ale jakmile zákazník přijde s netypickým požadavkem, tak konkurence změní komponentu v DI, zatímco v Php-Jet se bude přepisovat kód, který bude fork-em původního kódu odjinud (pokud tam bude vůbec nějaké sdílení), což s sebou přinese šílené náklady vůbec na udržitelnost.

Nezlobte se, ale takovýmhle tónem v diskusi pokračovat nechci. Stále vás považuji za rozumného člověka a nerad bych, aby se diskuse zvrhla v osobní útoky jako např. u pánů dw nebo greenlinuxguru.

Jinak souhlasím s tím, co napsal BoneFlute - pokud sám tvrdíte, že technický argument má být podložen čísly, tak byste to měl udělat. Vy tvrdíte, že "DI je mýtus", ale nepodložil jste to vůbec ničím, pouze vašimi dojmy a pocitem - a to je prostě málo.

PHP ani weby mě neživí, takže čísla, která byste si představoval, vám bohužel nejsem schopen poskytnout. Ale pracuju už 10 na stále stejném produktu v Javě - a části, které byly psány vaším způsobem, vykazovaly pokaždé stejný živostní cyklus: rychle napsáno, ale údržba a přidávání dalších funkcí pak šlo čím dál pomaleji, až se to nakonec zadrhlo úplně a muselo se to přepsat do příčetnějšího návrhu. Části, které používaly best practices jako DI a SRP, sice ze začátku trvaly napsat o něco déle, ale čas na přidání dalších funkcí je konstantní a se zvětšováním projektu se nijak nezvyšuje.

Zdravim na jedne strane pisete ze si zakladate na cislech a faktech pritom ale zadna neuvadite vidim tu pouze dojmy. pisete ze je "obecnejsi a flexibilnejsi nez Nette / Symfony" tak mi prosim ukazte jak jednoduse zmenite DB ne pro celou aplikaci ale pro jednu konkretni komponentu.

Rikate nastudujte si: ale tady neni moc co studovat to co vy prezentujete jako DI je naprosto bezna vec ServiceLocator jak uz tu jini psaly. Na tom paternu neni vubec nic spatneho a sve uziti ma jen to principielne neni nic jineho nez Globalni promena a nese si sebou vyhody / nevyhody s tim spojene.

Pisete:

Měnit třeba parametry konstruktoru v celém projektu, nebo na X velkých projektech? Naprosto nemyslitélné.

To mi prijde ze naopak vy jste neco nepochopil jak funguje moderni DI v projektech jako symfony / nette / Spring protoze zmenit konstruktor je opravdu jenom o tom ze zmenim konstruktor po vetsinou prave na 2 mistech

• Definice servisy
• Predani zavyslosti v unit testech

Nikde jinde s konstruktorem nepracuji vse za me udela DI kontejner a ja mam naprosto volnou ruku. pouzivat vytvaret si instance rucne uz se az na vyjimky proste nenosi a vyzraly DI kontejner za me udela veskerou spinavou praci ja proste jen reknu ze chci v konstruktoru novou sluzbu "Logger" a taky ji tam dostanu tecka a to i kdyz se ma servisa pouziva na dalsich 100 mistech v projeku.

Mimochodem zrovna u testu se opet sam sebe vyvracite:

Jako uživatel třídy neřeším její vnitřní implementaci. Nezajímá mě. Vím jaké má třída vnější rozhraní a to používám.

Jak napisete test na servisu?

class A{
public function doSomething(int $number){

}
}

pokud se uvnitr vola Product::get() ? vy to ani nemate jak poznat.. ale najednou pisete test a musite se podivat do strev dane classy abyjste videl co vsechno potrebuje ke svemu behu coz je v primem rozporu s tvrzenim "neřeším její vnitřní implementaci. Nezajímá mě. Vím jaké má třída vnější rozhraní a to používám."

Ale v jedné věci s Vámi naprosto souhlasím.
Každý nástroj se hodí na něco jiného. To se naprosto shodneme.

Je chybou tahat postupy např. z vývoje desktopových aplikací na do online aplikací a tak dále.

Ovšem opravdu Jet nechápete. Jet je obecný framework pro jakoukoliv online aplikaci.

Ať už je to web, nebo intranet, e-shop, speciální nástroj s webovým UI (viz Easy Deployer), specializovaný informační systém a tak dále.
S tím vším (a troufám si říct že s mnohem víc) jsem se v praxi setkal a Jet je navržený tak, aby tohle všechno na něm šlo vyvinout rychle a efektivně, aby bylo možné pracovat v týmu a zároveň aby bylo možné aplikaci přizpůsobit.

Dá se na tom postavit dobře webík (teda pokud by pro daný účel nebyl lepší třeba Wordpress - nevím, v této oblasti se moc nepohybji), tak aplikace přes kterou tečou stovky milionu korun a kteoru denně používají lidé jako nástroj obživy - své práce.

A vím, že v této oblasti jsou ostatní mě známé frameworky opravdu velice neefektivní. Už z hlediska organizace práci, struktury celé aplikace a tak dále.

Opakuji: pro mne to není teorie, ale denní realita.

Proč si myslíte, že mi ostatní to máme jako hobby? ;-)