Proč ne automatické testy a noční buildy

10.2.2012 17:44 | Přečteno: 3900× | | poslední úprava: 10.2.2012 17:58

V práci se mi stala nemilá událost, a začínám chápat proč většina programátorů nemá moc ráda novoty.

Dělám na jedné monstr aplikaci, která by automatické testovaní a CI (continuous integration) potřebovala jako prase drbání. Build obvykle trvá 40 minut, není automatizovaný a výstupem je 1GB instalátor. S tímhle je radost pracovat, takže obvykle děláme milestone každé tři měsíce. Prostě se dvě měsíce tříská do klávesnice a pak to měsíc zkoušíme zkompilovat.

Jako správný mlamoj (mladý neklidný a moderní) jsem se s tím rozhodl něco udělat. Můj prvotní naivní požadavek na zastavení práce na tři měsíce a naprogramování základních testů tvrdě narazil. Šéf to označil za fantasmagorii a zakázal mě i pomyslet na něco podobného v pracovní době. Základní argument proti byl, že náš projekt je "special", od ostatních se dost odlišuje (asi jako zvláštní škola) a my unit testy nepotřebujem.

Pro úplnost dodám že unit-testy používám velmi úspěšně ve svých open-source programech. Plán který jsem předložil byl docela propracovaný a měl i podporu několika dalších programátorů a testerů.

Vzal jsem to do dalšího levelu a v podstatě za zády vedení nastavil Hudson s nočními buildy. Trvalo to asi 40 hodin rozprostřených do tří měsíců. Náš build system má asi 20000 řádků v 'bat' souborech, používáme Visual Studio 97 a Delphi 6, build vyžaduje součinost tří virtualních mašin... No prostě lahůdka, kterou jsem si to patřičně užil, ale nakonec to fungovalo.

Postupně jsem to oznámil ostatním programátorům a vychytal mouchy. Měsíc po instalaci se Hudson ujal a začali ho používat všichni. Do teď skvělá pohádka s happy-endem.

Ale půl roku uplynulo a moje produktivita začala upadat.

Obvykle dělám na problémech, které vyžadují několik týdnů na opravení a mají velké riziko že se povlečou. Dřív jsem si to hlídal a obvykle přibral hodně malých bugů, abych vybalancoval statistiku. Před Hudsonem se průměrné hodnocení dělalo každé tři měsíce (po tom co testeři otestovali milestone), teď se testuje průběžně a statistiky se dělají každý týden. Prostě šéf se každý týden podívá do bugzilly, vidí že já jsem tenhle týden neopravil žádný bug, a udělá si u mě černý puntík.

Další problém je že jsem "chlápek zodpovědný za Hudson". Když hudson pošle error mail, je na mě vystopovat kdo udělal chybu, a dokopat dotycneho člověka, aby ji opravil. Pokud nedej bože chybu opravím sám, tak dostanu vynadáno co se hrabu v jeho kódu. Pokud se build nepovede pár dnů v řadě, dostanu vynadáno od testerů, kde je poslední build.

Dále Hudson přispěl ke "zprůhlednění vývoje". Tzn pokud někdo opraví bug špatně a tester ho znovu otevře je to okamžitě vidět. Jenže jsem na tom bit zase já, protože typ problémů které opravuju prostě nemůžu 100% otestovat než je commitnu. Za poslední měsíc mám 5 znovuotevřených bugů, což je solidně nejhorší statistika.

A v poslední řadě jsem se připravil o "buildovací neděle". Před Hudsonem jsem 5% času dělal buildy pro ostatní. Tzn seděl jsem doma, škrábal se na zadku a četl reddit. Díky náhradnímu volnu jsem pak mohl v pátek dřív domů.

Na konci roku máme performance review, o Hudsonu samozřejmě nepadlo ani slovo (neoficiální projekt) a místo toho jsme dělali čárky za každý uzavřený bug. Takže jsem otřepal CV a brzy nastupuju v nové firmě

