Těžké OOP problémy

[Tomas-T]

No já si taky postěžuju k tématu:

V rámci pracovní náplně se starám o údržbu, opravu chyb a rozvoj několika různých webových aplikací psaných v ASP .NET.
Jde o různé druhy - některé jsou napsané jako Website ještě ve Visual Basicu, něco jsou takové klasické MVC aplikace v c#, zbytek pak "moderně" pojaté MVC aplikace se spoustou frameworků, továren, fasád, s podporou NodeJS.
Autoři aplikací jsou také různí, něco pochází od vývojáře u zákazníka, který se o to už nechtěl starat, něco je osiřelá aplikace napsaná a následně opuštěná konkurenční firmou, zbytek pochází od kolegů programátorů, kteří na jejich údržku a rozvoj nemají čas, protože píšou zase jiné nové aplikace.
Vče jsou to aplikace podobného rozsahu a složitosti. Žádnou z těch aplikací jsem od začátku nepsal, přicházím vždu k cizímu hotovému.

A já mám největší problémy s údržbou a opravami aplikací pocházejících od vlastních kolegů (některých).
Jejich aplikace jsou na můj vkus totiž "příliš programátorské, příliš příručkoidní, příliš OOP" - vše je skryté pod několika vrstvami abstrakce, všude jsou implementované interfejsy, automatické mappery, časté je dědění tříd a přepis metod, JS kód je obvykle někde dynamicky generovaný jako součást něčeho a jednoduše nedebugovatelný.
Můj pocit z jejich kódu je, že se snaží vždy všechno napsat co nejvíc "elegantně", aby se velká část činnosti nevykonávala ve viditelném kódu vlastních tříd, ale někde skrytě na pozadí. Taková trošku programátorská onanie, čím menší vrabec, tím větší kanón. 
A když mám v takové aplikaci něco opravit nebo vylepšit, tak tím často strávím několik dní než se skrz ten balast prokoušu k podstatě, často jen odhadem a zkusmo. Většinou také proto, že přijde nějaký požadavek na funkčnost mimo rámec toho jejich "elegantního" řešení a já to musím nějak násilně ohýbat, pokud to nechci celé přepsat po svém.
Přitom se paralelně starám i o ostatní aplikace od jiných autorů a tam takové problémy nepociťuju - vše je skoro vždy tam, kde to čekám, když něco změním, reaguje to dle očekávání, změny jsou hotové za hodinu nebo dvě. Jsou prostě napsané přímočařeji a jednodušeji, složitější konstrukce si šetří jen tam, kde to opravdu dává smysl (= skoro nikde, neřešíme teorii relativity, ale třeba logistiku, správu vozového parku, apod).
 
Takže teď nevím, zda mám hledat nedostatky u sebe nebo u kolegů - z mého hlediska je jejich "dokonalý" kód hodně neefektivní na občasné změny a opravy. Místo aby vše šlo snadněji a rychleji, tak je to naopak časově náročnější - minimálně pro mně.

Kdo to dočetl až sem, má u mě velké bezvýznamné plus. 

[Reklama]

[Idris]

No já si taky postěžuju k tématu:

V rámci pracovní náplně se starám o údržbu, opravu chyb a rozvoj několika různých webových aplikací psaných v ASP .NET.
Jde o různé druhy - některé jsou napsané jako Website ještě ve Visual Basicu, něco jsou takové klasické MVC aplikace v c#, zbytek pak "moderně" pojaté MVC aplikace se spoustou frameworků, továren, fasád, s podporou NodeJS.
Autoři aplikací jsou také různí, něco pochází od vývojáře u zákazníka, který se o to už nechtěl starat, něco je osiřelá aplikace napsaná a následně opuštěná konkurenční firmou, zbytek pochází od kolegů programátorů, kteří na jejich údržku a rozvoj nemají čas, protože píšou zase jiné nové aplikace.
Vče jsou to aplikace podobného rozsahu a složitosti. Žádnou z těch aplikací jsem od začátku nepsal, přicházím vždu k cizímu hotovému.

