Ahoj,
to že oop v php vládne je už pár let jasné, mám takový pocit, že jsem jedním z mála "exotů" co ještě píše procedurálně, zajímalo by mě, jestli je to pravda, nebo jsem podlehl nějaké iluzi jedinečnosti.

Zajímá mě, jestli vy sami (nebo někdo ve vašem okolí) píše kód postaru. Mám na mysli alespoň pokročilé programátory - tzn žádný tisíc+ řádkový soubory, žádné php v html, sql dotazy v šabloně, 100Kč/h sazba a podobně.

Osobně v php dělám cca 6let, ve vývoji cca 10let, produkuju aplikace rychlé, bezpečné, nejsem lepič ani špageťák, vím jakej je rozdíl mezi nullováním a unsetem atd. Můj kód je rozdělený podobně jako mvc, s daty pracuji podobně jako v oop (pole a nad tím funkce), přejít na oop by nebyl problém, ale tímhle stylem se mě osobně pracuje lépe, přijde mi to přímočařejší, jednodušší, mám z toho zkrátka lepší pocit.

Pokusy o přechod byly, zkoušel jsem čisté oop, různé frameworky (nette, symphony, codeignter) - u každého jsem si napsal větší či menší aplikaci, vyzkoušel nástroje a využíval výhody daného řešení, ale vždy převládl vnitřní pocit, že tohle není ten způsob, jakým chci pracovat. Dost mi taky vadí jedna věc - když jsem zkoušel nette tak na hello world stránce mi tracy hlásila 6MB memory peak a představa, že než se spustí první řádek samotný aplikace je využitý víc paměti než by stačilo na celou aplikaci mi nedělá úplně dobře na moji šetřivou duši.

Moc dobře si uvědomuju výhody jak oop, tak frameworků - mnoho fičur a postupů jsem implementoval do svých modulů.

Krom toho, že bych rád věděl, kolik nás procedurálních punkerů je, zajímala by mě ještě jedna věc. Pokud byste dokázali odhlédnout od dogmatu, že oop je jedinná správná cesta pro všechny a na všechno, vidíte v procedurálním přístupu k vývoji nějaký problém? Častým argumentem je to, že při bobtnání aplikace dochází v procedurálním kódu k chaosu, to je pravda, před pár lety jsem s tím měl hodně problémů, ale podařilo se mi to vyřešit správným návrhem struktury aplikace - mimojiné poučením se z objektových návrhů a řešením frameworků, nyní s tím nemám problém a nedostavuje se dříve mi věrně známý pocit chaosu.

Podělte se prosím o vaše názory a zkušenosti
Díky, brooks.

V PHP jsem psal něco naposled tak před deseti lety, navíc jenom menší úpravy existujícího. Nicméně pokud dokážeš psát kvalitní aplikace, které dobře fungují a jsou udržovatelné tak je tak klidně piš i nadále. Osobně mě vždycky chytá hrůza, když vidím aplikace, které jsou takzvaně dobře napsané je tam spousta balastu kolem, jenom prostě proto aby to bylo dle best practices a používaly se ty správné design patters a pak aplikací trvá hodinu než se vůbec spustí. A když na ní nastoupí nový vývojář, tak mu trvá měsíc než se trochu zorientuje a další půl rok než se do toho pořádně dostane. Za mě - hlavně ať je přehledný kód, který dobře pochopí i člověk, který to vidí prvně a ať ta aplikace běhá svižně a bez problémů. Pak budou spokojeni všichni.

Heled taky sem driv psal MVC framework, ktery nepouzival objekty a byl proceduralni a slo to... Jenze je to cle takove kostrbate, objekty sou ciste, jasne, strukturovane, proto se pouzivaji... On je taky rozdil kdyz to pises a nasledne udrzujes sam a kdyz na tom ma pracovat tym lidi... Tym lidi zkratka ajenodduse nemuze psat proceduralni kod aniz yb se z toho casem vsichni nezblaznili, stejne jako je dost "sebestredne" psat proceduralni kod s tim, ze vim ze ho v budoucnu bude nekdo upravovat - pokud to pises pro ostatni, je proste potreba dodrzovat nejakou konvenci, ne protoze je to spravnejsi z hlediska technickeho, ale protoze je to spravnejsi z hlediska budouci udrzitelnosti...