Sečteno a podtrženo: Hudson obrovsky zvedl produktivitu celého týmu (a moji), ale já díky němu vypadám jak nekompetentní idiot. Šéf si díky Hudsonu začal dělat debilní statistiky, které zvýhodňují 'bušiče formulařů' Navíc jsem ztratil docela dobrou práci.

To mě přimělo se zamyslet proč hromada programátorů nemá ráda nové nastroje (VCS, CI, unit testy..). V podstatě nasazení těchto nástrojů je výhodné pro firmu, ale ne pro programátora. Díky těmto nástrojům má vlastník kódu (firma, ne programátor) větší kontrolu a může klidně vyhodit celý tým a vývoj odlifrovat někam do tramtárie. Tohle nehrozí pokud je zdroják v podstatě neudržovatelný pro cizího člověka.

Další krok v téhle úvaze je, že je v podstatě je proti našemu zájmu dávat tyto nástroje svým nadřízeným. Jistě, můžeme dál psát unit testy a dělat CI, ale čistě sobecky by jsme je měli schraňovat pro sebe.

A další krok může být regulérní business model založený na téhle úvaze. Jako firma můžeme poskytovat zdrojáky ke svým produktům (a odfajkovat si open-source), ale zatajit unit-testy. Navenek tak můžeme prohlašovat, že unit-testy jsou k prdu, a mi máme tým genialních programátorů. A také za naše geniální programátory patřičně účtovat...

A na závěr ponaučení: Pokud někdo zakazuje věc, která by měla být standard, klidně ji použijte, ale nedávejte mu ji. A vůbec nejlepší je při prvním vyslovení "nepotřebujem unit testy" se na podpadku otočit, odejít a ani nezahajovat diskuzi.        

Komentáře

[Aleš Kapica]

Sečteno a podtrženo: Hudson obrovsky zvedl produktivitu celého týmu (a moji), ale já díky němu vypadám jak nekompetentní idiot.

Jo. Tak to obvykle chodí.

[Mrkva]

Náš build system má asi 20000 řádků v 'bat' souborech, používáme Visual Studio 97 a Delphi 6,

A kdyby ta firma dělala do cateringu tak používá pazourkové nástroje, co?

[Trained.Monkey]

Velka cast aplikace je v Jave a delame nove UI v JQuery, takze to celkove neni zas tak hrozne. Ja ale vetsinou delam na 'dark side', takze si tech pazourku uziju hodne.

[tomasi]

diky za hezky clanek, mas dobry pristup... Mel jsi se domluvit na jinem systemu hodnoceni a domluvit se predem, ze pracovni doba ti zabira tolik a tolik procent z Toolem a oprava defektu tolik a tolik, proto mas maly pocet opravenych defektu. Mel jsi take pozadovat zmenu pozice z opravatora bugu na "spravu Hudsonu" Tvuj manager nechtel inovovat a ty jsi delal neco nekaleho. Delat "za zady" jinou praci si musis dovolit, popripade ji mit posvecenou. Nektere firmy asi inovatory nechteji...

[Trained.Monkey]

Ja myslim ze Hudson zvedl produktivitu a boss se toho chytnul. Takhle je mozne zvyseni produktivity pricist jeho "skvelemu" rizeni.

[John Hartigun]

Podle toho pipisu vypada ten boss jako poradnej ***. Nejak casto je ve vyvojovem tymu sef ten nejneschopnejsi.

[John Hartigun]

(nejneschopnejsi clen)

[rastos]

To som zvedavý, čo sa stane, až na Hudsone prestane niečo fungovať a bude treba človeka, čo sa v tom vyzná a čo to fixne. Možno za rok, budú naspäť pri "Prostě se dvě měsíce tříská do klávesnice a pak to měsíc zkoušíme zkompilovat."

Nie je šanca, že by sa za teba postavili nejakí senior-kolegovia, ktorí vidia a chápu prínos systému?

[Aleš Kapica]

Nie je šanca, že by sa za teba postavili nejakí senior-kolegovia, ktorí vidia a chápu prínos systému?

