Management a kvalita kódu

8.5.2009 19:10 | Přečteno: 1593× | programování | poslední úprava: 8.5.2009 20:47

Jedna věc mě poslední dobou hodně pálí. Je to postoj vedení ke kvalitě výsledného kódu. Prvotní důvod je jasný, je to čas a jsou to peníze.

Opravdu mě dokáží naštvat věty :

• Kluci, je to projekt za pár šupů, tak se s tim moc nepárejte
• Zákazník na to vážně spěchá, takže není čas na nějaké přemýšlení, prostě to bušte

Nevím jak vy, ale já jsem se s podobnými větami setkával vcelku často, a nevím, jestli se mi povedlo z tohoto kruhu dostat ven. Je to věc, která mě velice demotivuje a to je při práci na jakémkoliv projektu to nejhorší.

Ovšem nejde jen o demotivaci. Když totiž vše náležitě a svědomitě ošidíte, jak vám bylo nakázáno, pak se můžete dostat do jedné ze dvou situací.

• Projekt je tak velký, že každým dnem je práce na něm pomalejší a pomalejší
• Projekt je sice krátký, ovšem za půl roku přijde klient s tím, že ho chce rozšířít, či jinak modifikovat

Je asi jedno, která z těch dvou situací je horší. V každém případě se na vás jako vývojáře shora snese velké množství kritiky a někdy i nadávek. V prvním případě nikoho nezajímá že nestíháte. V tom druhém případě nikoho nezajímá, že cena úprav je tak vysoká, že vás s tím zákazník pošle někam. Všechno je vaše chyba. Vy jste zodpovědní za svůj kód. Tvrzení o zodpovědnosti je jasný fakt, a musí to tak být. Ovšem pokud mám za něco zodpovědnost, pak rozhodnutí o důležitých věcech by mělo stát na mě.

Je jasné, že ohledně softwarových projektů je velice obtížné jakkoliv změřit výslednou kvalitu kódu, ba co víc, je to téměř nemožné. Ovšem myslím si, že není tak důležité produkovat ten nejkvalitnější kód, ale snažit se vymáčknout ze sebe maximum. Když se totiž tým snaží vydolovat ze sebe to nejlepší, pak každý jeho projekt je lepší a lepší. Pracovat je pak radost. No a jak jste na tom u vás?

Na závěr doplním graf, na kterém je vidět, jak se kvalita designu podepisuje na rychlosti tvorby projektu. Je to obrázek ze stránek Martina Fowlera

       

Komentáře

[dad]

jmeno te firmy, na kterou si mame davat pozor, se asi nedovime, ze ?

[pasmen]

Tohle znám a je to na hovno. Já to zatím řeším tak, že i když se mi řekne "není čas, prostě to udělej rychle ať to nějak běhá", tak to většinou nějak opravdu narychlo zbastlím, ale většinou na to pak sednu doma a kód čistím, protože se zatím vždycky stalo, že se dřív nebo pozdějc muselo to či ono dodělat/změnit. A taky se mi kolikrát stalo, že to prostě nešlo, protože návrh/cílový koncept byl prostě k ničemu. Kupodivu se na mě zatím nikdy neřvalo, že je to moje chyba, ale já osobně ztrácel motivace (jak už jsi psal ty). Co z toho pro mne plyne: do zadání či cílového konceptu aktivně kecat a vždy být o krok nebo dva v myšlenkách napřed. Jakmile je zadání hotové, už mi nikdo nemůže bránit v tom dělat to správně

[Jan Včelák]

To si můžu říct taky, ale pak na to bohužel nikdy není čas. Nebo spíš ten čas chci věnovat něčemu jinýmu, než čištění kódu... Řikám, si: když to běhá, tak do toho nebudu vrtat. A pak když přijde ten moment, kdy se tam musí něco změnit, tak to většinou všechno smažu a napíšu znova. Je to rychlejší, a často efektivnější. Už v hlavě mám nějakej koncept a už vím, co jsem předtim mohl udělat líp. Většinou to vede ke kratšímu a přehlednějšímu kódu.

[Grunt]

No a jak jste na tom u vás?

Slovo kvalita a plnohodnotný by měli vyškrtat ze slovníku.

[JS]

No, co k tomu dodat. Jeste, ze delam v solidni americke firme, a moji sefove chapou, co znamena delat software poradne.

Co se tyce spolecenske organizace, lidstvo se jeste ma co ucit: http://en.wikipedia.org/wiki/Maverick_(book)

