Proti proudu: Nemám rád úpravu hotových řešení!

18. června 2008

Programování

Trendem poslední doby je znovupoužitelnost již naprogramovaného. Povídáme si o tom ve škole na přednáškách i později u piva, vášnivě o tom diskutujeme na studentském serveru Všeborec.cz.

"Ty se ještě furt děláš s vlastním redakčním systémem? Taky jsem tak začínal, teď nedám na wordpress dopustit. Všechno je jednoduché - změním pár šablon a hned to frčí do světa. Někdo udělá novej plugin a já si ho hned můžu naimportovat, na kód nemusím ani šáhnout."

Podobně slastné výkřiky slýchám poslední dobou ze všech stran. Po znovupoužitelnosti na úrovních copy-paste, funkce, objekt a komponenta se přesouváme do období customizace hotových řešení. A neříkají to pouze kolegové informatici, čím dál častěji s tím za mnou chodí i klienti.

"Chceme jistotu, že to bude fungovat. Když to používají statisíce (miliony,...) lidí, znamená to, že to asi je funkční. Potřebujeme dodržovat standardy, které uznává mnoho lidí, aby případně mohl na práci bez problémů pokračovat i někdo jiný."

Ano, uznávám, že existují důvody, kvůli kterým má smysl v některých případech o customizaci hotových řešeních uvažovat (uvedu na konci). Obecně jsem však k podobným produktům spíše skeptický a v tomto článku bych si dovolil polemizovat s nejčastějšími argumenty pro a přihodit i pár svých proti.

Upravit hotové je rychlejší a tím pádem levnější než to udělat celé znovu

Nejčastějším argumentem, na který slyší zejména zadavatelé, je cena. Ano, Wordpress nainstalujete za pár minut, phpBB forum také, stovky jiných webových aplikací jakbysmet. Náklady za deset minut práce? Do stovky se vejdeme. Je jasné, že za 100 Kč při nejlepší vůli nemůže nikdo redakční systém naprogramovat, takže by se zdálo, že je situace jednoznačná.

Samozřejmě nemohou mít všechny weby jeden z dvaceti připravených templatů (šablon), to dá rozum. Takže je zapotřebí vytvořit šablonu vlastní  - zaplatit grafikovi za grafický návrh, rozřezat, připravit CSS. Nastane fáze, kdy je zapotřebí poprvé trochu pochopit vnitřnosti hotové aplikace, neboť klient si přál tohle támhle a grafik se také trochu vzdálil původnímu rozmístění prvků. Nestačí pouze editovat soubor kaskádových stylů a přepsat obrázky. Najednou nechceme vypisovat kategorie pomocí seznamu LI v levém sloupečku, ale chceme je vypsat nahoru na jeden řádek jako odkazy do lišty. Podkategorie se zobrazí javaskriptem po najetí myši - sice se to nemá, ale klient to chce, takže to uděláme.

Jak na to? Nejprve se samozřejmě podíváme do obrovské databáze pluginů - co když už náhodou někdo před námi něco podobného udělal? Řekněme, že máme poloviční štěstí - najdeme plugin, který dovolí vypsat kategorie do řádky, ale podkategorie schovávat javaskriptem neumí. Nainstalujeme plugin a pustíme se do jeho editace. Otevřeme zdrojový kód a vidíme úžasný systém s jistě báječnou a léty prověřenou filozofií... kterou musíme pochopit. Otevřeme dokumentaci a po pár desítkách minut zjistíme, že se výpis kategorií definuje v třídě XY v souboru YZ. Třída XY však vypadá nějak jednoduše na to, aby zvládala všechno, co zvládat má - aha, je to pouze potomek třídy X. Takže dohledáme rodiče a konečně upravujeme kód. Podobných drobností musíme obvykle upravit více, takže nakonec systém známe skoro tak dobře, jako kdybychom jej programovali sami.

Hotový redakční systém sám o sobě není zdrojem konkurenční výhody, tedy nemůže být ani příčinou úspěšnosti webu. Hotový software je proto zapotřebí více či méně upravit. K této úpravě je zapotřebí alespoň z části pochopit filozofii redakčního systému, která obvykle bývá mnohem komplexnější než u vlastních řešení, protože musí podporovat různé pluginy a být co nejvíce pružná.

Osobně se domnívám, že pochopit cizí filozofii je mnohdy náročnější, než vytvořit filozofii vlastní, nikdy však méně náročné. Programování vlastními silami "od nuly" nám umožní se lépe soustředit na specifické potřeby klienta. Programový kód bude jednoduchý, protože nebude muset spolupracovat s desítkami pluginů a nebude muset být parametrizovatelný.

