Cena změn
Školení, která pořádám 
Čtu teď knihu Dokonalý kód, která na svém začátku zdůrazňuje důležitost kvalitního návrhu při vývoji software. Dokládá to několika studiemi renomovaných společností, které prokázaly, že pokud se chyba odhalí až při programování, tak její oprava stojí desetkrát víc, než když se eliminuje hned na začátku, a pokud se odhalí až při testování nebo po uvolnění produktu, tak dokonce až stokrát víc. Samozřejmě souhlasím s tím, že je kvalitní návrh důležitý a že chybám je vhodné předcházet nebo je řešit co nejdřív. Trochu mě ale mrzí, že se nákladnost změn bere jako fakt. Možná se tomu budou věnovat další kapitoly, ale podle mě stejně důležité jako kvalitní návrh je udělat vše pro to, aby oprava chyb a obecně jakékoliv změny byly co nejlevnější. Chybám a změnám se dá různými způsoby předcházet, ale v praxi se jim stejně nevyhneme, tak je možná lepší se s tím naučit žít.
Uvědomil jsem si, že mé nástroje NotORM a Adminer Editor slouží právě ke snížení náročnosti změn. Ukázal bych to na příkladu: U adresy jsme vedle ulice a města zapomněli na PSČ.
Jak ho přidáme v běžném programu?
- Přidáme sloupec do databáze.
- V administraci přidáme políčko do editačního formuláře.
- V administraci necháme políčko ukládat.
- V prezentaci přidáme sloupec do dotazu
SELECT ulice, mesto. - Pokud používáme šablony, tak PSČ předáme šabloně.
- V šabloně umístíme PSČ na správné místo.
- Vytvoříme
ALTER TABLEpro nasazení na produkci. - Změny commitneme.
- Zavřeme task.
Jak se dá úloha vyřešit pomocí generátorů (např. Doctrine)?
- Přidáme vlastnost do odpovídající třídy.
- Spustíme skript pro promítnutí změn do databáze.
- Přegenerujeme administrační rozhraní.
- Od bodu 6
stejněobdobně.
Jak se dá stejná úloha vyřešit s vhodnými nástroji?
- Přidáme sloupec do databáze. Adminer Editor ho automaticky zohlední v administraci.
- V šabloně umístíme PSČ na správné místo. NotORM si ho automaticky vytáhne z databáze a předá šabloně.
- Změny commitneme. Redmine nebo jiný systém task automaticky zavře pomocí zprávy „fixes #123“.
Odlišný může být i proces nasazování změn (obvykle více najednou). Kromě přenesení nových souborů je obvykle také potřeba změnit databázi. To se dá vyřešit buď tak, že pro každou změnu píšeme ALTER TABLE, které pak při nasazení spustíme. Nebo průběžné změny neřešíme a při nasazení využijeme ALTER export Admineru.
U složitějších úloh je rozdíl ještě patrnější: Místo sloupce autor chceme vytvořit tabulku všech autorů a odkázat se na ni.
Kromě úpravy databáze a přelití dat musíme v běžném programu udělat ještě tohle:
- Vytvoříme nový formulář v administraci pro editaci nové tabulky.
- Stávající formulář upravíme tak, aby s novou tabulkou dokázal pracovat.
- V administraci přidáme odkaz na editaci nové tabulky.
- Do SQL dotazu v prezentaci musíme přidat
JOIN.
Při využití Adminer Editoru nemusíme v administraci měnit vůbec nic, s NotORM jen změníme $tab['autor'] na $tab->autor['jmeno'].
Závěr
Podle mě se vyplatí udělat všechno proto, abychom si při vývoji usnadnili opravování chyb a obecně jakékoliv provádění změn. Generátory nám s tím mohou pomoci, ale v principu jsou taky špatné, protože se nevyhneme jejich spouštění. Cílem by mělo být využít návrh samotným programem – naklikání nového sloupce v Admineru se dá považovat za návrh databáze, který aplikace může automaticky využít.
Diskuse
Martin:
Toto som zacal pred mesiacom robit a je to bajecna vec.Mam v DB tabulku, ktora obsahuje profily klientov. A PHP automaticky generuje formulare na pridavanie/upravu profilov na zaklade stlpcov v tabulke.
Do poznamky tabulky v DB som uviedol Human-Readable nazov stlpca a nazov stlpca je v HTML pouzity ako atribut name.
V komentari v DB mam este vlozeny komentar, ktory obsahuje popis pola... Komenar je od nazvu oddeleny oddelovacom "---", nieco ako "Nazov---Datum zadavajte v tvare DD-MM-RRRR".
Jakub Vrána 
:
Doporučuji vyzkoušet Adminer Editor. Komentáře tam půjdou snadno doplnit pomocí přizpůsobení.
Jakub Vrána : Martin:
Na tu stranku Admineru by mozno bolo fajn napisat rozdiel medzi Adminer vs. Adminer Editor. Ci uz textom alebo nejaka tabulka s vlastnostami.Priznam sa, ze to je dovod, preco som doteraz nestiahol Adminer Editor - som lenivy prestudovat co to vlastne je :-) /idem to pozriet az teraz, ked som uz na to dostal tip/.
Jakub Vrána :
Myslím, že je to popsané docela dobře: http://www.adminer.org/editor/#features
Jakub Vrána : Josef Sábl:
Souhlasím, že jednovětné vysvětlení by bylo na místě. Byl jsem ve stejné situaci jako Martin. Chvilku mi v online demu trvalo, než jsem si všiml rozdílů a pochopil filosofii.Martin:
A uz len dodam, ze na zaklade typu stlpca sa automaticky zobrazuje dlzka INPUT pola, pripadne to vlozi TEXTAREA atd...mj41:
> Trochu mě ale mrzí, že se nákladnost změn bere jako fakt.
To ze jsme zamomneli na PSC v nejakem formulari muze byt priklad nakladne chyby v pripade, ze je produkt otestovan, vypalen na cd a jsou jiz vytisteny manualy :-). Samozrejme u webovych aplikaci je situace mnohdy jednodussi. Ale kdyz si vezmente kolik lidi dnes stale jeste pouziva IE6, tak u desktopovych aplikaci i takhle hloupa chyba muze mit obrovske dusledky. Navic velke webove aplikace dnes poskytuji API a chyby v jejich navrhu, se taky dosti spatne opravuji.
Martin Prokeš:
Já si naopak myslím, že tento přístup je cesta do pekel. Navíc článek je trochu demagogický. Snaží se čtenáři namluvit, že kdo používá Doctrine, nepoužívá Redmine. Jakub Vrána :
Cesta do pekel je snažit se minimalizovat cenu změn? Tedy bychom se naopak měli snažit o to, aby změny byly co nejpracnější nebo v ideálním případě úplně nemožné?
Zmíněnou „demagogii“ jsem upravil.
Jakub Vrána : 
PeTaX:
Ze zkušenosti bych řekl, že ceny změn mohou být natolik fatální, že mohou zahubit celý projekt.
Stalo se mi to. Naprosto mlhavá a neujasněná koncepce u klienta, neustálé změny v zadání a požadavcích na aplikaci. Výsledkem bylo obrovské množství práce navíc, neustálé přepisování hotových věcí a ve výsledku nespokojený klient s pocitem, že náklady přesáhly možné zisky a nic vlastně nefunguje.
Úvaha spíše psychosociální.
PeTaX: Honza:
Úplně mi to bereš z úst :-)
David Grudl:
S tím velmi úzce souvisí neustálé nářky vývojářů nad tím, jak jim jejich klient nemá jasnou představu a neustále mění zadání. Pláčete jen nad vlastní neschopností. Když to slyším, nejraději bych popřál jejich nebohému klientovi lepšího dodavatele.
Klient nemá jasné zadání, protože není odborník ve webdesignu. Zajímalo by mě, kolik webdesignérů se vyzná v oboru podnikání svého klienta tak dobře, že by dokázalo vytvořit přesné zadání, kdyby se karty obrátily.
Pokud klient zadání mění, znamená to, že ho projekt zajímá, baví, že s ním roste. Je pak větší pravděpodobnost, že vznikne něco skutečně užitečného. A především: bude poptávat další a další práci.
Pokud si vývojář tyto věci uvědomí, pak pochopí, že je to právě on, kdo musí přizpůsobit svůj styl práce realitě. Třeba maximálně zjednodušit přidání kolonky PSČ, které v původním zadání nebylo.
David Grudl: Tharos:
Já bych jen doplnil, změny v zadání nemusí být jen důsledkem neodbornosti klienta, ale mohou být také například důsledkem změn v jeho okolí v průběhu vývoje (konkurenčním, ekonomickém...). Zkrátka je na místě ona pověstná „spolupráce se zákazníkem před jednáním o smlouvě“. :)Olda Šálek:
Davide, souhlas. Stačilo by krátce napsat „Náš zákazník, náš pán“ a od toho se vše odvíjí. Zákazník je ten co nás platí, takže podle toho se tak chováme.
Peter Lištiak:
Súhlasím. Ako to však vyriešiť obchodne? Keď klient nemá jasnú predstavu a zadanie sa mení, prerába a pod. tak sa zvyšuje cena aplikácie. Žiaľ stalo sa mi, že zákaznik nevedel, čo chce, robili sa neustále zmeny a nakoniec bol nešťastný z výslednej ceny :-/ PeTaX:
Já bych s tím, Davide, lehce polemizoval. Použiji příměrů:
To platí, pokud klient požaduje aplikaci: „tady se vhodí pětikoruna a tady vypadne kafe“, domluvíte se na ceně a odevzdáš mu funkční automat.
A je naprosto v pořádku, jestliže se později klient rozhodne, že chce, aby to vracelo drobné, že kafe by mohlo být s mlékem, nebo bez, hořké i sladké. Pak má o projekt zájem a doplácí si nikoliv na změny, ale na upgrade.
Můj příspěvek mířil spíše do projektů, kdy klient neurčí, co se má do štěrbinky hodit (musíš odhadnout, že asi koruny), a co z bedny vypadne je definováno obdobně (odhadni, co asi může chtít). A když to je po pěti bezesných nocích napsané, zvoní telefon, že to vlastně nemělo vařit kafe, ale vyrábět suspenzory na míru. Tak to smažeš - protože nemá smysl přidávat pole pro rozměry - ani jednoduše, ani pracně.
Píšeš novou aplikaci (v lepším případě za nové peníze, v horším za tytéž podruhé).
Tam mířil můj podnět: klient, který netuší, že něco vymyslet a napsat to dá dost práce, že to není jen jednoduché copy/paste.
PeTaX: 
Filip Procházka:
Na tobě je taky tyhle informace z něj dostat, myslím že se tomu říká projektový manager. To je člověk co rozumí programování a rozumí řeči normálních lidí a tlumočí požadavky pro programátory. Což samozřejmě musí freelanceři zvládat, jinak by vymřeli hlady :)
Filip Procházka: Tharos:
Ta Tvá nadsázka je ale z mého pohledu nepřiměřená. Takhle to až zní, že se Ti běžně stává, že po Tobě chtějí klienti web, ale nakonec zjistí, že vlastně chtěli spíš nový nábytek do kanceláře... Management se domníval, že nový online rezervační systém by mohl zvednout prodeje, ale po jeho naimplementování zjistili, že by se jim spíše hodilo zajistit zaměstnancům na pobočkách firemní uniformy... :)Neříkej mi, že Tví klienti tak diametrálně netuší, co vlastně chtějí (káva s mlékem versus suspenzory na míru). A na následné kvalitě zadání má podstatný podíl i projekt manager (nebo v horším případě vývojář...). Ale no offense.
PeTaX:
Též no offense. Ale často jsem na tuto situaci narazil. Doslova to, co píšeš: zadali si rezervační systém, ale ve skutečnosti chtěli nový nábytek. Chtěli nějaký systém, který jim zvýší zisky - to je naprosto legitimní - ale nevěděli jaký systém chtějí.
Jako lonesome autor nemáš v zádech projektové manažery, ani freelancery.
Jen se snažíš, dřeš se jako landsknecht, snažíš se zajistit si záda a výdělek a ve výsledku sklidíš nespokojenost.
PeTaX: Tharos:
Jestliže se Ti to ale děje opravdu často, asi existuje nějaká příčina. Střílím naslepo, ale napadá mě, jestli třeba nejsi k zadavatelům příliš loajální a nekývneš jim na projekty (z čistě tržních důvoů), u kterých třeba sám cítíš, že pro zadavatele nejsou „tím pravým ořechovým“?Řeknu příklad: kdyby po mně chtěl někdo v dnešní době naprogramovat další slevový agregátor, nešel bych do toho (samozřejmě pokud by odměna nebyla v řádech statisíců), protože to v dnešní době nepovažuji za dobrý podnikatelský záměr.
PeTaX:
Máš naprostou pravdu. Jsem příliš slušný, taktní, ohleduplný, loajální. Ale vyrostl jsem v době, kdy to patřilo k dobrému vychování. Jsem docela dost starý chlap.
PeTaX: Josef Sábl:
Být slušný blbec ve smyslu držet hubu a krok je bohužel jedna z hodnot staré školy, která by své místo dnes už mít neměla. A loajalita nemusí jít vyloženě proti tomuhle principu. Řekl bych, že může naopak znamenat, že klientovi jeho "nesmyslný" nápad vyvrátíš, i když z toho nebudeš mít prospěch a třeba o zakázku přijdeš, protože klient zjistí, že žádný web nepotřebuje. Pokud klient stojí za to, tak to ocení.Taky je pravda, že můžou existovat špatní, hloupí a nevděční klienti. To je asi freelancerská noční můra a jejich odhalování včas by měla být hlavní schopností freelancera.
PS: Nejsem freelancer, spíš ten projektovej manažer
Josef Sábl:
Ono tohle chce schopnost určité abstrakce. Vždyť je jedno, jestli se do škvírky hází koruny nebo strká kreditka. Nechcete koruny? Ok, musíme udělat modul na kreditky a ten bude stát XXX, modul na mince za YYY schováme do šuplíku, třeba si to rozmyslíte, a nebo nechcete zapojit oba? Pokud ale automat není z modulů a je to monolitní krabice, kde je vše prodrátované se vším, je problém a je třeba začít znovu. Řekl bych, že o tomto je ten článek.vojtech:
Davide, tohle je všechno moc fajn, pokud u projektu není předem daná pevná cena a termín dodání.Když mi bude klient platit za odvedenou práci a ne za předaný projekt, budu si s každou jeho vlastností hrát klidně půl roku.
v6ak:
Ono je taky špatné to brát jako buď a nebo. (Článek sice s tím není v rozporu, ale...) Budu-li chtít snížit náklady tím, že změny odhalíme co nejdříve, budu nějakou chvíli úspěšný, ale od určitého bodu se to přestane vyplácet.Podobně, pokud budu jen chtít snižovat cenu změny, mohu být do určité doby úspěšný. Ale od nějakého bodu se to opět přestane vyplácet.
Největší úspěch asi bude přinesen kombinací obojího.
Josef Sábl:
Mně se osvědčilo dělat věci systémově správně. Pokud je systém dobře navržený, vždy snese jakoukoli změnu.Je ale potřeba stále myslet na YAGNI princip. Hodně se setkávám s tím, že se programátoři snaží systém už předem připravovat na všechny možné scénáře, motají se na místě a výsledek není žádný. Jsou z toho frustrovaní a pod časovým tlakem začnou aplikaci bastlit nesystémově. Když pak nějaký z plánovaných scénářů nepřijde nebo nedejbože přijde jiný, se kterým programátor nepočítal, nadávají, jaký je ten klient debil a co si to vymýšlí.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 