[rastos]

Ak robíš X pre niekoho a ten niekto to chce "síce odfláknuté, ale rýchlo" tak najlepšie, čo môžeš urobiť, je vysvetliť mu, že to čo chce je blbosť (najlepšie písomne). Ak sa nechá presvedčiť - dobre. Ak sa nenechá, tak mu urob to, za čo ťa platí. Ak to znamená, že sa ti to vráti ako bumerang - nevadí. Znamená to len, že máš ďalšiu prácu a dostaneš za ňu zaplatené. To je vlastne pozitívna vec. To, že v zamestnaní robíš niečo, čo sa ti nepáči, je skôr pravidlo ako výnimka. Je na tebe, či sa s tým dokážeš zmieriť (a či sa ti podarí nájsť miesto, kde je to inak).

X môže byť software, alebo čokoľvek iné.

[dad]

hm, ale zamestnavatele nejsou tak hloupi, aby rekli - ze se to ma odflaknout. Chytry management rekne - ze treti nejlepsi reseni je to ekonomicky nejvyhodnejsi a pak mate zase cerneho petra.

[RapMan]

U nas je tomu tak, ze to nikdo neresi. Protoze se pohybuju v oblasti prumyslovych zarizeni, kde je vetsina vedoucich hardwarove zalozenych, o software nemaji ani paru. Kdyz ma zarizeni jiny konektor nez to predchozi, delaji z toho nehorazny humbuk, ale kdyz je na nem pouzita uplne jina softwarova platforma, nikdo to neresi. Takze tak je tomu u nas.

[hajoucha]

Ahojda, co pišeš je důležité téma a je dobře, že se o tom mluví (či píše). Přesto si ale dovolím malou poznámku, která až tak moc s tématem nesouvisí - ten graf je docela ale docela kvalitativní. Příslušné křivky jsou podle všeho vycucané z prstu. Tj. nenašel jsem, že by byly výsledkem nějakého matematického modelu, který by se dal testovat nebo tak něco. Někdo si prostě sedl a nakreslil dvě čáry, aby to vypadalo vědecky. Myslím, že by ten dotyčný udělal lépe, kdyby si to odpustil a místo toho napsal slovy, co má vlastně na srdci. 

[deda.jabko]

ten graf je imho blbe a i jeho interpretace je odflakla.

priklad je ta primka pro ,,dobry design''... podle me by to mela byt funkce f(x) = x^n (pro nejake n > 1). jelikoz dobry design vyzaduje, aby se urcity cas venovalo jenom jemu a implementace funkcionality stoji.

dalsi veci je, ze se v intepretaci ignoruje delici cara. pokud je pozadovany program svou funkcionalitou hodne pod delici carou nema smysl resit nejak design.

[crunch]

1. Co se týká designu a stojící implemetace, tak si dovolím nesouhlasit. Já osobně vyvýjím za pomoci Test Driven Development, kde je jasně řečeno, že design vzniká při implementaci a testy řídí jeho podobu. Něco o TDD určitě bude v některém z dalších blogpostů.

2.Ano v tom máte pravdu, já jsem ovšem ještě nepracoval na takovém projektu, abych se pod tuto dělící čáru dostal. Nebylo ani mým cílem toto jakkoliv komentovat, graf o tom mluví jasně. Já jsem jen presentoval problém, na který velice často narážím.

[deda.jabko]

Co se týká designu a stojící implemetace, tak si dovolím nesouhlasit. Já osobně vyvýjím za pomoci Test Driven Development, kde je jasně řečeno, že design vzniká při implementaci a testy řídí jeho podobu.

no, tak misto prace na designu travite cas psanim testu. a jestli pouzivate najaky ten XP pristup tak je potreba jeste zapocitat cas na refaktorizaci, coz je dalsi duvod pro zmenu tvaru te krivku. navic, pokud o designu rozhoduji testy, tak tam nevidim moc velky rozdil od ad-hoc pristupu k programovani.

[crunch]

To že nevidíte rozdíl mezi ad-hoc přístupem je podle mého tím, že jste to nikdy nezkusil. Kvalita kódu, která tímto přístupem vzniká je opravdu vysoká. Co se týká ceny psaní testů, tak ta se mi zdá stejná jako jakékoliv testování, které musí každý programátor dělat, aby se ujistil, že jeho kód funguje. Výhoda napsaných testů je, že během pár vteřin si je mohu všechny zopakovat. Co se týká refaktorizace, tam něco je, ale to vše je v grafu zahrnuto. XP neprovozuji, a TDD je jen jednou malou součástí XP.