Heled taky sem driv psal MVC framework, ktery nepouzival objekty a byl proceduralni a slo to... Jenze je to cle takove kostrbate, objekty sou ciste, jasne, strukturovane, proto se pouzivaji...

Tady souhlasím částečně, procedurální kód nemusí nejasný, nestrukturovaný, sic je pravda, že oop svým návrhem tomu dost brání, ale že by nešlo napsat nejasný a nestrukturovaný objektový kód? To si nemyslím i vzhledem k vlasní zkušenosti když jsem se oop kdysi učil.

On je taky rozdil kdyz to pises a nasledne udrzujes sam a kdyz na tom ma pracovat tym lidi... Tym lidi zkratka ajenodduse nemuze psat proceduralni kod aniz yb se z toho casem vsichni nezblaznili, stejne jako je dost "sebestredne" psat proceduralni kod s tim, ze vim ze ho v budoucnu bude nekdo upravovat - pokud to pises pro ostatni, je proste potreba dodrzovat nejakou konvenci, ne protoze je to spravnejsi z hlediska technickeho, ale protoze je to spravnejsi z hlediska budouci udrzitelnosti...

Tady máš určitě velikou pravdu, v době kdy oop je mainstream nutit někoho dalšího k práci v procedurálním je špatnej nápad a určitě by to nefungovalo, naštěstí nepíšu oss, projekty se nikam dál nepouští a pokud pracuje více programátorů tak vždycky jsme na jedné ideologické vlně, takže procedurální programování vyhovuje. S budoucími úpravami/udržitelností nemám problém díky tomu, že jsem přejal dobré přístupy z oop - aplikace nejsou klasický procedurální monolit.

Každopádně díky za reakci, je to hodně silný argument a v případě oss, nebo nějakého většího/různorodějšího týmu programátorů je oop určitě jedinná správná cesta.

-- 09. 05. 2017 15:25 --

matejka píše:
V PHP jsem psal něco naposled tak před deseti lety, navíc jenom menší úpravy existujícího. Nicméně pokud dokážeš psát kvalitní aplikace, které dobře fungují a jsou udržovatelné tak je tak klidně piš i nadále. Osobně mě vždycky chytá hrůza, když vidím aplikace, které jsou takzvaně dobře napsané je tam spousta balastu kolem, jenom prostě proto aby to bylo dle best practices a používaly se ty správné design patters a pak aplikací trvá hodinu než se vůbec spustí. A když na ní nastoupí nový vývojář, tak mu trvá měsíc než se trochu zorientuje a další půl rok než se do toho pořádně dostane. Za mě - hlavně ať je přehledný kód, který dobře pochopí i člověk, který to vidí prvně a ať ta aplikace běhá svižně a bez problémů. Pak budou spokojeni všichni.

Poslední dobou mě děsí módní přístup do aplikace cpát co nejvíc technologií který jsou zrovna cool, ne proto že by byly nějak extra potřeba, ale proto že machrovat s tím, že aplikace jede na xyz, zyx, abc je prostě hustý, pak samozřejmě na frontend nacpat alespoň patnáct js knihoven, tři css extension a pořídit pár dediků aby se to alespoň rozjelo.

S předposlední větou naprosto souhlasím a dodržuju, vlastně musím, pokud backend aplikace běží déle než 100ms, mám z toho málem trauma a pokud bych se po roce vrátil ke kódu, po přejetí očima bych musel přemýšlet jak ten kód funguje nebo co dělá a musel se dívat do dokumentace, měl bych další.

brooks píše:
Poslední dobou mě děsí módní přístup do aplikace cpát co nejvíc technologií který jsou zrovna cool, ne proto že by byly nějak extra potřeba, ale proto že machrovat s tím, že aplikace jede na xyz, zyx, abc je prostě hustý, pak samozřejmě na frontend nacpat alespoň patnáct js knihoven, tři css extension a pořídit pár dediků aby se to alespoň rozjelo.

