Co mi dalo pět let na jednom projektu

Podobnost s předchozím článkem není ponechána náhodě. Je to takové volné pokračování myšlenek. Na interní službě SOS (Seznam Obchodní Systém) v rámci Seznamu jsem byl přesně pět let a jeden měsíc. Měsíc leden jsem tam zůstal navíc ještě jako podpora, kdy jsem hodně pároval a předával vědomosti nejen o projektu. To mi dalo i zajímavou příležitost vidět před odchodem celý projekt z trochu jiné perspektivy a čas na zamyšlení.

Díky tomu jsem si všiml jedné velmi zajímavé věci, které si lze všimnout právě po delší době na „jednom“ místě. Lidi se totiž točí přibližně co dva/tři roky a tak jsem poznal různé programátory a viděl jejich pohled na stejný kód a práci jejich předchůdců. A jelikož jsem znal i některé předchůdce, udělal jsem si obrázek.

Obrázek mi vyšel takový, že programátoři mají tendenci neustále něco zlepšovat. Aspoň to je to, co si myslí. Ve skutečnosti chtějí spíše měnit k obrazu svému. Jak si myslí, že je to správně. Realitou ale je, že nikdo neví, jak je to správně. I když víme, co vše systém má umět, nebudeme schopni si jít sednout a na zelené louce postavit krásnou vilku. Kód, který tam nyní je, by nebylo možné použít a nejlepší by bylo sáhnout po něčem novém. Novém Pyhtonu, jiné komunikační vrstvě, využít jiné patterny, napsat web jako SPA nebo naopak nepsat už jako SPA atd.

Tedy dnes sice víme, co jsme neměli dělat tak, jak jsme udělali. Jenže s dnešními technologiemi zase nevíme, čemu se vyhnout tentokrát. Protože to je prostě něco nového a musí se zase prozkoumat. Jinými slovy opět udělat chyby. Což je důležité si uvědomit, než se začne křičet jak někdo mohl něco napsat jak napsal.

Neříkám, že by se mělo smířit, jak kód vypadá, a přidat další bez žádného vylepšení. Právě přesný opak: zlepšovat! Ale ne neustále to samé. Protože mi přijde, že se často řeší ty samé věci dokola. A jakmile se dostane do jednoho bodu, začne se mluvit o tom, že to vlastně není dobře, a předělává se znovu. Třeba i do více méně verze, jak bylo dřív.

Byl jsem v tomhle ohledu mírný a dnes už vím, že bych měl přitvrdit. Například struktura kódu, validace vstupních dat, úroveň zobecňování, … jsou věci, které se řeší téměř všude a neustále, každý na to má svůj názor a jiné zkušenosti a nikdy řešení nebude perfektní. Protože perfektní neexistuje. Takže nemá smysl se snažit o dokonalost a neustále měnit ty samé věci.

Málokdo (čti opravdu málokdo, nejsem to ani já a velice pravděpodobně ani vy) dokáže napsat nadčasový kód. Podobně jako málokterý spisovatel dokáže napsat nadčasovou knihu či scénárista film.

Je potřeba se smířit s tím, že před námi napsal kód „prostě jen člověk“ a nezabývat se zbytečným přepisem. Na každém projektu je spoustu zajímavých a mnohem důležitějších oblastí, které je potřeba řešit. Stačí se rozhlédnout, udělat si seznam a priority. A řešit to, nikoliv jestli v pár let starém kódu je [doplň si jakoukoliv nekritickou věc, která tě irituje].

