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.