Jo, tohle osobne uplne nenavidim, nedavno se mi to snazil nekdo vysvetlit a uznavam, ze v urcitych pripadech ma tohle vsechno samozrejme i smysl, ale pokud napriklad programuju jednoduchy formular s nekolika kroky a potrebuju na to angular s deseti knihovnami, bootstrap s nekolika rozsirenimi a jeste tunu divneho nekomentovaneho kodu (to jen popisuju neco s cim sem nedavno musle pracovat) tak proste neni neco v poradku, vazne ne :) Nicmene tenhle pristup ma mnoho nespornych vyhod, ale chce to pouzivat mozkem, ne to jen tupe srat uplne vsude a jeste nejlip jako copy paste z nejakych tutorialu :) To mimochodem plati i o prilisnem naduzivani slozitych OOP navrhovych vzoru... Vzdycky se musim smat kdyz otevru knihovnu co ma 30 souboru a ve skutecnosti to dela neco co by zvladla funkce o par radcich... Ale tak nekdo se v tom proste vyslovene vyziva... A ve vysledku to funguje...

Z hlediska dlouhodobé udržitelnosti se OOP jeví skvěle, ovšem s ohledem na relativně krátkou životnost frameworků, jejich překotný vývoj a vývoj i samotných jazyků to zas tak jednoznačné není. Primitivní procedurální kód napsaný v roce 2003 běží pořád, 5 let starý framework ne.

OOP bohužel děsně svádí k "modulárnímu vývoji" (jak já tomu říkám) - prostě tady nacpu tuhle knihovnu, tady tuhle, natáhnu si tady CSS a tady 3x JS a buch došla paměť... Je to strašně složité, každý framework má milion různých nesmyslů, které z něj nejdou snadno vykuchat a vše se řeší sice formálně až dokonale, ale za cenu šílené režie. Názorně, jeden můj starší projekt přepsaný do OOP znásobí spotřebu paměti asi 10x, v laravelu je to ještě víc.

Na složité věci je OOP často jediné rozumné řešení, zejména u většího týmu. Ale rozhodně to není bezproblémové, snadné, lehce udržovatelné atd. Kolikrát vznikne modulární slepenec, který se v určité chvíli už velmi těžko aktualizuje (tady se nám pere DB a PHP, tady to zase nesežere tenhle JS, tahle knihovna neumí nové PHP...).

O módních technologiích škoda mluvit, hlavně hned všecko předělat a překopat, aby se to mohlo za 2 roky měnit zase...

Jedna z výborných ukázek je Wordpress - napsaný kdysi na velmi odlišném PHP a MySQL od těch dnešních. V současnosti by v podstatě potřeboval úplně přepsat, což ale půjde těžko, když na tom běží cca 40 % webů... WP by to přežil, ale kvadrilión existujících šablon a pluginů by to odpálilo.

basti píše:
OOP bohužel děsně svádí k "modulárnímu vývoji" (jak já tomu říkám) - prostě tady nacpu tuhle knihovnu, tady tuhle, natáhnu si tady CSS a tady 3x JS a buch došla paměť... Je to strašně složité, každý framework má milion různých nesmyslů, které z něj nejdou snadno vykuchat a vše se řeší sice formálně až dokonale, ale za cenu šílené režie. Názorně, jeden můj starší projekt přepsaný do OOP znásobí spotřebu paměti asi 10x, v laravelu je to ještě víc.

Jo.... to je ten duvod proc mam napsany svuj framework, cisty, jendoduchy, primocary, s co nejmensim provazanim jendotlivych casti :) A to je ten duvod proc na me proad vetsina lidi kouka jako na blazna, protoze vetsina je zvykla presne takhle lepit kod a uz vlasten ani poradne neprogramuji, jen slepuji... A co je trochu zarazejici aspon pro me, ze spousta firem kde sem se kdysi uchazel o misto me sama presvedcovala ze to co delam je zasadne spatne a ze ztracim cas :) tak sem na to rekl ze ztracim, ale tim ze jsem sel k nim na pohovor... Nastesti to tak neni vsude, proste jem v tom "mainstreamu" kde se weby sekaji jako cvicky u bati...