Nerad bych se tímto někoho dotknul. Sám nejspíš za chvíli do kategorie "senior" spadnu. Ale tito lidé se obvykle nejvíc těmto novotám brání, protože mají své zažité postupy. Stíhat, mít přehled o kdejakém softu co se kde šustne, a zároveň na něčem kloudném dělat prostě není dlouhodobě možné. Takže si každý - ač nerad - musí po určité době přiznat, že technologicky zaostává. V opačném případě nutně něco znedbává.

[Bluebear]

Stíhat, mít přehled o kdejakém softu co se kde šustne, a zároveň na něčem kloudném dělat prostě není dlouhodobě možné. Takže si každý - ač nerad - musí po určité době přiznat, že technologicky zaostává. V opačném případě nutně něco znedbává.

Ještě je možné zanedbat společenský život a rodinu. Pak vzniká klasický dlouhovlasý rozježený hacker, co bude i v šedesáti naprosto kompetentní, uznávaný a vážený celou komunitou a někdy i trochu známý mimo komunitu; ale k jeho uchu nikdy nedolehne hlas syna, dcery ani manželky, a na jeho pohřbu budou jenom geekové. Nicméně je to také cesta.

[Aleš Kapica]

Přesně tohle jsem tím měl na mysli.

[Bystroushaak]

k jeho uchu nikdy nedolehne hlas syna, dcery ani manželky, a na jeho pohřbu budou jenom geekové.

No, to je teda tragédie :D

[rastos]

Ale tito lidé se obvykle nejvíc těmto novotám brání, ...

Píše, že ... a měl i podporu několika dalších programátorů a testerů. A to bolo ešte pred zavedením. Ak sú jeho kolegovia aspoň trocha kompetentní, tak prínos vidia a mali by to vedieť uznať.

[vencour]

Přidal jsem do výběru.

[ThePilgrim]

Situaci podobnou tomu zaveru znam taky. Firma (mezinarodni, par tisic zamestnancu) nasadi novej "framework" pro tvorbu aplikaci pro testovani / kalibraci ve vyrobe urcitych pomerne komplexnich nastroju. Prezentace o systemu sice super ("katovani kostu", o 300% vyssi efektivita, atp.), ale bohuzel, system ma jeden drobny nedostatek - v podstate jedina dokumentace co k nemu je sestava prave s tech prezentaci v Powerpointu.

Kdyz potom prijde nekdo z venku (muj pripad), jedina moznost jak v tom neco delat je osobni kontakt se dvema / trema typkama, co to vsechno udrzujou. Nasleduje pul roku stravenyho nad vicemene denodennim zoufalstvim nad debuggerem zjistovanim proc se objevuje vyjimka ve tride s nazvem "[Assembly | Utility | Resource][Helper | Manager | Assistant][.*]*" a prakticky nulovou dokumentaci kodu... Po prvnich par tydnech jsem dosel k zaveru, ze chlapci asi maji pomerne slusne zajistene zivobyti.

[Ivan]

To snad ani neni mozny jak je to presny a jak to sedi. Nedelas nahodou ty samy nejmenovany finacni instituci?

[Peter S.]

Človeče, ved ty vôbec nerozumieš projektovému manažementu. Taký systém sa nenasadzuje len tak, že vraj 40 hodín práce. To sa najprv musi urobiť analýza či je takéto niečo potrebné, zostaví sa projektový team, začnu sa pravidelné konf. cally a o pár týždnoch sa pripraví prezentácia pre vedenie kde sa vyčíslia náklady a prínosy. Urobí sa odhad hodín potrebných pre implentáciu - ak to budete robiť interne, tak aspon 200-400 hodín. Ale vždy sa odporúča mať aj externé náklady, bud nejaké licencie (čim drahšie, tým dôležitejší projekt) alebo aspon cena podpory pri implementácii. A až potom by si bol členom projektového teamu a bol by si v suchu. Ono takéto projekty su takmer vždy uspešné, maximálne sa ex post zmení cieľ alebo rozsah projektu.

no a takto to žiaľ vo veľkých firmách chodí :)

[mozog]

To mi pripomina znamou hlasku ze serialu Jiste, pane ministre a Jiste, pane premiere Ustavime mezirezortni komisi ...

[xvasek]