[crunch]

 

To že nevidíte rozdíl mezi ad-hoc přístupem je podle mého tím, že jste to nikdy nezkusil.

 

Omlouvám se, to je opravdu hodně zavádějící věta. Spíše bych napsal, že pokud zkusil, tak nevydržel. Spousta polopravd o TDD vzniká právě tím, že je velmi těžké s ním začít a vydržet u něj. Ta cena je vysoká a začne se vracet až po delší době provozování TDD. Kdo nevydrží, většinou ho pro sebe zatratí.

[Ladicek]

Jen trošku rejpalsky: které všechny xDD praktikujete? Nějak se s nimi roztrhl pytel, TDD, BDD, FDD, DDD, MDD, RDD… aby to nedopadlo špatně

[crunch]

Ano ten graf je vycucaný z prstu a dokázat se nedá. Vznikl za pomoci zkušenosti. Pokud tě zajímá jaké zkušenosti, stačí kliknout na ten link autora od kterého pochází. Ten důvod, proč je vycucaný z prstu je jasný, dodnes ještě nemáme žádnou techniku měření kvality sw projektu, která by se dala opřít o jasný matematický model a zohlednila všechny aspekty.

[Jirka bianco Vágner]

Nemuzu to najit, ale nekde jsem v knize videl krasny graf. Byl to rovnostranny trojuhelnik a na kazde spicce sedelo jedno slovo ze svate trojky - rychlost, kvalita a cena. Uvnitr tohoto trojuhelniku lezi kazdy  projekt. Dejte si to, prsknete tam tecku malou a sibujte s nim. Soustredte se napriklad na dva libovolne aspekty.  Kvalita a rychlosti? Ejhle cena se nam vzdaluje a roste. Zkuste i jinak. Funguje to. :)

[Jirka bianco Vágner]

Příloha:

• 6a00d83425845e53ef00e54f59ecd68834-800wi.jpg (24684 bytů)

Uz to mam. :)  

[JS]

No, nevim. Ja myslel, ze Mythical Man-Month ukazal, ze i kdyz zvysujete cenu (pocet lidi delajicich na projektu), nemuzete dosahnout vyssi rychlosti pri stejne kvalite - kvuli komunikacnim nakladum uvnitr tymu.

[Jirka bianco Vágner]

Aha, to zni zajimave. Co to? Kde to? Kdo to? ;)

[JS]

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

A jak rikam, trochu to vyvraci ten trojuhelnik, protoze ten trojuhelnik je linearni, praxe ne.

[Ladicek]

Tak to o přidání lidí do zpožděného projektu určitě platí (i když jsem kdesi četl článek, kterak důsledným používáním agilních technik dokážou přidávat lidi do zpožděných projektů s pozitivním výsledkem ), ale cena nemusí být jenom o počtu lidí.

Jinak já osobně bych řekl, že softwarový projekt, který se nevejde do jedné kanceláře, je fundamentálně špatný

[Jendа]

Jinak já osobně bych řekl, že softwarový projekt, který se nevejde do jedné kanceláře, je fundamentálně špatný

Linus by s tebou asi nesouhlasil

[Bluebear]

Kdo ví, možná by i souhlasil; možná by řekl něco v tom smyslu, že o tom ví, ale nenašel tolik géniů, aby jimi naplnil jednu kancelář, tak se musí spokojit s davem blbců.

V životě se bohužel musíme často spokojit s mizerným řešením, protože to ideální prostě není dostupné.

[Ladicek]

Naopak bych řekl (ale do vývoje jádra samozřejmě nevidím, je to jenom dojem), že vývojový model Linuxu k tomu velmi dobře pasuje: je to obrovský počet miniaturních softwarových projektů uspořádaných přibližně do stromu. Každý uzel by se pak do té kanceláře nejspíš vešel, kdyby každý člověk nežil na jiném místě na Zemi

[JS]

Predevsim, Linuxove jadro jako takove neni omezeno penezi, takze tam diskuse management vs. vyvojari nehrozi.

[Kvakor]

