Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: sdasdasdasd 03. 09. 2015, 22:59:00
-
Zdravim,
mam taku malu dilemu.
Niekto dal moj kontakt niekomu druhemu s tym ze ma odporuca lebo som celkom kvalitny developer. Ten koncovy clovek sa mi ozval, predstavil mi ten projekt, dal mi pristup k repozitarom a mal som par dni na to aby som sa popozeral do coho by som isiel.
Ja som celkom prekvapeny ale je to celkom sprasene. Jedna sa o serverovu cast, nejake REST api + Spring + omacka okolo.
Mna z toho kodu proste bolia oci. Su to spagety, absolutne to nema vobec ziadne testy, unit ani integracne, je to malo robustne, malo modularizovane ... a ten REST je dopraseny fakt uctihodne. (vsetky queries vracaju rovnaky http status kod) no ja neviem. Momentalne to vyzera tak ze by bolo jednoduchsie to cele prepisat odzova ako tam dopisovat endpointy "po starom". Ten projekt dost velky technical debt a neviem ako sa mam k tomu postavit.
Prva moznost je ze zatnem zuby, odkodim si svoje a rozlucim sa s tym projektom.
Druha moznost je ze sa pokusim vysvetlit tomu cloveku tie slabiny a povedat mu na rovinu ze to nevidim celkom ruzovo, viac menej mu zdelim to co vam a uvidim co bude.
Tretia ze mu navrhnem aby mi to nechal cele prepisat "tak ako sa to ma".
S tou tretou moznostou by to bolo najlepsie ale na to nebude chciet prisvedcit. Lenze mne sa uplne hnusi robit na projekte ktory je od zakladu napraseny a nic sa s tym uz neda robit ...
-
A co chces slyset? Otazka ma styl: ta tlusta blbka se mi sice vubec nelibi, ale sem nadrzenej jak prase...
-
Dulezitymi faktory zde budou: kolik za to dostanes a za co, jestli aktualne tuto odmenu potrebujes, jestli kdyz to odmitnes, budes mit neco jineho...atp. A sam si pak odpovez, jestli ti to stoji zato. Domnivam se, ze jsi jediny clovek na planete, ktery to dokaze odpovedne rozlousknout.
-
quote author=sdasdasdasd link=topic=11799.msg141140#msg141140 date=1441313940]
Tretia ze mu navrhnem aby mi to nechal cele prepisat "tak ako sa to ma".
[/quote]
To je prosté: Navrhni mu třetí možnost se slovy: "ber nebo nechej být". Posledně jsem to tak udělal a vydělali jsme na tom oba, protože na to přistoupil a od té doby aplikace šlape tak jak má.
-
Otazka je jestli to funguje, protoze to koncoveho uzivatele zajima. Na tom jak moc je to zprasene az zas tak moc nesejde, pokud aplikace plni svuj ucel. Mnohdy je to tak, ze ta zprasenost ma svou historii a obsahuje spoustu funkcionalit, ktere byly zadany a dodavany postupne a mnohdy protichudne k pozadavkum z minulosti, placeny nepravidelne apod. Neznam detaily. Pokud chces byt siritelem evangelia cisteho kodu (dle tveho nazoru) je to tvoje volba, otazka je zdali za to dostanes zaplaceno.
-
Otazka je jestli to funguje, protoze to koncoveho uzivatele zajima. Na tom jak moc je to zprasene az zas tak moc nesejde, pokud aplikace plni svuj ucel. Mnohdy je to tak, ze ta zprasenost ma svou historii a obsahuje spoustu funkcionalit, ktere byly zadany a dodavany postupne a mnohdy protichudne k pozadavkum z minulosti, placeny nepravidelne apod. Neznam detaily. Pokud chces byt siritelem evangelia cisteho kodu (dle tveho nazoru) je to tvoje volba, otazka je zdali za to dostanes zaplaceno.
chapem, diky za nazor
-
Nejsem si vůbec jist, že přepsání od nuly vyjde levněji než to při implementaci nových zadání postupně zrefaktorovat a vyčistit. Obzvláště REST, který se celkem snadno testuje.
-
Nejsem si vůbec jist, že přepsání od nuly vyjde levněji než to při implementaci nových zadání postupně zrefaktorovat a vyčistit. Obzvláště REST, který se celkem snadno testuje.
Nevyjde. A to je dôvod, kôli ktorému sa to postupom času tak zhovadilo.
-
spis myslim, ze ten duvod popsala krysa. nemusi jit o neumetelstvi vyvojaru - sam si po sobe obcas rikam "to je prasecina", ale pak kouknu do dokumentace a do gitu a vidim jak to vznikalo.
1) pozadavek na jasnou funkci x = y.
2) v prubehu vyvoje pridana vyjimka, ze 1 se nerovna 1. proc? proste proto.
3) mesic po dokonceni vyvoje zadan pozadavek na detekci jestli je cislo binarni nebo desitkove. protoze pak uz skutecne 10 nemusi byt 10.
4) zadost o pridani vyjimky, ze 10 je vzdy 10 bez ohledu na soustavu.
5) pozadavek - pri zadani 100 vzdy vyhod chybu, ze neni mozne zadat takove cislo
6) oprava predchoziho pozadavku - nejdrive se zeptej jestli 100 je sto nebo jedna-nula-nula.
...
A uz to leti. Treba tvurci ucetnich SW maji muj naprosty obdiv - podivejte se jak se ty zakony meni.
-
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ě.
-
ja pouzivam rest api taky jen s kodem 200
a rozlisuju jesli se mi vraci jako klic result nebo error a podle toho kod reaguje
je to dano jquery kdyz pouzivas $.get nebo $.post tak ti errorovy status kody vse domrvi musel bys pouzivat jen $.ajax a psat dva callbacky takhle se to da spachat v jednom a kod se zbytecne nestepi.
navic pokud jedes na nejakem verejnem hostingu tak brzo zjisitis ze ti neprojdou jine metody nez get a post
a nazaver nelze rict ze kazdy prohlizec pokud vratis error kod ti to posle dal do javascriptu, byli taci co to proste zahodili protoze error a mozna jeste jsou.
navic co je prasecina pro tebe nemusi byt prasecina pro jineho a obracene
k testum, vetsina mensich projektu se robi proste bez nich, protoze je to neco za co ti nikdo neda ani korunu, protoze odpoved je, ale my nehodlame uz nic predelavat proste to napiste mi si to ozkousime
-
Nejsem si vůbec jist, že přepsání od nuly vyjde levněji než to při implementaci nových zadání postupně zrefaktorovat a vyčistit. Obzvláště REST, který se celkem snadno testuje.
V mém případě tam ten REST původně vůbec nebyl. Byla to jedna dlouhá nefunkční špageta a ten REST to zpřehlednil. Stavěl jsem ho od nuly - nyní funguje tak jak má, i když má pouze třetinovou délku proti původní verzi. Zato běží cca 100× rychleji.
-
Tak přepis na rest je defacto nový projekt...
-
ja pouzivam rest api taky jen s kodem 200
a rozlisuju jesli se mi vraci jako klic result nebo error a podle toho kod reaguje.
I když stránka neexistuje? Tak na co ty HTTP kódy máme?
navic pokud jedes na nejakem verejnem hostingu tak brzo zjisitis ze ti neprojdou jine metody nez get a post
Ale jedou. Dokonce často jedou i vlastní metody - které si vymyslíš a přitom nikde nejsou zdokumentovány. Obvyklou podmínkou je, že musí být psány verzálkami a nesmí obsahovat diakritiku. Samotný protokol HTTP to umožňuje. Formuláře HTML však umí pouze GET a POST.
a nazaver nelze rict ze kazdy prohlizec pokud vratis error kod ti to posle dal do javascriptu, byli taci co to proste zahodili protoze error a mozna jeste jsou.
Někteří vývojáři zahazují errory a staví vlastní chybové kanály. Prostě si přidělávají zbytečnou práci.
k testum, vetsina mensich projektu se robi proste bez nich, protoze je to neco za co ti nikdo neda ani korunu, protoze odpoved je, ale my nehodlame uz nic predelavat proste to napiste mi si to ozkousime
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.
-
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.
-
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.
-
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íš ;D
-
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íš ;D
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.
-
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.
-
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.
-
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 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íš ;D
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.
-
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.
-
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.
-
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í.
-
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.
-
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.
-
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.
-
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. ;)
-
A existuje kvalitní projekt ?
-
A existuje kvalitní projekt ?
Ne, protože je vždy psán nekvalitním člověkem. ;) Navíc pojem "kvalita" je diskutabilní. Má být SW co nejšetrnější k přírodě (=nejrychlejší a nejšetrnější ke zdrojům počítače)? Pak má spotřebovávat co nejméně elektřiny a nejlepší jazyk je assembler. A teď v assembleru udělejte kvalitní objektový návrh! ;) Kvalitní vzhledem k rozšiřování aplikace, kvalitní podle počtu chyb (i špagetový kód může být velmi kvalitně za tu dobu otestovaný), kvalitní podle rychlosti vývoje (když my ten program potřebujeme už příští týden, bez něj nám zákazník uteče!)... Kvalitu si každý představuje jinak.
-
Přepis aplikace má tu výhodu, že máte k dispozici údaje, které nebyly původně k dispozici. Nevýhodu máte v tom, že musíte znova realizovat zadání zpravidla za několik let, což je obvykle víc práce, než se v evangelizačním nadšení zprvu zdá. A stále tam zůstává problém skrých předpokladů - use-casů, které se sice používají, ale zákazník si to vůbec neuvědomuje.
Typické reakce jsou: Ta nová verze je hrozná, nejde tam udělat XY a zrovna tohle v původní verzi fungovalo skvěle. Cože, vy jste něvěděl, že to takto používáme?? No ale za to mi nemůžeme, přece jsme nechtěli, abyste nějakou funkčnost rušil, mysleli jsme že to bude fungovat jako dřív a že si to jen nějak uvnitř uzpůsobíte aby se v tom vám lépe programovalo a aby to bylo rychlejší...
K principu DRY: Někdy je lepší se opakovat a zachovat ortogonalitu, než se za každou cenu neopakovat a vytvořit přebujelou hiearchii tříd nebo do sebe zaklesnutých pomocných modulů, které rádoby dělají tu věc, které se nemá opakovat, ale jsou špatně navržené. Takže než vytvořit nezvládnutou abstrakci, je lepší to psát jednoduše. V tom dost pomůže prototypování - otestuje se, zda zvolená architektura zachycuje reálné potřeby.
Kvalitu si představuje programátor typicky jako elegantní návrh (a možná i jako odolnost vůči chybám), uživatel požaduje hlavně srozumitelné gui no a manager to chce zítra :-)
-
K principu DRY: Někdy je lepší se opakovat a zachovat ortogonalitu, než se za každou cenu neopakovat a vytvořit přebujelou hiearchii tříd nebo do sebe zaklesnutých pomocných modulů, které rádoby dělají tu věc, které se nemá opakovat, ale jsou špatně navržené. Takže než vytvořit nezvládnutou abstrakci, je lepší to psát jednoduše.
Aneb každé správné a jednoduché pravidlo má své výjimky. Úplně stejně jako v reálném jazyku. :)
-
http://www.joelonsoftware.com/articles/fog0000000069.html
-
Jojo, nové začátky jsou prostě osvobozující - člověk odhazuje tíživou karmu projektu a jde vstříc novým světlým zítřkům. Nikde ale není zaručeno, že neskončí stajně jako předtím. Nicméně úkolem všech patternů je zařídit, aby ta karma zůstala pokud možno čistá a aby bylo co nejmenší puzení k přepisu kódu...
-
Přepis aplikace má tu výhodu, že máte k dispozici údaje, které nebyly původně k dispozici. Nevýhodu máte v tom, že musíte znova realizovat zadání zpravidla za několik let, což je obvykle víc práce, než se v evangelizačním nadšení zprvu zdá. A stále tam zůstává problém skrých předpokladů - use-casů, které se sice používají, ale zákazník si to vůbec neuvědomuje.
Typické reakce jsou: Ta nová verze je hrozná, nejde tam udělat XY a zrovna tohle v původní verzi fungovalo skvěle. Cože, vy jste něvěděl, že to takto používáme?? No ale za to mi nemůžeme, přece jsme nechtěli, abyste nějakou funkčnost rušil, mysleli jsme že to bude fungovat jako dřív a že si to jen nějak uvnitř uzpůsobíte aby se v tom vám lépe programovalo a aby to bylo rychlejší...
K principu DRY: Někdy je lepší se opakovat a zachovat ortogonalitu, než se za každou cenu neopakovat a vytvořit přebujelou hiearchii tříd nebo do sebe zaklesnutých pomocných modulů, které rádoby dělají tu věc, které se nemá opakovat, ale jsou špatně navržené. Takže než vytvořit nezvládnutou abstrakci, je lepší to psát jednoduše. V tom dost pomůže prototypování - otestuje se, zda zvolená architektura zachycuje reálné potřeby.
Kvalitu si představuje programátor typicky jako elegantní návrh (a možná i jako odolnost vůči chybám), uživatel požaduje hlavně srozumitelné gui no a manager to chce zítra :-)
Predevsim u toho prepisu nejsou k dizpozici zadani, podle kterych to puvodne vznikalo, a nikdo si uz nepamatuje, co vsechno se vlastne chtelo aby to umelo. Osobne sem se ucastnil, a osobne sem prepisovatele predem varoval, ze nikdo nevi, co vsechno ta vec vlastne dela. Vysledek byl v souladu s ocekavanim (tedy, mym ocekavanim, managori vazne verili, ze bude fungovat) - misto v unoru se to zprovoznilo v lednu.
-
Predevsim u toho prepisu nejsou k dizpozici zadani, podle kterych to puvodne vznikalo, a nikdo si uz nepamatuje, co vsechno se vlastne chtelo aby to umelo. Osobne sem se ucastnil, a osobne sem prepisovatele predem varoval, ze nikdo nevi, co vsechno ta vec vlastne dela. Vysledek byl v souladu s ocekavanim (tedy, mym ocekavanim, managori vazne verili, ze bude fungovat) - misto v unoru se to zprovoznilo v lednu.
Jenže cílem nemusí být realizovat to samé - cílem může být realizovat jen to, co se používá a realizovat to lépe.
-
NIKDY nenabízej, že delší dobu v reálném prostředí fungující projekt přepíšeš from scratch. To se jdi raději oběsit rovnou, dokud na to máš ještě aspoň dost sil.
Pokud si tě někdo najme výslovně na tento úkol, protože je sám pevně přesvědčen, že je to dobrý nápad, můžeš o tom uvažovat, ale dej si pozor na smlouvu a nech si zaplatit předem s no refunds.
-
NIKDY nenabízej, že delší dobu v reálném prostředí fungující projekt přepíšeš from scratch. To se jdi raději oběsit rovnou, dokud na to máš ještě aspoň dost sil.
Pokud si tě někdo najme výslovně na tento úkol, protože je sám pevně přesvědčen, že je to dobrý nápad, můžeš o tom uvažovat, ale dej si pozor na smlouvu a nech si zaplatit předem s no refunds.
Jo, spravil som to tak. Nejdem to prepisovat ale vypisal som slabiny ktore to ma a ponukol som riesenie ako by sa to mohlo zlepsit. O kompletnom prepisani nepadlo z mojej strany nic.
Myslim si, ze je to zbytocne prepisovat to uplne odznova. Ako tu vela krat zaznelo, nema to zmysel a nestoji to za to. Uz to je raz tak ...