Určitá výhoda hotových řešení je samozřejmě v tom, že jejich filozofii pracně pochopíte jednou, a při příští zakázce už jste jako ryba ve vodě. Hned víte, kam šáhnout. Na druhou stranu - pokud vytváříte opakovaně vlastní redakční systém, nikdy od úplné nuly nezačnete. Častý argument pro hotové řešení zní "vždyť je to stejně všechno na jedno brdo - insert, update, delete - proč to programovat milionkrát znovu?" Samozřejmě, že si postupem času vytvoříte i při vlastním vývoji funkce nebo celé skripty, které budete používat ve všech svých projektech (načtení dat z databáze do struktur, přihlašovací formulář, captcha,...). Výhodou těchto funkcí a skriptů ale bude, že nad nimi budete mít plnou kontrolu, budou obsahovat jen to, co potřebujete, budou blízké Vašemu způsobu myšlení (programování).

Redakční systémy neobsahují žádné složité algoritmy, programování jejich základní kostry na míru je v mnoha ohledech rutinní a tím pádem i rychlé. Co na programování trvá, to jsou zvláštnosti, které jsou pro každou stránku specifické - a ty budete programovat stejně, ať již použijete hotové řešení či nikoli. Prostor pro velký rozdíl v ceně tedy nevidím - ono asi nebude náhodou, že na trhu v ČR neexistuje žádný významný implementátor opensource CMS. Mně nejznámější je asi oblíbená firma F-ART Agency (není to úplně opensource, pravda...) a pohled na ceník mi nepřijde o mnoho odlišný od vývoje na míru...

Hotové řešení je bezpečnější, protože je odladěno miliony uživatelú

Velice silný argument, který má logiku. Je jasné, že hotová řešení jsou zcela jistě odladěna více, než většina řešení na míru. Na druhou stranu mají hotová řešení oproti těm vlastním minimálně 3 nevýhody:

  • jsou složitější - tím pádem náchylnější k chybám a děravým místům
  • mají většinou volně dostupný zdrojový kód - kdokoli může kód nejen opravit, ale také studovat za účelem útoku
  • mají mnoho instalací, čímž jsou pro hackery atraktivnější (Kdyby tučňáci nebo ilidé měli na desktopech tolik, kolik Windows, to by bylo virů! Takhle po nich pes neštěkne, protože se to nevyplatí)

Každý programový kód má svá slabá místa. Pokud si zrovna Vaše stránky někdo šikovný vyhlídne, je pravděpodobné, že se mu nakonec nějaký průnik podaří. Nevýhodou hotových řešení je, že se mohou objevit útočníci, kteří nebudou primárně zaměřeni na Vaše stránky, nýbrž na Vámi použitý SW. Každou chvíli vidím v logu svého apache pokusy různých červů zneužít nějakých starých děr v neaktualizované aplikaci phpMyAdmin. Útoků na redakční systém wordpress je rovněž nepočítaně, zkuste si schválně do googlu zadat "wordpress útok". U dalších používaných řešení typu phpBB je situace podobná a jediná možnost je tyto hotové aplikace neustále aktualizovat.

Snadno přidám novou funkcionalitu - stále budu trendy a nebudu muset naprogramovat ani řádku

Bylo by velice krásné sledovat, jak mi na email chodí informace o nově dostupných pluginech pro mé hotové řešení. Vyjde plugin pro můj eshop, který mi dovolí exportovat zboží do Froogle. Než se naděju, už se to stahuje, rozbaluje, instaluje...

Problém je, že vše, co nainstalujete, musí nějakým způsobem spolupracovat. Změnili jste strukturu tabulky zboží, protože jste nutně potřebovali dvojjazyčné popisky? Máte smůlu, nový plugin s takovouto tabulkou spolupracovat nebude.

Dalším velkým problémem je, že z bezpečnostních důvodů budete muset vše, co nainstalujete, pravidelně aktualizovat. Pokud cokoli v hotovém řešení přepíšete, jste v pytli, protože s novou verzí přijmete buď všechno, nebo nic.

Kdy je vhodné použít hotové řešení

Přes všechno uvedené výše hotová řešení zcela nezatracuji, existují případy, kdy je jejich použití efektivní a často jediné možné. Použití customizovatelného hotového řešení doporučuji v následujících případech:

  • produkt není zdrojem konkurenční výhody, poskytuje rutinní funkcionalitu, kterou nebude potřeba nijak zvlášť měnit - nastaví se pouze pár parametrů v konfiguračních souborech (FCKeditor, phpMyAdmin, dle okolností phpBB forum a další...)
  • není důležitá forma, ale obsah a rychlost zprovoznění (některé blogy, stránky ke školním projektům,...)
  • týmová práce mnoha lidí vyžadující respektování určitých pevně definovaných standardů, postupů a filozofií
  • plánovaná častá obměna programátorů

