Jak se postavit k nekvalitnímu projektu?

[Ondrej Nemecek]

První otázka zákazníka bude: Kolik by to stálo a co se refaktorací rozbije? Co tím získám?

Z toho vyplývá, jak se postavit k projektu: Musítě spočítat, kolik vyjde údržba a implementace nových funkčností za stávajícího stavu a kolik po refaktoraci. Náklady musí vyjít stejně nebo ve prospěch refaktorace. Zhodnoťte si to sám a pak prezentujte zákazníkovi. Náklady musí vyjít ve prospěch refaktorace, jinak do toho zákazník nebude chtít. Dost zásadní taky je, zda se dá refaktorovat postupně nebo zda se to musí udělat (a zaplatit) naráz. A musíte zákazníka přesvědčit, že do provozu se to nasadí hladce a bez chyb. Pokud máte podobný případ už za sebou, dokladujte to na příkladech. Uvažujte taky, jaký provoz zvládne aplikace obsloužit. Pokud bude stávající implementaci brzo docházet dech, bude výkonové zlepšení žádoucí a bude to podstatný argument pro uvolnění financí.

Jinak každý má jinou minimální úroveň projektu, do kterého by šel. Že něco vrací jen http 200 nemusí být problém, podstatnější je, jestli to API chyby ošetřuje a zda ošetřuje všechny chybové stavy. Minimálně při výpadku serveru se tam mohou objevit jiné kódy a ty musí být na klientovi ošetřené. Při refaktoraci bych využil nějaký hotový protokol, vzdálené volání procedur nebo něco podobného, pokud to projekt umožňuje.

[Reklama]

[karel]

Tak přepis na rest je defacto nový projekt...

Ne tak docela. Téměř vše, co bylo v Javascriptu, jsem mohl ponechat beze změny. Pouze jsem kódy, které byly v hlavičce HTML, společně s tím HTML vystrnadil do výstupních šablon, které tam původně vůbec nebyly. To byl také významný krok DRY - HTML už do PHP nedávám vůbec.

je zajímavé jak se z jazyka vytvořeného pro generování html stalo něco co by s html nemělo přijít do styku, pokrok nezastavíš   

[Kit]

To byl také významný krok DRY - HTML už do PHP nedávám vůbec.

je zajímavé jak se z jazyka vytvořeného pro generování html stalo něco co by s html nemělo přijít do styku, pokrok nezastavíš   

Sám jsem se nad tou vlastní změnou také podivoval, ale když vidím benefity šablon (např. automaticky validní výstup HTML, využití dědičnosti a polymorfismu, dependency injection, jazykové překlady, řízení šablony tokem dat,...) tak se mi už s HTML do PHP vracet nechce.

[sdasdasdasd]

První otázka zákazníka bude: Kolik by to stálo a co se refaktorací rozbije? Co tím získám?

Dakujem za velmi kvalitny prispevok.

Problemom je, ze momentalne nie som schopny toto odhadnut pretoze to absolutne nema testy takze ani neviem povedat, ci sa vobec nieco rozbilo a ako velmi. Ak by to malo nejaku test suitu, tak kazdu zmenu co spravim prezeniem testami a uvidim ako na tom som. Lenze ja to nedokazem zrefaktorovat bez testov tak, aby som si bol isty, ze ten vysledok po refaktorizacii je ten isty ako pred nou, kedze to nemam s cim porovnat.

[sdasdasdasd]

Záleží na tom, jak se vývojář k testům staví. Pokud jako k povinnosti, kterou mu nikdo nezaplatí, tak se bude koukat tomu vyhnout. Pokud se však k němu budeš stavět jako k prototypu, který od počátku píšeš jako dvojici (test, kód), stane se z toho zábava.

Presne tak.

[Reklama]

[Nemo7]

Názor líného programátora - vykašlat se zbytečně opravovat původní funkční kód, používat co se používat dá a udělat si pro přístup k původnímu kódu nějakou dobrou fasádu (vzor facade). Svět není ideální, kód není ideální a do toho co funguje se má vrtat co nejméně... Jsou z toho pak úplně zbytečné chyby, opravu a zbytečný vývoj stejně nechce pak nikdo platit. Vždy jde program navrhnout lépe, protože existují celkem protichůdná hlediska. Rychlost vývoje aplikace, rychlost běhu aplikace, udržovatelnost aplikace a rozšiřitelnost aplikace + množství chyb co zákazník po nasazení snese.   

[karel]

To byl také významný krok DRY - HTML už do PHP nedávám vůbec.

je zajímavé jak se z jazyka vytvořeného pro generování html stalo něco co by s html nemělo přijít do styku, pokrok nezastavíš   

Sám jsem se nad tou vlastní změnou také podivoval, ale když vidím benefity šablon (např. automaticky validní výstup HTML, využití dědičnosti a polymorfismu, dependency injection, jazykové překlady, řízení šablony tokem dat,...) tak se mi už s HTML do PHP vracet nechce.