No ono je nejsmutnější, že stejným stylem jsou zflikované i zásadní technologie či jádro mnoha OS => dlouhodobě neudržitelné, značně nestabilní a hlavně děravé jako řešeto. Méně je více. Raději jasně specifikovaná a omezená funkčnost, ale perfektní výkon, bezpečnost a stabilita. Trend je ale přesně opačný - čas jsou peníze a co nejrycheji zflikovat nějaký bastl.

Tady potřebujeme toto, no vlastně by to chtělo přepsat pořádně, ale hoří termín, tak to tady naprasíme, toto přiohneme... a za rok do toho někdo sáhne a celé se to rozsype. Holt jak se říká, existují programátoři, ale většina lidí jsou jen lepiči kódu...

Ne vždy je procedurální kód špatný. Třeba pro malé projekty je to výhodnější.

Jinak co je špatně na tisíc+řádkovém souboru? Pokud je ten soubor dobře strukturován, tak je přehledný.
Nemám rád, když je na každou banalitu x desítek souborů o 1 kB.

Otakar Pěnkava píše:
Ne vždy je procedurální kód špatný. Třeba pro malé projekty je to výhodnější.

Jinak co je špatně na tisíc+řádkovém souboru? Pokud je ten soubor dobře strukturován, tak je přehledný.
Nemám rád, když je na každou banalitu x desítek souborů o 1 kB.

Špatně jsem to napsal, původně jsem chtěl napsat něco ve smyslu tisíciřádkový metody nebo celé aplikace v jednom souboru a vzniklo z toho tohle :-). Ale i tak, tisíc řádků na soubor je už celkem dost, hůř se v tom orientuje, ale často není zbytí. Stále mnohem lepší než zbytečný dělení na xyz pidi souborů o pár řádcích.

Trend je ale přesně opačný - čas jsou peníze a co nejrycheji zflikovat nějaký bastl.

Pro mě je vývoj řemeslná činnost, chci si s tím kódem hrát, chci ho vytvářet, ne lepit. To že bych si mohl práci ulehčit a sázet jeden projekt za druhým jak ve fabrice někomu může připadat fajn, ale já to dělám protože mě to baví a to je koneckonců hlavní důvod toho že to dělám a taky důvod toho proč to tak dělám.

Tohle přirovnání je sice trochu přitažený za vlasy, ale když zavzpomínám, tak před lety se weby dost často dělaly tím způsobem, že se do googlu dalo "anketa v php", "počítadlo v php" atd, nahodilo se na ftp a pak všude machrovalo jak super to programování je. Pak přišla móda redakčních systémů (která je tu ve formě wp, joomly atd bohužel dodnes), stáhnul se zip, nahodil na ftp, naklikaly se pluginy a hle jsem profi vývojář protože dělám weby. Při zavřených očích mi programování nad frameworkem přijde trochu podobný, nahodim framework, mám hotový routování, bezpečnost, formuláře, databázi a vlastně všechno co potřebuju tak to slepim dohromady a hle, najednou všechno umim, sice moc netušim jak to php funguje, jak ten framework funguje, ale programuju.

Na druhou stranu to není jen móda, ale přirozený vývoj. Ten obor se zjednodušuje tak aby to zvládl každý, což má určitě pozitiva i negativa.

Z hlediska dlouhodobé udržitelnosti se OOP jeví skvěle, ovšem s ohledem na relativně krátkou životnost frameworků, jejich překotný vývoj a vývoj i samotných jazyků to zas tak jednoznačné není. Primitivní procedurální kód napsaný v roce 2003 běží pořád, 5 let starý framework ne.

Tohle jsem vůbec nebral v potaz, díky za zajímavý postřeh.