Ano, to je Brooksův zákon, pamatuju na sadu obrázků (které se mi bouhužel nedaří vygooglit), kde je na grafech ukázán lineaární vzestup výkonu (1,2, 3, 4, 5, 6, 7, 8, 9, 10 ...) a kombinatorický vzestup nákladů na komunikaci (0, 1, 3, 6, 10, 15, 21, 28, 35, 43, 52, 62 ...). Ať už jsou náklady na komunikaci jakékoliv, vždy existuje určitá hranice, za níž znamené přidání dalšího člena týmu takové dodatečné náklady , že celkový čistý nárůstek výkonosti je záporný. Čoý znamená, žese projekt zpožďuje, namísto aby se urychloval.

[Jendа]

Ať už jsou náklady na komunikaci jakékoliv, vždy existuje určitá hranice, za níž znamené přidání dalšího člena týmu takové dodatečné náklady , že celkový čistý nárůstek výkonosti je záporný.

Něco jako elevator story?

[Jendа]

Příloha:

• design-payoff.png (14335 bytů)

IMHO jak říká deda.jabko, tak by začátek grafu měl vypadat jako v příloze. Ono to chce vždycky si na začátku sednout se zákazníkem a popovídat si, co vlastně chce a podle toho vymyslet strukturu. Pak až má cenu začít něco dělat.

[JS]

Jestli ono to nebude tak, ze tomu grafu chybi 3. dimenze, ktera je pocet zdroju/lidi, kteri delaji na tom projektu. Takze, pokud je na tom dostatecny pocet lidi, muzete mit i pravdu. Ale realna tendence (v pripade uvedenem v blogpostu) bude dost mozna ten projekt poddimenzovat i co do nakladu, takze se vzdycky dostanete mimo tu spodni oblast.

[zr]

Nejsem nejakej super programator, ale jednou jsem delal na web projektu, ktery mel pro zobrazovani pouzivat XML data zkonvertovany do HTML pomoci XSLT. Ja jsem to delal presne podle puvodniho navrhu - muj kod generoval cistej XML s vlastnima znackama a na to se pak pouzila XSLT a ta z toho vyplivla HTML - myslenka byla, ze grafik pak zmeni pouze XSLT a do PHP kodu vubec nebude hrabat. Kolegove to spis kombinovali, cast HTML slo rovnou z PHP. Nakonec moji cast museli prepsat, protoze to s XSLT bylo zatracene pomaly.

Dalsi takovou vec ve stylu "rychle rychle" jsem videl v kodu systemu, kterej firma pouzivala jako svuj ucetni system. Kdyz jste to videli v akci, tak to bylo super - byl to kompletni system pro support, timesheet, prijmy/vydaje, proste super. Kdyz jste se ale podivali trosku podrobnejc do kodu, tak to byla hruza. Chapal jsem to az kdyz mi vysvetlili, ze to vznikalo postupne pridavanim funkci z puvodniho XLS stylem "udelej nam neco, co nam bude automaticky pocitat tohle" , "ted tam dodelej, aby to delalo tohle". Takze tam byla napr. takova vec, ze pro ucetnictvi se ucetni polozky zapisovaly do tabulky jako "uc2005". Kdyz pak prisel novej rok, tak se museli udelat posledni upravy v roce 2005 a pak se musely v kodu zmenit nazvy tabulek na "uc2006". Proste silenost.

Pokud teda prijde sef, ze chce neco rychle nabusit bez premysleni, tak je nejlepsi poslat email (pripadne s kopii i na dalsi lidi), ze bud to udelas hned a rychle, ale v budoucnu bude muze trvat hodne tam neco pridelat, pripadne to muze byt uplne nemozne, a nebo se to naprogramuje poradne a bude to dobre spravovatelny, ale bude to drazsi. Nejlepsi je to potom predat zakaznikovi, at se rozhodne sam, jestli pocita s rozsirovanim a zaplati radsi o neco vic za kvalitni navrh ted a pozdeji za upravy pouze min, nebo jestli ted zaplati malo, bude to mit rychle, ale pri upravach bude platit treba i stejnou nebo vyssi cenu a bude to trvat dlouho.

[xkucf03]

Nejlepsi je to potom predat zakaznikovi, at se rozhodne sam

Tohle moc nefunguje – zákazník těm technickým detailům nerozumí a ani o takových věcech nechce rozhodovat*. Spíš by to mělo být tak, že jako firma (dodavatel) máš určitý standard kvality, pod který nejdeš.

*) a pokud bude muset, tak si vybere tu levnější variantu, protože si bude myslet, že se z něj akorát snažíš tahat prachy navíc, za nějakou údajnou kvalitu, kterou on ve skutečnosti nepotřebuje – „vždyť to přece bude fungovat i v té levnější variantě“

[zr]

 