Jak dlouho jste ochotni hledat vhodné řešení?

Před časem jsem spustil vlastní projekt Vyplňto.cz, který má snahu co nejvíce respektovat aktuální trendy webu 2.0. Jelikož lidé dlouhou dobu brečeli, že u výsledků průzkumů nejsou k dispozici žádné grafy a jedním z principů webu 2.0 je mimo jiné hledání a použití cizího řešení, zkusil jsem to.

Takové koláčové a sloupcové grafy jsou poměrně rutinní věc, jistě je již mnoho lidí potřebovalo generovat, nejedná se o konkurenční výhodu. Zcela základní věc - logicky by na mě mělo z googlu vypadnout x snadno upravitelných řešení, přičemž si dokážu představit, že bych u grafů nemusel upravovat klidně vůbec nic.

Hledal jsem, hledal, a kupodivu dlouho nic moc nenacházel. Zajímavě vypadající Libchart byl bohužel nakonec shledán licenčně nevýhodným (GPL) podobně jako většina ostatních produktů (vesměs rovnou trial nebo shareware). Vyplňto obsahuje velké množství unikátního kódu, který přímo způsobuje jeho konkurenční výhodu - kvůli grafům se mi zveřejňovat celý zdrojový kód pod virovou licencí GPL rozhodně nechtělo.

Nakonec jsem po několika hodinách zvolil slibně vyhlížející produkt Open Flash Chart (OFC) pod nevirovou licencí LGPL. Grafy vypadaly pěkně, efektní animace sice trochu ztěžovala možnost tisku, ale čert to vem. Pustil jsem se do implementace a zhruba za hodinu nebo dvě se mi nakonec podařilo připravit zdrojová data a grafy nějak zprovoznit. Jenže v mnoha ohledech jsem narazil - potřeby Vyplňto se ukázaly být poněkud specifické, a to hned v několika ohledech. Největší problém byl v délce textů - názvy otázek jsou mnohdy opravdu dlouhé a OFC má se zobrazením nadpisu grafu do více řádků problém. U dlouhých hodnot, o které rovněž není na Vyplňto nouze, bylo zapotřebí nastavit limit asi na 10 znaků, jinak z koláčového grafu zbyl jen malinký bonbónek vedle obrovské legendy. Vaz nakonec OFC zlomila nepodpora některých českých znaků - po několika hodinách pokusů o skutečný Web 2.0 jsem naprogramoval grafy vlastní. Trvalo to sice celý jeden večer, ale s výsledkem jsem nadmíru spokojen - ocenili to kupodivu i uživatelé.

Máte na téma jiný názor? Vyjádřete jej prosím v diskusi...

Publikováno dne 18. 06. 2008 v kategorii Programování Odhadnutá klíčová slova BETA: wordpress | hotove | open | chart | flash | libchart | řešení | hotových | plugin
Mohlo by Vás zajímat BETA: Sony Ericsson K850i - první mega dojmy a srovnání s K750i (recenze)

O kategorii Programování

V nejodbornější kategorii tohoto blogu jsou zařazeny články s mými programátorskými zkušenostmi získanými několikaletou praxí tvorby stránek a java aplikací pro mobilní telefony.

Komentáře k článku

my trend - [email schován] (dne 16. 06. 2009 v 10.55)
ja mam zkusenost s ohybanim wordpressu docela pozitivni. Je pravda, ze clovek se do toho musi dostat, ale pak je programovani vlastnich pluginu hracka.

Přidat vlastní komentář:
Jméno:
E-mail:
Sledovat diskusi:
Web:
Kontrolní kód:

Komentáře jsou v prvé řadě určeny ke kladení dotazů k tématu, upozornění na chybu, rozšíření obsahu článku a vůbec ke zpětné reakci na obsah těchto stránek. Mé reakce jsou barevně odlišeny.

V současné době není umožněno vkládat HTML tagy - pokud vložíte HTML kód, bude převeden na entity. K Vašemu komentáři se do databáze uloží čas vložení a Vaše aktuální IP adresa (54.227.48.147). IP adresa se nebude zobrazovat čtenářům, nicméně v případě, že bude Váš odkaz shledán právně závadným, může být Vaše IP adresa předána příslušným státním orgánům. Emailové adresy jsou ochráněny před běžnými spam roboty.

© Marek Demčák 2007 - 2018
Všechna práva dle Autorského zákona (č. 121/2000 Sb.) vyhrazena.