A já mám největší problémy s údržbou a opravami aplikací pocházejících od vlastních kolegů (některých).
Jejich aplikace jsou na můj vkus totiž "příliš programátorské, příliš příručkoidní, příliš OOP" - vše je skryté pod několika vrstvami abstrakce, všude jsou implementované interfejsy, automatické mappery, časté je dědění tříd a přepis metod, JS kód je obvykle někde dynamicky generovaný jako součást něčeho a jednoduše nedebugovatelný.
Můj pocit z jejich kódu je, že se snaží vždy všechno napsat co nejvíc "elegantně", aby se velká část činnosti nevykonávala ve viditelném kódu vlastních tříd, ale někde skrytě na pozadí. Taková trošku programátorská onanie, čím menší vrabec, tím větší kanón. 
A když mám v takové aplikaci něco opravit nebo vylepšit, tak tím často strávím několik dní než se skrz ten balast prokoušu k podstatě, často jen odhadem a zkusmo. Většinou také proto, že přijde nějaký požadavek na funkčnost mimo rámec toho jejich "elegantního" řešení a já to musím nějak násilně ohýbat, pokud to nechci celé přepsat po svém.
Přitom se paralelně starám i o ostatní aplikace od jiných autorů a tam takové problémy nepociťuju - vše je skoro vždy tam, kde to čekám, když něco změním, reaguje to dle očekávání, změny jsou hotové za hodinu nebo dvě. Jsou prostě napsané přímočařeji a jednodušeji, složitější konstrukce si šetří jen tam, kde to opravdu dává smysl (= skoro nikde, neřešíme teorii relativity, ale třeba logistiku, správu vozového parku, apod).
 
Takže teď nevím, zda mám hledat nedostatky u sebe nebo u kolegů - z mého hlediska je jejich "dokonalý" kód hodně neefektivní na občasné změny a opravy. Místo aby vše šlo snadněji a rychleji, tak je to naopak časově náročnější - minimálně pro mně.

Kdo to dočetl až sem, má u mě velké bezvýznamné plus. 

To je klasika, přesně o čem jsem psal, kdo zná jen a pouze IT, vnáší umělou složitost do kódu. Kdo píše kód k vyřešení problému z jiné domény, napíše ho co nejjednodušší, aby prostě řešil, co má, bez padesáti rovin abstrakce.

[Mirek Prýmek]

kdo zná jen a pouze IT, vnáší umělou složitost do kódu

Nevím, jestli bych to takhle spojoval. Např. my máme ve firmě šéfprogramátora, který jednoduchost a přímočarost docela tvrdě vyžaduje. Zrovna tenhle týden mi říkal, že za rule of thumb kritérium obhajitelnosti abstrakce považuje to, že je ta abstrakce použitá na třech různých místech. Psát abstrakce jenom tak z plezíru, s vidinou, že se to jednou bude hodit, je u něj no-go. A je to čistý informatik. Akorát má prostě dost zkušeností a je dost inteligentní.

Podle mě je ideální takového člověka v týmu mít. Když si člověk existenci každé abstrakce, kličky a nestandardnosti musí obhájit jasnými konkrétními argumenty, přestane mít chuť psát ty neobhajitelné

[Idris]

kdo zná jen a pouze IT, vnáší umělou složitost do kódu

Nevím, jestli bych to takhle spojoval. Např. my máme ve firmě šéfprogramátora, který jednoduchost a přímočarost docela tvrdě vyžaduje. Zrovna tenhle týden mi říkal, že za rule of thumb kritérium obhajitelnosti abstrakce považuje to, že je ta abstrakce použitá na třech různých místech. Psát abstrakce jenom tak z plezíru, s vidinou, že se to jednou bude hodit, je u něj no-go. A je to čistý informatik. Akorát má prostě dost zkušeností a je dost inteligentní.

Podle mě je ideální takového člověka v týmu mít. Když si člověk existenci každé abstrakce, kličky a nestandardnosti musí obhájit jasnými konkrétními argumenty, přestane mít chuť psát ty neobhajitelné

To je přesně ono, jeden z padesáti čistých informatiků je určitě dost zkušený a inteligentní na to, aby si to uhlídal. Takového by měli vyvažovat zlatem. Ale co ten zbytek, který nad sebou žádnou kontrolu nemá?

[L..]

Blbost. Tomu, co tady popisuje Tomas-T se říká "overdesign" a ano, vyskytuje se bohužel poměrně často, nicméně že by nějak souvisel s tím, jestli je člověk "čistý ajťák" nebo ne jsem nevypozoroval. Maximálně tam může být ten efekt, že člověk "z jiného oboru" nepíše složitější abstrakce, protože je prostě nezná. Nicméně takoví lidé mají problém v okamžiku, kdy musí napsat něco složitějšího nebo prostě jen trochu většího - často mají tragickou organizaci kódu. A zesložiťují to i jiným způsobem - typicky se pokouší těch pár řešení, co znají, napasovat na všechno a občas člověk kouká, jaká zvěrstva jsou schopni napsat, protože prostě nemají rozhled...

Jestli s něčím, tak overdesign souvisí spíš s "nadšeností" programátora. Jsou lidi, co jsou profesionálové v nejlepším slova smyslu. V programování vezmou problém, zváží možná řešení, vyberou to nejlepší a aplikují.