To, co píšeš, je velká pravda. Ovšem někdy má člověk prostě nutkání udělat něco správného a té touze "začít hned teď" se hrozně těžko odolává.

[lambda]

Můžu potvrdit. Čím větší moloch, tím zkostnatělejší přístup a potažmo efektivita využívání zdrojů. Asi nebude náhoda, jak jsou si v tom podobné velké korporátní organizace s mnoha patry řízení a org. státní správy nebo státními podniky.

Ještě bych přidal, že kromě běžného přivlastňování si zásluh nadřízeným a svalování případných problémů opačným směrem, práce odváděná nad rámec požadovaného vyvolá v nadřízeném místo očekávaného uznání pocit ohrožení jeho pozice a podle toho se k Vám i začne chovat.

[Opravář]

Díky za příběh. Hodně mi to připomíná mou situaci před léty. Jen s tím rozdílem, že já jsem nasazoval Jiru (bug tracking). Ani si nepřej vědět, jak se tam před tím sledovali požadavky a chyby.

Ale nelituju, že jsem odešel. Našel jsem si lepší flek, kde se vyznává princip od kolébky po rakev, tedy vytvoříš, nasadíš, rozvíjíš. Dbá se sdílení znalostí a puntíky se rozdávají za ošklivý kód, nebo průsery na produkci. A musím říct, že mi ta výmněna znalostí vůbec nevadí, hodně se naučím a až mě zoptimalizují, budu mít alespoň čisté svědomí.

Držím palec, ať se ti daří.

[Bluebear]

Tesat do kamene.

Máš můj hluboký soucit; byl jsi moc hodný, přesněji, upřednostnil jsi svou práci před svým prospěchem. Velmi si vážím lidí, kteří jsou schopni jít za svým cílem, i když jim za to nikdo neděkuje. Problém je v tom, že to je činnost, za kterou je jedinou odměnou splnění toho cíle (a to jen v nejlepším případě). A úcta pár lidí - ale úcty se nenajíš, ani tě před ničím nezachrání, bohužel.

[xvasek]

Hm, jak to tak čtu, tak začínám přemýšlet, že můj tajný pracovní projekt zůstane v utajení napořád...

[loki]

Pekny zapisek. Skoda, ze jsi prisel o praci. Zkousel jsi jit treba o dalsi instanci ve vedeni vyse a tam vylozit to, co jsi pro spolecnost udelal?

[Trained.Monkey]

Nechapu proc, v nove praci mam lepsi podminky a vetsi plat. Nehodlam si nicit nervy.

[pavlix]

+1

Když se člověk snaží něco udělat, tak alespoň zjistí na čem s danými lidmi je. Já si tímhle způsobem jako OSVČ ověřuju partnery taky. Občas je lepší ustoupit a nechat je, ať si najdou někoho jiného, kdo jim bude dělat blbce :).

[loki]

Jiste. Kdyz to beres takto, je vse v nejlepsim poradku.

[Grunt]

Tohle není o podmínkách, platu nebo nervech. Tohle je o principu.

[alkoholik]

Jenom dve veci:
Uz nejaky patek to neni Hudson, ale Jenkins.
Kdyz to byl neoficialni projekt, tak jsi ho mel radeji zlikvidovat, ze delat bossum saska. Idioti jsou oni.

[Trained.Monkey]

Jenkins je fork, Hudson porad existuje a ja nemam duvod prechazet.

[alkoholik]

Tak podle wiki "Both the Jenkins and Hudson projects appear to consider the other to be a fork."
Podle konferek "Jenkins is the new Hudson. It really is more like a rename, not a fork, since the whole development community moved to Jenkins. (Oracle is left sitting in a corner holding their old ball "Hudson", but it's just a soul-less project now.)"
A prinejhorsim se clovek zepta.
;)

[Trained.Monkey]

Zaprvy neni pravda ze vsichni odesli, nekteri vyvojari zustali u Hudsonu.

Za druhy Hudson je "software poskytovany Oraclem zadarmo", coz ma u mananagoru patricne grady. Nasazovat Jenkins odnekud z githubu je na hodne dlouhe vysvetlovani.