to me take ne, ale pro jednudochou vec se to stale hodi, pro slozitejsi mi prijde pouzivani php uz trosku out, nehlede na to ze vetsina php freamworku je celkem nenazrana.

[sdasdasdasd]

Názor líného programátora - vykašlat se zbytečně opravovat původní funkční kód, používat co se používat dá a udělat si pro přístup k původnímu kódu nějakou dobrou fasádu (vzor facade). Svět není ideální, kód není ideální a do toho co funguje se má vrtat co nejméně... Jsou z toho pak úplně zbytečné chyby, opravu a zbytečný vývoj stejně nechce pak nikdo platit. Vždy jde program navrhnout lépe, protože existují celkem protichůdná hlediska. Rychlost vývoje aplikace, rychlost běhu aplikace, udržovatelnost aplikace a rozšiřitelnost aplikace + množství chyb co zákazník po nasazení snese. 

To je pravda, ale aj tak to nemeni nic na fakte ze to takto byt nema a je prinajmensom fakt krute ze niekto projekt takejto kvality prehlasuje za produkcny ... je to sila.

[Nemo7]

To je pravda, ale aj tak to nemeni nic na fakte ze to takto byt nema a je prinajmensom fakt krute ze niekto projekt takejto kvality prehlasuje za produkcny ... je to sila.

Ekonomika, co chcete? Na programování nepotřebujete nutně žádné vzdělání, takže klidně programují lidé co o programování nemají pořádně páru (stlučou tak nějaký špagetový skript nebo lepí knihovny k sobě). A hrdě se prohlašují za vývojáře, navíc můžou být (a také jsou) levnější než studovaný IT. A pokud jejich program nějak funguje, tak se nikdo nezajímá co je uvnitř. A vy budete za blbce, protože ve snaze cizí kód opravit uděláte nějakou chybu. Stačí totiž zadání trochu špatně pochopit, pochopit špatně nějakou mezní podmínku a všechny testy jsou vám k ničemu.

[Kit]

Sám jsem se nad tou vlastní změnou také podivoval, ale když vidím benefity šablon (např. automaticky validní výstup HTML, využití dědičnosti a polymorfismu, dependency injection, jazykové překlady, řízení šablony tokem dat,...) tak se mi už s HTML do PHP vracet nechce.

to me take ne, ale pro jednudochou vec se to stale hodi, pro slozitejsi mi prijde pouzivani php uz trosku out, nehlede na to ze vetsina php freamworku je celkem nenazrana.

Nepoužívám žádné frameworky - tím jsem přece pověstný. Ten šablonovací systém byl napsán v C/C++, je úsporný a velmi rychlý - doba generování HTML je běžně pod 1 ms, což považuji za vyhovující.

[Trident]

Přijde mi ze se tu setkávají dva typy lidí. Čerství absolventi vs lidi z praxe vs ekonomové. Je treba se smířit s tím ze na světě je spousta odpadu který nějak funguje. A to jak v sw tak třeba I ve fyzických věcech jako auto. Plastova kola na kritických částech aut, příliš složité systémy řízení. Stejně tak spackane webové aplikace jejichž laditelnost je úplně někde jinde než vývoj hw,os kernelu a driveru. Takový už je svět. Přijde mi ten člověk si neví rady se základním životním dilema. Jako doktor jež vidí umírat nevinné dítě kterému nemůže pomocí. Je to tvrdé je to život. Ideály vs realita. Pokud se to nezvládnes dělej soukromý projekt nebo dělej něco jiného. Hanba to není. Taky jsem si tím prosel.

[j]

Jenže měnící a vyvíjející se zadání je realita dlouhodobě funkčního projektu. Je na vývojářích, aby s kódem mohli/uměli cvičit a při každé změně jej refaktorovat k lepšímu. Při implementaci změny nejdříve pár (občas i desítky) commitů refaktoringu a až pak, až má kód správné názvy, rozpadlý do krátkých metod s jasným významem a jakžtakž se mi líbí, mohu změnu zaimplementovat. Často se vlastní změna pak ukáže jako drobnost. A příště je to samé, požadavky se mění, tomu musí odpovídat i refaktoring. Samozřejmě to vyžaduje IDE, které refaktoring umí dobře (a i na něm je vždy co zlepšovat).

Nevěřím, že přepisy funkčního používaného otestovaného kódu od nuly něčemu pomůžou. Nakonec to dopadne úplně stejně.

Jasne, zakos ti rekne, ze chce k tomu poli pricist jednicku a ty mu reknes, ze to bude 30 hodin ... tak ti rekne ze ses zblaznil a najme nekoho jinyho, kdo si zato rekne tu hodku prace.