Nejlepsi je to potom predat zakaznikovi, at se rozhodne sam

Tohle moc nefunguje – zákazník těm technickým detailům nerozumí a ani o takových věcech nechce rozhodovat*. Spíš by to mělo být tak, že jako firma (dodavatel) máš určitý standard kvality, pod který nejdeš.

*) a pokud bude muset, tak si vybere tu levnější variantu, protože si bude myslet, že se z něj akorát snažíš tahat prachy navíc, za nějakou údajnou kvalitu, kterou on ve skutečnosti nepotřebuje – „vždyť to přece bude fungovat i v té levnější variantě“

Nene, ja mel prave na mysli mu dat pouze na vyber, ale samozrejme tam nelicit objektovy navrhy a podobne, ale proste jenom rict neco jako, ze za pozadovanou cenu a kratky cas se to napsat da, ale pokud by se s tim v budoucnu melo dal pracovat (upravy, opravy), tak to pak bude drazsi a bude to trvat dele. Nebo se ted muze udelat kvalitni navrh s nejakymi predpoklady do budoucna a pak by dalsi upravy/opravy byly levnejsi a rychlejsi. A je na nem, jak se rozhodne. A kdyz si vybere tu levnejsi variantu, tak aspon bude vedet dopredu, co ho ceka:)

[xkucf03]

Kluci, je to projekt za pár šupů, tak se s tim moc nepárejte. … Zákazník na to vážně spěchá, takže není čas na nějaké přemýšlení, prostě to bušte.

Tyhle věty mají evokovat pocit, že „tenhle projekt je zrovna výjimka, ale jinak to děláme samozřejmě pořádně“. Jenže ve skutečnosti je to pravidlem – zákazník nikdy nechce zaplatit příliš mnoho a nikdy na to nemáme tolik času, kolik bychom si ideálně představovali. Takže nemá cenu se takovými větami nechat obalamutit* a neslevovat z kvality návrhu  a kódu. Navíc ona ani neexistuje přímá úměrnost mezi „nějak to naprasím“ a „bude to rychle hotové“ – osobně si myslím, že ten zlomový bod nastává hodně brzo, resp. o těch výhodách nekvalitního kódu nemá cenu ani uvažovat.

*) já jsem se párkrát nechal a pak jsem zjistil, že to nebylo dobře

[Bluebear]

Nevím, čím to je, ale už několikrát jsem si všiml zajímavého úkazu: čím horší software, tím líp se prodává. To není specialita Microsoftu, to je nějaký zvrhlý tržní zákon. Nechápu, ale je to tak.

Viděl jsem to x-krát: jak jednotlivý zákazník, tak i celý segment trhu mají tendenci nejvíc kupovat ta nejhorší, nejodfláknutější řešení. A není to tak, že by šli po nejnižší ceně. Pokud je na trhu několik programů pro stejný účel, největší úspěch má ten nejhorší. Podobně, pokud jako firma prodáváte několik různých softwarových produktů, z nichž některé jsou dobré, jiné průměrné, pár horších a pár fakt strašných, tak zákazníci budou nejvíc kupovat tu nejhorší hrůzu, a to i tehdy, když je předražená.

[JS]

Mozne vysvetleni je v http://en.wikipedia.org/wiki/Market_for_Lemons

Jestli to take nebude tim, ze vyrobci tech "strasnych reseni" investuji penize do marketingu/sales misto do vyvoje. A diky asymetrickym informacim (viz vyse) se jim to vyplaci.

[Ladicek]

Unix… Céčko… Worse is Better…

[xkucf03]

To může být tím, že ty máš jiná kritéria pro kvalitu než uživatel-zákazník. Ty dáváš asi přednost technické dokonalosti a kvalitě kódu, zatímco zákazníka spíš zajímá, co mu program přinese – jde tedy hlavně o to, jaký má ten program nápad – jak dobře je napsaný, je plus mínus jedno, pokud funguje.

[crunch]

A tohle jde podle mě ruku v ruce s kvalitou kódu. Zákazník a většinou ani management si neuvědomují že dosáhnout softwaru takového, který by zákazníkovi opravdu přinesl užitek a peníze se jen těžko dá na první pokus. Já říkám, že jedinou jistotu, kterou v projektu máme je, že budou změny v zadání. Ale na ty musíme být připraveni dostatečnou kvalitou kódu, tak aby nebyli drahé.

[crunch]

a ne jen drahé, ale spíš aby nebyli nemožné.