Portál AbcLinuxu, 14. června 2024 16:17
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 :
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í.
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
Tiskni Sdílej:
jmeno te firmy, na kterou si mame davat pozor, se asi nedovime, ze ?
No a jak jste na tom u vás?
Slovo kvalita a plnohodnotný by měli vyškrtat ze slovníku.
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)
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.
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.
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.
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.
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.
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í.
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.
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. :)
Uz to mam. :)
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.
Aha, to zni zajimave. Co to? Kde to? Kdo to? ;)
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
A jak rikam, trochu to vyvraci ten trojuhelnik, protoze ten trojuhelnik je linearni, praxe ne.
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
Predevsim, Linuxove jadro jako takove neni omezeno penezi, takze tam diskuse management vs. vyvojari nehrozi.
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?
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.
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.
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ě“
Nejlepsi je to potom predat zakaznikovi, at se rozhodne samTohle 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:)
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
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.
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.
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é.
a ne jen drahé, ale spíš aby nebyli nemožné.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.