Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).
Vůbec nejde o akademické články. Akademickým článkům té doby by běžný Pepa kodér vůbec nerozuměl. Jde o texty praktiků, kteří popisovali své zkušenosti a často i řešení problémů, s nimiž se setkali.
Např. zmiňovaný postřeh o nepředvídatelnosti budoucího vývoje SW produktu. Tak na to naráželi už v 70. letech. A řekl bych, že většina z nás se už někdy setkala s poznámkami "reserved for future extensions". A taky tenkrát doporučili, jak se s tím vypořádávat:
1. Řešte jen problém, který máte skutečně řešit dle zadání. Dejte si pozor na dodatečné podmínky, které ve skutečnosti ze zadání neplynou, ale vy jste si je podvědomě dotvořili ve snaze předvídat budoucí vývoj nebo řešení nějak vylepšit, a přitom vedou k potřebě větší abstrakce a komplexity.
2. Pokud obecnější řešení v daném případě nevede k nárůstu komplexity nebo náročnosti na zdroje, není důvodu omezovat se na specifikaci.
Zdůvodnění je jednoduché. V naprosté většině případů o ta vylepšení nikdo nestojí a vývoj se bude ubírat jiným směrem než si myslíte, ale jejich přítomnost velmi zkomplikuje budoucí modifikace směrem, s nímž se nepočítalo. Jednoduchá věc se dá překopat snadněji než komplikovaná.
Vyčleníte-li někde 4 bajty pro budoucí rozšíření vlastnosti X, 4 bajty pro vlastnost Y a 4 bajty pro vlastnost Z, vemte jed na to, že jich nakonec bude zapotřebí nejméně 5 pro vlastnost X a vyvstane potřeba přidat vlastnost W, co potřebuje 2 bajty, a vlastnost Y už nikdo nepotřebuje, protože děrné pásky odnesl čas. Přestože prostor k obojímu je, technicky to bude hlavolam, protože někdo před lety "myslel" víc, než bylo zdrávo. Je to jen ilustrační příklad, ale na podobné situace jsem ve svém profesionálním životě narážel neustále - komplikované hierarchie tříd, zabránění opakování stejného kódu i za cenu, že se to celé znepřehlední zbytečnými abstraktními mezičlánky a lepidly mezi nimi, jež vydají za 5x tolik kódu, než kdyby se to prostě duplikovalo apod., načež se potom ukáže, že přeci jen ten kód nebude úplně stejný, takže struktury, jež měly zamezit duplikaci kódu, se musejí obcházet a nastavovat jak kaše, protože tím okamžikem ztrácejí smysl, ale zato vydatně překážejí.
Přestože formulace je jednoduchá, realizace je náročná, protože ne každý si umí ty klapky z očí sundat a má cit pro to, co ještě ano a co už ne. Ale rozhodně by přemýšlení o takovýchto věcech měl být dáván větší prostor, než jak nejčistěji aplikovat návrhový vzor XYZ, protože jsem podlehl pocitu, že jde o zázračný všelék, který za mě vyřeší problémy. V knížce to sice vypadá elegantně, možná se to i v konkrétním případě podaří implementovat elegantně, ale jakmile bude třeba do toho trošku hrábnout, stane se z toho podobný zážitek, jako oprava traktoru typu LKT.
80 Odpovědí
32473 Zhlédnutí