Názor líného programátora - vykašlat se zbytečně opravovat původní funkční kód, používat co se používat dá a udělat si pro přístup k původnímu kódu nějakou dobrou fasádu (vzor facade). Svět není ideální, kód není ideální a do toho co funguje se má vrtat co nejméně... Jsou z toho pak úplně zbytečné chyby, opravu a zbytečný vývoj stejně nechce pak nikdo platit. Vždy jde program navrhnout lépe, protože existují celkem protichůdná hlediska. Rychlost vývoje aplikace, rychlost běhu aplikace, udržovatelnost aplikace a rozšiřitelnost aplikace + množství chyb co zákazník po nasazení snese. 

Tak, naprosto nehorsi co se ti muze stat, ze presvedcis zakose ze to napises znova, prineses to, a pak se to dalsi rok ladi, protoze prakticky nic nefunguje. Stravis na tom nasobky casu, zakaznik nadava, ze to co predtim fungovalo nefunguje a ty delas desikty/stovky hodin gratis.

Nakonec z toho vypadne podobna zplacanina jako predtim, protoze te prestane bavit to neustale prepisovat. Videl sem na vlastni oci, jak podobnej zoufalec nabouchal do kodu asi 20 totoznych ifu, protoze proste nechtel resit, co kde a jak prepsat.

[Kit]

Tak, naprosto nehorsi co se ti muze stat, ze presvedcis zakose ze to napises znova, prineses to, a pak se to dalsi rok ladi, protoze prakticky nic nefunguje. Stravis na tom nasobky casu, zakaznik nadava, ze to co predtim fungovalo nefunguje a ty delas desikty/stovky hodin gratis.

Opačnou situací je, když původní aplikace téměř nefunguje a testy neviděla ani z dálky. Ty to napíšeš s poctivými testy (netrvá to déle než bez nich) a funguje to od prvního nasazení. Když pak zákazník chce novou funkcionalitu, přidáš jen další modul/třídu. OCP.

Nakonec z toho vypadne podobna zplacanina jako predtim, protoze te prestane bavit to neustale prepisovat. Videl sem na vlastni oci, jak podobnej zoufalec nabouchal do kodu asi 20 totoznych ifu, protoze proste nechtel resit, co kde a jak prepsat.

Držím se pravidla, že každá podmínka se má testovat pouze 1×. Prostě DRY. Před zápisem každé podmínky se sám sebe 2× ptám, zda je tam vůbec k něčemu dobrá a často ji tam vůbec nedám. Tell, don't ask.

Volba správné architektury aplikace patří mezi strategická rozhodnutí. Pokud ji někdo na začátku zvolí chybně, pozdější předělávání je velmi náročné i nákladné a zpravidla to znamená to vše napsat od nuly.

[Nemo7]

Opačnou situací je, když původní aplikace téměř nefunguje a testy neviděla ani z dálky. Ty to napíšeš s poctivými testy (netrvá to déle než bez nich) a funguje to od prvního nasazení. Když pak zákazník chce novou funkcionalitu, přidáš jen další modul/třídu. OCP.

Držím se pravidla, že každá podmínka se má testovat pouze 1×. Prostě DRY. Před zápisem každé podmínky se sám sebe 2× ptám, zda je tam vůbec k něčemu dobrá a často ji tam vůbec nedám. Tell, don't ask.

Volba správné architektury aplikace patří mezi strategická rozhodnutí. Pokud ji někdo na začátku zvolí chybně, pozdější předělávání je velmi náročné i nákladné a zpravidla to znamená to vše napsat od nuly.

Hezká teorie. A jak se říká "Šedá je teorie a zelený je strom života" : 
1) Aplikace má svůj vývoj v čase. Z původní naprosto primitivní aplikace s pár formuláři (kde nikdo nepočítal s nějaký rozšířením) vznikla postupem času solidně rozrostlá aplikace.
2) Když pak zákazník chce novou funkcionalitu, přidáš jen další modul/třídu. Perfektní. Tak bude aplikace napsána nejobecnější. Polymorfismus se přece perfektně debuguje, čím abstraktnější návrh a větší poletování po třídách, tím lepší. No a aplikace se tímto směrem vůbec nevyvíjí a nerozšiřuje. Zákazník bude chtít rozšířit v aplikaci funkčnost něčeho naprosto jiného, samozřejmě co nejlevněji a v oblasti programu, která s rozšířením naprosto vůbec nepočítala.
3) Testy jsou sice pěkná věc, ale já dělám odhadem 95% svých chyb při programování GUI. A na to se testy píšou pěkně blbě.
4) Volba správné architektury aplikace patří mezi strategická rozhodnutí. Rozšíření bodu 1. NIKDY nemáte všechny informace, kam aplikace v čase doputuje, takže původně správné rozhodnutí se může ukázat časem jako naprosto chybné.
5) A počkejte si, co život a zákazník dokáže přinést za podmínky ke zpracování v kódu. 

[pepa]

A existuje kvalitní projekt ?