No a pak jsou vyloženě nadšenci, které programování hrozně baví, když přijde nová technologie nebo i jen nová verze knihovny, musí ji hned vyzkoušet a někde použít. A ti právě overdesign páchají dost často, protože ty technologie / abstrakce prostě _chtějí_ použít a nezajímá je, že jsou vlastně zbytečné.

Mě třeba programování baví, ale nemám ho jako středobod života. U nové technologie se vždycky ptám "co nám to přinese" a jednoduchost je moje hlavní heslo při programování. Protože jednoduchý kód znamená prakticky vždycky rychle napsaný, spolehlivý a dobře udržovatelný kód. Je zajímavé, že k podobnému "pravidlu tří použití" o kterém tady mluví Mirek jsem také dospěl, zcela nezávisle :-)

[Reklama]

[Ink]

Já bych taky doporučoval vystříhat se zobecňování.

Viděl jsem programy "lidí z praxe", kteří vystudovali jiný obor. Jakmile systém přesáhne určitou velikost, často nevědí moc co s tím, protože jim scházejí zkušenosti, nemají to osahané ani odkoukané. Programování je řemeslo úplně odlišné od jiných a jeho znalost nedá se nahradit ani selským rozumem ani vysokým IQ, vyjma prdlikání prográmků o pár tisících řádek. Mimochodem, lidé z jiných oborů, kteří mají ultravýkonný mozek, sice nevrství abstrakce, ale zase občas píší špagetový kód, ve kterém se vyznají přinejlepším oni sami a udržovatelnost je mizivá.

Co se týče "zbytečných" abstrakcí, je to otázka míry a odhadu. Kolikrát jsem zažil situaci, kdy kolegové tíhli k "custom" implementaci, pak se udělal jeden copy/paste, pak druhý, pak další a už to šlo tak nějak ze zvyku a když to po nich někdo přepíše, málem aby si za to dal facku, když "to přece takhle funguje" a "proč to neudělat zase tak, když máme dost jiné práce". Že se to pak další měsíce a roky s úspěchem dělá ponovu a co se řešilo kopírováním funkce o 100 řádcích nebo větší třídy, je teď na jedno volání, už nikdo nevidí, protože se to "teď dělá takhle, no". Nebo ty abstrakce daný tým znovupoužívá v dalších a dalších produktech, ale to už jaksi není vždycky vidět. No a navíc - dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit. Naopak by měla vést k tomu, že se pořád dokola řeší pár řádek namísto špagetového monstra, kde "všechno souvisí se vším" a "nic není navíc".

Že je abstrakce nástroj, který může být použit špatně? Ale jistě, jako každý nástroj!

[Mirek Prýmek]

dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit.

S tím bych nesouhlasil. Dokonce bych spíš tvrdil skoro opak: každá abstrakce z definice přidává další indirekci v tom smyslu, že když sleduju flow programu a narazím na abstrakci, musím odskočit jinam (do souboru, kde je ta abstrakce definovaná).

Jediné, co rozhoduje, je, jestli převáží nevýhody použití nebo nepoužití abstrakce. Což je typicky počet abstrakcí (jestli jsem schopen si je zapamatovat a ušetřit si tak odskoky) a jejich srozumitelnost (po jednom přečtení chápu smysl abstrakce, nedělám to tak, že sleduju jenom ten jeden průchod, který zrovna řeším).

[Ink]

dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit.

S tím bych nesouhlasil. Dokonce bych spíš tvrdil skoro opak: každá abstrakce z definice přidává další indirekci v tom smyslu, že když sleduju flow programu a narazím na abstrakci, musím odskočit jinam (do souboru, kde je ta abstrakce definovaná).

Jediné, co rozhoduje, je, jestli převáží nevýhody použití nebo nepoužití abstrakce. Což je typicky počet abstrakcí (jestli jsem schopen si je zapamatovat a ušetřit si tak odskoky) a jejich srozumitelnost (po jednom přečtení chápu smysl abstrakce, nedělám to tak, že sleduju jenom ten jeden průchod, který zrovna řeším).

Dobře zvolená abstrakce naopak nevyžaduje, abys někam skákal, prostě o sobě říká, co dělá a typicky se o vnitřek zajímat vůbec nemusíš. Co je abstrakce, je datová struktura abstrakce? Je bufferovaný soubor abstrakce, je check box abstrakce? Je volání dobře pojmenované funkce zbytečná překážka v čitelnosti kódu, když se to přece dá naprasit na jednom místě a překladač to snese? Proč používat map() a filter(), když všichni známe cyklus a taky funguje. Proč požívat cyklus, když máme goto...

[Mirek Prýmek]

Dobře zvolená abstrakce naopak nevyžaduje, abys někam skákal, prostě o sobě říká, co dělá a typicky se o vnitřek zajímat vůbec nemusíš.

