Posílám notebook na reklamaci.

Objevil se nepříjemný problém s větrákem, který nadměrně pracuje a hned po spuštění se rozjede ve vysokých otáčkách a nikdy už nezpomalí. Nezáleží při tom na činnosti, stačí zapnout jenom OS. Větrák je namáhán a opotřebováván více, než je třeba, což je doprovázeno nesnesitelným hlukem.

Nikdy není vhodná chvíle na odeslání počítače, takže ho posílám hned a doufám, že se brzy vrátí zpět. Musel jsem připravit pracovní prostředí na netbooku, což znamená wamp s MySQL, Apachem a PHP, které bylo třeba nově nastavit. Dále třeba nainstalovat git a TortoiseGit pro verzování, PSPad pro editaci (nějakou dobu se obejdu bez Eclipsu) a TC jako file manager a FTP klient.

Netbook pochopitelně nemá takový výkon, takže všechny operace jsou pomalejší, než by se mi líbilo. Pracovní plocha se dá alespoň vylepšit externím monitorem, ale i tak to bude utrpení.

Během reklamace jsem zatím narazil na jeden zásadní a zbytečný problém: formulář pro reklamaci nepřipouští diakritiku v žádném poli. Nejhorší je v to v textarea s popisem závady, který dokonce nepřipouští ani uvozovky. Nerozumím proč nemůžou napsat skript pro překlad a pro nahrazení problematický znaků z textu a nutí uživatele k něčemu tak nepohodlnému.

Uvidíme, jak se bude reklamace dále vyvíjet, zítra očekávám vyzvednutí krabice (jejíž pečlivé zabalení mi dalo tolik práce) DPD.

Minule jsem zmiňoval dva projekty "špatného kódu," ale rozepsal jsem se jen o tom prvním.

U druhého mě totiž zaráží spíše jeho samotná existence. O co jde? Vlastní PHP framework a rozsáhlé CMS na něm postavené. Psát v dnešní době framework se mi zdá zbytečné. Existuje jich spousta a i když se zaměřím jen na ty větší, které mají nějakou budoucnost.

Ne každý z nich se hodí ke každému účely. Například CakePHP je vhodný pro jednodušší CRUD aplikace s trochou rozšíření, pro komplexnější aplikace asi spíš Zend, někomu zase vyhovuje Nette. Určitě si mezi nimi člověk může vybrat podle účelu, ke kterému má sloužit.

Za výhody velkého "cizího" FW považuju:

1. Je výsledkem práce týmu programátorů, což znamená minimálně více pohledů na věc a zvážení alternativ
2. Neslouží jenom vývojovému týmu, což si vynucuje dokumentaci
3. Je používán
   
   1. A tím testován v různých situacích
   2. Existují o něm články i mimo vývojový tým s odlišným přístupem, který je často zpočátku stravitelnější
   3. Existují fóra s popsanými problémy, v lepším případě i řešeními
4. Čas vynaložený na naučení je menší než na napsání vlastního, zpočátku se v něm člověk neorientuje tak snadno a řeší problémy neefektivně, což se nestane vývojařům vlastního systému (ale týká se to programátorů, kteří přijdou později a musí se s ním seznámit, tj. vynaložit čas a naučit se FW, který mimo nebude použitelný, ale současně není možné najít programátora, který by jej již znal)
5. Není třeba vynakládat čas na vývoj FW, pokud nám vyhovuje směr jeho vývoje, pokud ne, tak ho ovlivnit nebo forknout
6. Není vázán na jednoho, dva, tři programátory, kteří se podílejí na počátečním vývoji

Projekt, na kterém jsem minulých 14 pracoval trpí všemi těmito nedostatky. Navíc u něj dochází k velmi těsnému splynutí FW a CMS. Obsahuje zajímavé prvky (g11n, historie všech editací) a některé prvky jsou plně automatizované (výpis indexové akce se stránkováním a řazením), ale není možnost, jak tuto automatiku obejít, pokud je třeba udělat něco specifičtějšího.

Jiné části systému jsou naopak příliš holé. Pro komunikaci s databází je použito dibi, ale není obaleno žádnou třídou, která by usnadňovala práci. Při jakémkoliv dotazu na DB je třeba ve třídě (Active Record princip de facto) třeba vytvořit metodu, která bude obsahovat blok try - catch kvůli odchytávání chyb, které vyhazuje dibi. Blok catch navrch obsahuje jenom zalogování zprávy a je v desítkách tříd zkopírovaný ten samý kód - jasné místo pro abstrahování metody log v util třídě dostupné v celé aplikaci.

Samozřejmě chápu touhu každého vývojáře "napsat si to sám." Sám tím trpím, ale uvědomuji si, že je lepší použít již hotová řešení, kombinovat je a stavět na nich.

U prvního jde o nekonečný web - dávno vymyšlený, zadaný, napsaný a od té doby hnijící na testovací doméně, na jehož vývoji jsem se přímo nepodílel, takže často jen zírám a snažím se pochopit, kudy se ubírala mysl autora kódu.

Některé obraty jsou zbytečné (explicitní vytváření labelů u všech elementů, i když CakePHP to udělá automaticky), některé duplicitní (dvojí výpis inputu na základě toho, zda existuje již nějaká hodnota a její případné vložení, opět to Cake vyřeší sám).

Často se vyskytuje plýtvání prostředky, zvlášť u zpracování dat závislých modelů. Zbytečná rekurze při dotazech dokonce dokázala způsobit překročení paměťového limitu vyhrazeného pro PHP skript. Mnoho míst přímo volá po abstrahování do jednoduché funkce.

Šablony také trpí opakovaným kódem, který se strašně špatně udržuje. Při každém zásahu se bojím, že něco rozbiju (samozřejmě git pomůže, ale...) na jiném místě webu. Id a class jsou použité mimo svůj kontext (.article je nejen u článků, ale i u partnerů apod.) nebo na tolika místech, že je v podstatě nemožné dohledat, co změna způsobí.

Skoro vše se dá ovšem omluvit nezkušeností autora a omezeným časem.

Hlavní problém tkví v nových požadavcích zadavatele, mezi kterými vévodí nahrazení odstavců <p> souvislým textem s dvojitým <br>. Zákazník je bohužel pán a nedá si vymluvit svoje rozhodnutí, i když překážky, které tak klade budoucím úpravám jsou tak velké.

Díky takovémuto uspořádání zůstane mezi "odstavci" volný řádek konstantní velikosti. Nepochybuji o tom, že jednou přijde požadavek tuto mezeru zvětšit/zmenšit. Nepůjde, není to odstavec. Použití adekvátních předdefinovaných stylů je přitom při zadávání textů díky TinyMCE naprosto totožné. "To se rozhodně nikdy měnit nebude."

Z vlastní zkušenosti vím, že se změní vše a v první řadě to, o čem klient tvrdil, že se to nikdy měnit nebude.

S Danem si docela dáváme i sedm kuželek: http://zonglovani.info/obrazky/ulita-20100124/stranka3/0032.html

Irča s Danem přebírají kaskádu s pěti: http://zonglovani.info/obrazky/ulita-20100124/stranka5/0060.html

Skoro-synchro čtyři kuželky: http://zonglovani.info/obrazky/ulita-20100124/stranka4/0056.html

Danovo lehárko: http://zonglovani.info/obrazky/ulita-20100124/stranka4/0059.html