Primitivní procedurální kód napsaný v roce 2003 běží pořád, 5 let starý framework ne.

Jeste mi neda nereagovat na tohle - to totiz neni plne pravda, i 20 let stary framework samozrejme bude fungovat, problem je spis v tom, ze verejne frameworky maji taky verejne diry a je tedy nutne je kvuli bezpecnosti aktualizovat a to nejde vzdy jednoduse, je to jeden z mnoha duvodu proc delam svuj framework bez verejneho kodu, tedy tak, aby pripadne chyby nebyly alespon komukoliv na ocich a zivotnost takoveho kodu tedy byla v podstate stejna jako proceduralniho. To jen spis na upresneni, proc to tak vlastne je a proc je dle meho nazoru vyvoj svych reseni vyhodny pred pouzitim hotovych open source reseni.

Samozrejme ze to zabere nejaky ten cas navic, ale mnoho "lepičů" by mozna bylo prekvapeno ze to zase neni az tak tragicky hodne navic a vyhod je mnoho... Pri zachovani nejakych beznych navrhovych vzoru pak nemuze mit ani problem kdokoliv se s tim velice rychle naucit, pokud uz s jinymi frameworky delal...

Alesi píše:

Jeste mi neda nereagovat na tohle - to totiz neni plne pravda, i 20 let stary framework samozrejme bude fungovat, problem je spis v tom, ze verejne frameworky maji taky verejne diry a je tedy nutne je kvuli bezpecnosti aktualizovat a to nejde vzdy jednoduse, je to jeden z mnoha duvodu proc delam svuj framework bez verejneho kodu, tedy tak, aby pripadne chyby nebyly alespon komukoliv na ocich a zivotnost takoveho kodu tedy byla v podstate stejna jako proceduralniho. To jen spis na upresneni, proc to tak vlastne je a proc je dle meho nazoru vyvoj svych reseni vyhodny pred pouzitim hotovych open source reseni.

Samozrejme ze to zabere nejaky ten cas navic, ale mnoho "lepičů" by mozna bylo prekvapeno ze to zase neni az tak tragicky hodne navic a vyhod je mnoho... Pri zachovani nejakych beznych navrhovych vzoru pak nemuze mit ani problem kdokoliv se s tim velice rychle naucit, pokud uz s jinymi frameworky delal...

Myslím že to basti myslel tak, že pokud si na php7.1 spustíš starý primitivní procedurální kód tak bude fungovat, ale stačí pár updatů frameworku a bez úprav se nerozjede.

brooks píše:
Myslím že to basti myslel tak, že pokud si na php7.1 spustíš starý primitivní procedurální kód tak bude fungovat, ale stačí pár updatů frameworku a bez úprav se nerozjede.

Nemusí být pravda. PHP se v průběhu let vyvíjí a kód psaný pro staré verze, nemusí v těch nových fungovat. A to jednoduše - může mu vadit to co frameworku. U procedurálního kódu se spíš naráží na to, že je menší, takže případné chyby si člověk opraví sám než v případě použití nějakého robustního frameworku.

Otakar Pěnkava píše:

Nemusí být pravda. PHP se v průběhu let vyvíjí a kód psaný pro staré verze, nemusí v těch nových fungovat. A to jednoduše - může mu vadit to co frameworku. U procedurálního kódu se spíš naráží na to, že je menší, takže případné chyby si člověk opraví sám než v případě použití nějakého robustního frameworku.

Určitě, ale jak obsáhlé změny jsou v samotném php a jak obsáhlé změny se běžně dějí ve frameworcích? To určitě nelze srovnat. Není to tak dávno, když jsem spouštěl svojí appku z roku 09 na rc verzi php7, během pěti minut bylo fixnutý mysql_* a všechno běželo bez problému. To že se sem tam nějaká funkce zahodí je přirozené, ale ty primitivní konstrukty o kterých byla řeč jsou a budou stále stejné právě kvůli zpětné kompatibilitě a to není u mnohých frameworků vůbec samozřejmé.