Nemusím se o vnitřek starat, pokud jsem si dostatečně jistý tím, 1. co je výsledkem její činnosti (pokud je to funkce) 2. že neobsahuje žádnou chybu.

Implementaci knihovních funkcí typu map budu prolízat až jako poslední, protože je nejmenší šance, že chyba bude právě v ní. Naopak konstrukce, které napsali kolegové před půl rokem a jsou v kódu použité jenom dvakrát, prolízt musím, protože pravděpodobnost chyby je veliká. V případě, že jsou srozumitelné a snadno zapamatovatelné, prolezu je jednou. Jinak je musím prolízat pořád dokola, protože prostě nejsem schopný si zapamatovat nebo vůbec pochopit, co mají dělat.

[registrovany_ava]

"All problems in computer science can be solved by another level of indirection ...except for the problem of too many layers of indirection."

[redustin]

Je to také hodně o použitých nástrojích. Není problém napoprvé napsat konkrétní řešení, při druhém použití je mírně přiohnout a až při třetím použití pořádně zrefaktorovat do více úrovní abstrakce, když se člověk může spolehnout na použitý jazyk a nástroje. V pythonu či JS se taková věc dělá hodně pracně, v javě s generiky a kvalitním IDE je to hotové rychle a spolehlivě (pokud tam nejsou čuňárny typu přetypování natvrdo, reflexe se stringovými názvy apod.).

[Idris]

Je to také hodně o použitých nástrojích. Není problém napoprvé napsat konkrétní řešení, při druhém použití je mírně přiohnout a až při třetím použití pořádně zrefaktorovat do více úrovní abstrakce, když se člověk může spolehnout na použitý jazyk a nástroje. V pythonu či JS se taková věc dělá hodně pracně, v javě s generiky a kvalitním IDE je to hotové rychle a spolehlivě (pokud tam nejsou čuňárny typu přetypování natvrdo, reflexe se stringovými názvy apod.).

Toto je přínosný příspěvek - ano, do značné míry záleží na jazyku, typová kontrola při překladu posouvá proces vývoje na vyšší úroveň nejen kvůli odchytu chyb, ale i jako dokumentace a umožňuje automatickou analýzu a refaktorizaci. Jak tu správně zaznělo, efektivní použití abstrakce do určité míry záleží na tom, kolik toho člověk udrží v paměti, než se ztratí. Typový systém naopak “udržuje kód v mantinelech,” problém ovšem je, že kvalitativní hierarchie je vlastní typy -> generické typy -> higher kinded typy -> závislostní typy a 99% vývoje končí na generických. Až se rozšíří ty zbylé dvě kategorie, bude vznikat kvalitnější SW rychleji a spolehlivěji.

(Velice smutné je, že teď si jde drtivá většina čtenářů googlit, co to je higher kinded a závislostní typ.)

[Idris]

dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit.

S tím bych nesouhlasil. Dokonce bych spíš tvrdil skoro opak: každá abstrakce z definice přidává další indirekci v tom smyslu, že když sleduju flow programu a narazím na abstrakci, musím odskočit jinam (do souboru, kde je ta abstrakce definovaná).

Jediné, co rozhoduje, je, jestli převáží nevýhody použití nebo nepoužití abstrakce. Což je typicky počet abstrakcí (jestli jsem schopen si je zapamatovat a ušetřit si tak odskoky) a jejich srozumitelnost (po jednom přečtení chápu smysl abstrakce, nedělám to tak, že sleduju jenom ten jeden průchod, který zrovna řeším).

Každý má limit chápání (abstrakcí i obecný) jinde. Monoid v kategorii endofunktorů je ultraužitečná abstrakce, ale kolik wannabe vývojářů ví, která bije? Přesně o tomto je myslím Go, které kašle na fancy abstrakce, Pike ho navrhnul - dle vlastních slov - pro absolventy bez zkušeností.

[Kit]

Monoid v kategorii endofunktorů je ultraužitečná abstrakce, ale kolik wannabe vývojářů ví, která bije? Přesně o tomto je myslím Go, které kašle na fancy abstrakce, Pike ho navrhnul - dle vlastních slov - pro absolventy bez zkušeností.

Jenže kolik vývojářů ví, co je monoid a co endofunktor? To znají jen ti, kteří studovali teorii kategorií a těch není mnoho.

[Idris]

Monoid v kategorii endofunktorů je ultraužitečná abstrakce, ale kolik wannabe vývojářů ví, která bije? Přesně o tomto je myslím Go, které kašle na fancy abstrakce, Pike ho navrhnul - dle vlastních slov - pro absolventy bez zkušeností.

Jenže kolik vývojářů ví, co je monoid a co endofunktor? To znají jen ti, kteří studovali teorii kategorií a těch není mnoho.

Alert! Nadsázka