13 responses
Naprostý souhlas - bohužel málo programátorů umí, a chce, pracovat s "cizím" kódem. Vlastně je to věc, se kterou bojuji při jakémkoli dalším projektu (což se seznamíma věcma nejde ani náznakem srovnávat velikostí, rozsahem, ani týmem, spíš jde o to co někdo vyvíjí měsíce, a pak tam někdo další po roce vyvíjí něco dalšího). Typicky každý programátor začíná tím, že "by se todle mělo přepsat", nebo po třetí větší úpravě přijde s něčím jako "hele toto by chtělo zastavit na půl roku vývoj a celé to napsat znova". Dneska už nejede nette, ale zend, zítra nejede zend ale vyvíjí se v javě, a koneckonců po půl roce, proč to nepřesat do dotnetu?:) Takže dneska už jsem v tomto směru fakt striktní, nebo se o to snažím - a tedy, nic přepisovat nebudeme. Možná lepíme, možná vzniká sračka, ale zákazníka často "to co je uvnitř" našeho projektu nezajímá a naopak je číslo jedna funkcionalita. Nedává sice smysl tlačit nějaký "technický dluh", jenže to by se mohlo psát všechno co měsíc od znova...
@Michal Jojo, pracovat s cizím kódem je těžké. Právě v pondělí jsem přešel do jiného týmu a krásně na sobě pociťuji, jak mám nutkání některé věci upravit. Aby byly správnější (čti: podobnější tomu, čemu jsme se dobrali v předchozím týmu). Ale nijak to projektu nepomůže. Takže jsem si udělal seznam a na začátku mám zlepšit bezpečnost a automatizaci. Zbytek nemá smysl řešit. Každopádně bych nezatracoval „po třetí úpravě je potřeba to přepsat“. Někdy úpravy nedávají smysl pro aktuální implementaci a má opravdu smysl vynaložit úsilí předělat to. Dát kusy kódu na správné místo, lépe pojmenovat a tak. Aby to souhlasilo s tím, co to dělá. Protože přeci jen stále čtením strávíme více času, než psaním. Je dobré si to čtení co nejvíce zjednodušit. :-) Ale určitě nemá smysl měnit framework jen protože vyšel nový. V Pythonu či PHP taková situace jen tak nevznikne, ale v JavaScriptu by se každý den přepisovalo na nějaký nový… :-))
možná je tohle přesně způsob jak poznat seniora jeho schopnostmi a ne tím, že 4 roky programoval. Přepisování kódu, algoritmů, myšlenek je běžná programátorská práce, není-liž pravda? Zásadní problém je ale monolitický špatně strukturovaný kód plný edge vlastností a nedokumentovaných algoritmů, za to ale jednoznačně nemůže programátor, ale celý tým, který to tak nechal. Tenhle nešvar ale často ruku v ruce vídám s bohulibou myšlenkou psát celou aplikaci striktně v jednom jediném jazyku. Vždy člověk narazí na technologické možnosti a ohýbat jazyk, vymýšlet svoje "ověřené" algoritmy jsou v budoucnu velké bolístky. "Řekněte mi v kolika jazycích a v kolika jejich verzích provozujete aplikaci a já vám řeknu jak dobré máte programátory"
@Tomáš Popravdě si nejsem moc jist, jak celý komentář myslíte.
Pohnutky pro přepisování kódu from-the-scratch jsou zajímavé a moje zkušenost za 13 let programování je, že to je spíš záležitost psychologická než technickoodborná. Chvástání "já bych to napsal líp", lenost kód pochopit, ješitnost, že kód není ode mne, snaha ospravedlnit přepis na základě nalezení jedné bezvýznamné chyby, představa "údržba je nuda, tvořit nové věci je fun" atd. Pokud zvítězilo rozhodnutí přepsat kód od základu, bylo to ve většině případů proto, že jedinec nebo tým se s některým z uvedených bodů úplně emočně nevyrovnali. Takže zahodit starý kód pro nový může být jen falešné lákadlo na práci, která zpočátku vypadá nově a zajímavě, ale kvůli zahození množství předešlých zkušeností mohou opakující se chyby způsobit, že brzy omrzí. Naproti tomu postupně transformovat starý kód na nový je práce, která ze začátku vypadá jako nudná a obtížná, ale začne bavit později a za ten pocit, že se podařilo zlepšit kód "za pochodu", to stojí.
@Michal promiň asi jsem to vzal moc zkratkovitě. S článkem souhlasím, pěkně jsi to napsal, jen bych některé věci doplnil ze svého pohledu. Trochu bych to rozšířil, lehce mi z toho vyplývá, že tvrdíš, že na fungující kód se nešahá a nechává se hnít, to ale sám víš, že vede ke stejně špatnému stavu. Raději tvrdím, že kód musí být psaný tak, aby se dala jakákoliv jeho malá část rychle nahradit čímkoliv jiným. Strukturu kódu chápu jako technický pohled na kód, na to do kolika funkcí je rozdělený, na hierarchii tříd a jejich pojmenování. Já bych ale místo něj raději zmínil zodpovědnost jednotlivých vrstev, pro mě je daleko důležitější logika rozdělení než to do kolika tříd je kód rozložený a jestli náhodou nějaká funkce nedělá více věcí najednou. Validace vstupních dat je samozřejmě důležitá, ale nahradit se dá testováním a vede pouze k nestabilitě kódu a ne jeho dlouhodobé neudržovatelnosti, náprava je rychlá. Naopak dodržet striktiní pravidlo, že vstup funkce je imutable, nemá side effects nebo že funkce buď něco dělá nebo něco vrací, nikdy obojí. Úroveň zobecňování je důležitý aspekt, ale často se jí věnuje více času než si zaslouží. Já mám raději, když programátor čas věnuje UML a přestane používat globální stav k předávání informací. Zmínil jsem, že nemám rád, když je pravidlo aby kód byl striktně v jednom jazyku. Mockrát jsem zažil, že tahle zásada vedla k využíváním platformy do extrému, k používání nedokumentovaných vlastností zjištěných ze zdrojáků, k závislosti na konkrétní konstelaci systému atd. Takový kód je přesně ten, který je odsouzený k přepsání od nuly, rozpadá se jak domeček z karet, když se něco změní nebo aktualizuje. Přitom kód může striktině dodržovat code style, být dokonale pojmenovaný a rozdělený do tříd atd. Ano, vídám skoro všude, že noví programátoři chtěji vše hned přepisovat, jen ti zkušenější ví přesně proč a co tím získají. Nemám rád neustále přepisování bez jasného cíle jen kvůli nové technologii/módě a šahání do kódu jen abych ho přepsal. Mám naopak rád drobný častý refaktor při přidávání nových vlastností. Jen pro upřesnění, většinu svoji kariéry pracuji s C/C++/ObjectiveC, python, php/node.js, perl, R, linux a můj postoj je tím zádně ovlivněný.
@Tomáš Díky za doplnění. Souhlasím s Tebou. Drobný refactor určitě dělat, jen nemá smysl řešit takové ty samé klišé, které fungují, jen nejsou dokonalé. Ohledně příkladů jsem vypsal, co mi rychle přišlo na mysl tak, aby bylo představitelné pro všechny. Asi jsem měl vzít spíš konkrétní příklady a trochu je rozepsat. Nemám důvod nesouhlasit s tím, jak to rozepisuješ. Jen bych dodal, co mě při psaní napadlo trochu víc konkrétně: Například jsme měli novou funkční knihovnu na jednu část systému. Začali jsme ve stejném stylu přepisovat další a přitom jsme začali dělat revizi, zda je to OK. A dlouze jsme se dohadovali, na které vrstvě řešit transakce. Jestli validační chyby řešit vyjímkami. A další detaily. Udělat si revizi je fajn, ale zpětně mi přijde, že jsme moc času řešili tou samou debatou, jako s lidmi, kteří to dřív rozjeli. Bez nějakých opravdu dobrých argumentů to měnit. Jiný extrém je, že v jiném týmu je takové malé JSONové API a je to takový spíš spaghetti kód. Když jsem to viděl, měl jsem touhu to dát hned do pořádku. Ale pak jsem si uvědomil, že tím ničemu nepomůžu. Musím prostě nový kód napsat do správných vrstev jak nejlépe umím (i když to dá více práce, neb na to není připravena půda) a zařídit, aby se při úpravách takto pokračovalo. Mimochodem věta „noví programátoři chtěji vše hned přepisovat, jen ti zkušenější ví přesně proč a co tím získají“ je skvělá. :-)
@Tomáš Záluský Na jednu stranu souhlasím, na druhou stranu si dovedu představit situace (protože jsem je zažil), kdy je potřeba přepsat from-the-sratch. Například jsme před dvěma lety započali přepis celé aplikace. A ten přepis ještě dva roky poběží (můj soukromý odhad). Proč se tak děje? Protože způsob vývoje tolik zastaral, že nešlo bez toho začít automaticky deployovat, jednoduše testovat, spousta moderních featur se dělalo velmi těžkopádně s vekým prostorem pro bugy. Každopádně se to dělá po částech, funguje vedle sebe nový i starý kód, a přísun nových featur se neomezil. Což považuji za úspěch. Je teda možné, že každý budeme myslet pod pojmem from-the-sratch něco jiného. :-)
Covece, nesouhlasim:) V predchozi firme se taky stale dokola prepisovalo. Pak jsme si na to ale opravdu sedli, vymysleli hodne dlouho a detailne architekturu cele aplikace a dalsi projekt, co se podle toho udelal uz se prepisovat imho nemusi. Mozna se da refaktorovat, ale architektura uz je good enough na dalsi rozvoj i udrzbu.
@Daniel Milde: Však to nijak nevylučuji, spíš naopak. Pokud je to špatně, pak určitě dát dohromady. Ale pokud se jednou dohromady dalo a stejně to není nejideálnější, pak nemá podle mě smysl se v tom znovu dlouho babrat. A to je o čem mluvím. Tedy kdybych se mohl vrátit, tak o čem debatujeme už kvartál, bych podstatně zkrátil. Přiznejme si, že jsme stejně nic nevymysleli a akorát nás to hodně zdrželo. :-)
Tohle si právě nemyslím, no. Kód nikdy není úplně dokonalý, ale minimálně architektura se dá dotáhnout do stavu, který nebude v budoucnu dělat problémy. Protože pokud to není ideální a člověk se v tom nepohrabe a nedotáhne to, tak když se v tom napíše další spousta kódu, tak se to týmu jednou nehezky vrátí.
@Daniel Milde: Myslím, že si nerozumíme. Ty mluvíš o tom, že je potřeba architekturu mít dobře. O to se nepřu. Já říkám, že nemá smysl stejné věci řešit neustále dokolečka. S tím, že i architektura nemá smysl řešit dokolečka. Ideálního stavu stejně nedocílíš, neb přijde další a bude mít pod pojmem ideál něco jiného. A toho jsem si všiml – původní autoři měli ideál jinde, než programátoři, kteří sedí u projektu dnes. Přitom to není ani rozmezí dvou let. A už za mnou chodili další s dalšími nápady, jak to udělat jinak. Samozřejmě větší časové rozmezí, za které se hodně věcí změní (jiné technologie, frameworky, …), je zase jiná pohádka.
1 visitor upvoted this post.