Za treti tohle se stalo drive nez nejaky Jenkins vubec existoval.

[dementni.lojzik]

Zaprvy neni pravda ze vsichni odesli, nekteri vyvojari zustali u Hudsonu.

ne ze bych to nejak podrobne sledoval, ale AFAIK odesli vsichni vyvojari jadra a u pluginu drtiva vetsina, i kdyz je pravda ze mnozi z nich se snazi udrzovat pluginy kompatibilni jak s Jenkinsem tak Hudsonem (ale neodvazuju se odhadovat, jak moc velka cast)

Za druhy Hudson je "software poskytovany Oraclem zadarmo", coz ma u mananagoru patricne grady. Nasazovat Jenkins odnekud z githubu je na hodne dlouhe vysvetlovani.

jo, tohle je asi nejvetsi deviza Hudsonu, ze za nim stoji Oracle a Sonatype, takze to dobre zni. Nicmene Hudson se presouva pod Eclipse foundation, takze bych si nebyl uplne jisty tim, jak dlouho za nim Orcale bude stat

[xkucf03]

Podle toho, co jsi nepsal, tak práce pod takovým vedením musela být dost děsná i bez toho, že jsi zavedl CI a vyžral sis následky. Jestli někdo počítá jen čárky v bugzille a nedokáže mentálně uchopit, že pracnost jednotlivých „čárek“ se liší, tak to sorry, ale taková práce a vedoucí si tě nezaslouží a měl jsi odejít už dávno.

[Grunt]

že jsi zavedl CI a vyžral sis následky. Jestli někdo počítá jen čárky v bugzille a nedokáže mentálně uchopit, že pracnost jednotlivých „čárek“ se liší, tak to sorry, ale taková práce a vedoucí si tě nezaslouží a měl jsi odejít už dávno.

Hele, zdá se mi to nebo v podstatě říkáš: „Místo vykazování činnosti si se snažil dělat něco užitečného — dobře ti tak, ty lečo!“?

[xkucf03]

Ne, naopak – on si tam mohl v klidu žít/živořit, kdyby nezaváděl žádné „novoty“, šel s davem a ignoroval hloupého šéfa – ale taková práce by mě nebavila, a proto jsem radil, že měl odejít už dávno.

[Tyf]

Nejak me mate znovuotevirani chyb.

Mozna u verejnych chybohlidacu, kde nalezce po reportu uz nikdo nikdy neuvidi. Ale ve firme je lepsi kdyz vyvojar posle po oprave chybu zpet testerum ke kontrole a ti bud zavrou nebo vrati. Nebo to delaji jinde jinak?

[Bluebear]

Ne, to je poměrně normální situace. Vývojář opravil chybu, poslal nový kód testerům, ti otestovali známé situace, kdy se chyba projevovala, zkonstatovali, že chyba už se neprojevuje, a bugreport byl uzavřen.

Ale po čase se zjistilo, že chyba byla opravena jen částečně (například proto, že byla na více místech, nebo byl opraven jen jeden její aspekt, v nejhorším případě byl opraven jen její následek, ale ne chyba samotná) a projevuje se teď jiným způsobem nebo v jiných situacích. Pak se bugreport znovu otevře.

[xvasek]

No, já to znám takto: Pokud se např. při zaúčtování faktury v ostrém systému začne objevovat nějaký neškodný warning, jehož původ jsem lokalizoval a opravil, tak to nechám tak a prohlásím to za funkční - nebudu testovat zaúčtování faktury (v ostrém systému) a nebudu ani půl hodiny čekat na kopii, abych si to otestoval sám. Uzavřu to teda a nechám tak, občas se to vrátí, ale mě nikdo za znovuotevřené chyby neterorizuje.

[Matz]

Seriozne, aky je dovod zostavat vo firme, ktora hodnoti programatora podla poctu zatvorenych bugov?

[xxx]

To je ale nahoda: Dilbert 2012-02-12 :)

[Filip Andres]

Ahoj, a nechces jit delat k nam do GoodData? Urcite bychom nekoho takoveho potrebovali

Filip, filip.andres@gooddata.com