it-swarm-eu.dev

Jak se vypořádáte s ošklivým kódem, který jste napsali?

Váš klient tedy žádá, abyste napsali nějaký kód, takže ano. Poté na vás podle očekávání změní specifikace a vy jeho nové funkce pečlivě implementujete jako dobrý chlapeček. Kromě ... nových funkcí je v konfliktu se starými funkcemi, takže nyní je váš kód nepořádek. Ty opravd se chceš vrátit a opravit to, ale on stále žádá nové věci a pokaždé, když něco dokončíš, tak to zase skončí.

Co děláš? Přestaňte být OCD maniakem a prostě přijměte, že váš kód bude navíjet nepořádek bez ohledu na to, co děláte, a prostě se držet funkcí na této monstróznosti? Uložit čištění pro verzi 2?

89
mpen

Získejte jinou práci a nechte ji řešit ostatní. Muahahahhahahaa.

.....

Dělám si legraci. :)

Ale se vší vážností: padding odhad je váš přítel. Obecně dělám slušný realistický odhad, pak ho zdvojnásobím. Může to znít přehnaně a někdy je to, ale je lepší trochu přeceňovat a někdy dokonce vypadat pomaleji - než zanechat špatné dojmy otočením kódu buggy a vždy vyfukováním odhadů. A samozřejmě vám vznikne technický dluh tím, že necháte hackerskou síť hacknout.

Další (související) tip: Vždy odhadněte zdánlivě malé, žádné úkoly týkající se inteligence do bloku slušné velikosti. Řekněme například - položka, o které jste si téměř jisti, bude pouze jednoduchá změna jednoho řádku a 30 sekund - dejte jí 1 hodinu (nebo snad cokoli nejnižšího časového bloku je na vašem časovém rozvrhu nebo v systému CR, např. 15 minut/0,25 hodiny) . A dejte půl dne nebo 1 den bloky pro mírně větší, ale stále relativně triviální předměty.

Důvod je hlavně psychologický: Zjistil jsem, že pokud si zvyknete rychle hackovat malé změny, práce se cítí spěchaná a nikdy neskončíte sedět, inventarizovat a refaktorizovat věci, které je třeba refactored. Prakticky také: drobné, ale netriviální změny občas vyhodí do vzduchu a nechcete mít neustále pocit, že jste za plánem a vyhazujete oheň. Je to součást toho, proč se kódové základny časem hackou.

Nakonec si vždy pamatujte, že lidé nemusí vědět, že vaše odhady poněkud vycpáváte. Dokud jste kompetentní vývojář a vykořisťujete práci slušným tempem, nebude toto polstrování patrné. tj. neříkej PHB „Můj původní odhad je, že to bude trvat dvě hodiny, ale dej mi půl dne“. Jen mu řekni: „Myslím, že to bude trvat asi půl dne.“ a nechat to tam.

41
Bobby Tables

Záměrně přeceňujte čas potřebný pro další funkce. Použijte tento extra čas na vyčištění.

Nikdy nebudete schopni odůvodnit údržbu a klient ji potřebuje bez ohledu na to, takže jim dejte hořký lék (mírně zvýšené náklady na další funkce), aby se mohli zlepšit.

66
Frank Shearar

Pokuste se provést správný redesign při integraci nových funkcí. Neexistuje později. Bez redesignu neustále přidáváte tření pro další změny a nové funkce.

V určitém okamžiku se dostanete k broušení téměř zastavení, kde se zdá, že všechno trvá věky. Většina společností pravděpodobně v tuto chvíli, verze 2, prochází velkým přepisem. Má docela špatnou ekonomiku a je to dobrý okamžik pro zákazníka, aby vyzkoušel jinou vývojovou párty, pokud se cítí nakloněni.

Správná redesign/refaktoring může chránit investice vašich zákazníků a udržet věci udržitelné. Musíte to zabudovat. Optimalizujte pro změnu, cestovní světlo.

11
Joppe

Se všemi komentáři ohledně nadhodnocení se domnívám, že chybí skromné ​​množství bodů (dobrá příležitost).

Není to o odhadu času potřebného k provedení změny (jen) a poté o přidání, o odhadu času potřebného k úpravě kódu (refactor!), Aby byl přiveden do bodu, kdy může být změna bezpečně provedena, a pak provést změna (pravděpodobně poněkud propojená). Dobře, to je totéž ... ale není pochyb o tom, jak se chmurat, protahovat nebo nadhodnocovat, je to prostě otázka, že abych to mohl udělat, nejdřív to musím udělat a tak dlouho to bude trvat dohromady. Klíčem je to, že pracujete na těch částech systému, na kterých je změna závislá, a už ne - pokud existuje hrozné kód jinde ... těžké, chyťte je, když jste tam.

Abych se trochu vrátil k původní otázce - po mnoha letech to pro mě přijde, když něco implementujete, pokud víte (nevěříte, nečekejte (podezřelé?), Nemyslete ale vědět), že jsou vyžadovány další věci, pak byste měli udělat to, co potřebujete k provedení tohoto požadavku, a už ne v tak uklizené a elegantní módě, jak můžete.

Když přijdete na implementaci další věci - o něco později - podniknete kroky potřebné k tomu, abyste kódovou základnu (a databázi a cokoli) přivedli do stavu, který je nezbytný k implementaci této funkce, a to tak upraveným a elegantním způsobem, jak jen můžete. Toto refaktoring je místo, kde se vypořádáte s nepořádkem, který vzniká přirozeně v průběhu vývoje projektu - a doufejme, že se vyhnete vytváření dalších nepořádků (nebo alespoň udržet konzistentní úroveň).

Jednou z diskusních oblastí je „Technický dluh“ - je to jako přečerpání, musíte jej splatit a čím déle jej ponecháte, tím větší zájem (v tomto případě čas potřebný k nápravě) naroste - což vám dá dobrý argument pro strávení svého času minimalizací technického dluhu.

To je také místo, kde se začíná objevovat testování jednotek a další automatizované testování (pokud bych mohl dělat stejně dobře, jak říkám, že jsem si docela jistý, že budu šťastnější osobou!) V kombinaci se správným serverem pro sestavení (který může spouštět alespoň některé testů). V kombinaci s těmi - ale hodnotami samy o sobě - ​​jsou vzory jako injekce závislosti a inverze kontroly (nikdy si nejsou zcela jisty, kolik jsou „stejné“ tyto dva), protože usnadňují změnu vodovodní instalace a tím se zabývají změnami v instalaci izolace.

Konečně - pamatujte, že pokud se to nezlomí, neopravujte to. Uklízení kódu čistě kvůli jeho uklizení může být uspokojující, ale je to také příležitost k zavedení chyb, takže to může být bolestivé, pokud jej nemusíte měnit a nevyvíjíte na něm může být lepší nechat některé hrudky osamocené - příležitost opravit nebo vyměnit se nakonec převrátí!

6
Murph

1) Správná změna je vaším přítelem

Pokud zákazník změní specifikaci, která je v pořádku, je to jeho právo, jedná se však o změnu a je třeba ji zaúčtovat (nebo náklady, jakkoli je to vhodné pro strukturu/vztah projektu).

Odhad této změny by měl zahrnovat náklady na nezbytné refaktoring. Klient se může dobře starat o to, co se zdá být vysoké, ale v tomto bodě mu musíte vysvětlit, že protože kód je již napůl napsán, existují prvky, které je třeba přepsat, aby bylo zajištěno, že je robustní a podporovatelný v budoucnosti a že pokud se tak nestane, bude pravděpodobně mít problémy s budoucí podporou nebo změnami, které budou ještě dražší.

2) Refaktoring by měl být proveden tak, aby poskytoval klientovi skutečný dlouhodobý prospěch

Při zvažování refactoringu musíte vždy zvážit, co je skutečně potřeba a co je důležité, a zajistit, aby refaktoringová práce zajistila skutečnou dlouhodobou hodnotu za peníze.

Koneckonců bychom měli dělat tyto věci, aby kód zůstal rozšiřitelný a podporovatelný ve střednědobém/dlouhodobém horizontu, abychom zajistili, že investice klienta zůstane platná, nikoli z jakéhokoli úsilí o teoretickou dokonalost. Refaktoringová práce (a odpovídající odhady) by měla být prováděna s tímto rozsahem, a to nejen proto, že si nyní myslíte, že by mohl být o něco lepší způsob.

4
Jon Hopkins

Někteří programátoři naznačují, že způsob, jak řídit tento problém s klienty, je mít podepsat klienta a autorizovat počáteční specifikaci. Poté, když požádají o změnu požadavku, která není v původní specifikaci, řeknete jim, že musíte projít smlouvou a harmonogramem projektu, abyste mohli vypočítat dodatečné náklady a časová zpoždění, a poté přiložit přílohu smlouvy. Očividně to zajímá, jak zabránit klientům v tom, aby trvali na nových (nepředvídaných) funkcích.

3
Jas

Mám následující komentář v kódové základně, na které právě pracuji:

/*
 * Every time I see this function, I want to take a shower.
 */

Vím velmi dobře situaci, kterou popisujete. Snažím se (nejlépe) počkat, až se věci ustálí a jakýkoli druh „creepu“ má „crept“ vše, co bude dělat. Do té doby máte pravděpodobně vydáno něco použitelného a vy můžete nějakou dobu trvat, než věci vyčistíte a implementujete věci trochu jinak.

Nemůžete běžet kolem čištění mnoho malých nepořádků opakovaně. To jen ztrojnásobí vaši práci a frustrace. Počkejte, až se z něj stane větší, ale stěží se pohybující nepořádek, a pak s tím můžete něco udělat.

3
Tim Post

Nejraději bych se této situaci vyhnul.

Vše záleží na tom, jak čtete specifikace. Je snadné je považovat za kamenné tablety, ale ve skutečnosti se většina specifikací mění. Když navrhujete svůj kód, podívejte se, jak je pravděpodobné, že se každá část specifikace změní. Postupem času budete dost dobře předpovídat toto.

Po vstupu do nepořádku je zkušenost a úsudek velmi důležité. Píšete nové chyby kvůli tomuto špagetovému kódu? implementace trvá déle? tyto by ukazovaly na taktického refaktora.

do budoucna to zní, jako byste museli spolupracovat se svým zákazníkem. Řekl jim: „podívej se, že tento produkt se výrazně rozšiřuje nad původní specifikace. zákazník za to zaplatí.

2
Michael Shaw

Nabíjejte po hodině a pokud chce změny, řekněte, že je to v pořádku, ale do rovnice započtěte čas potřebný k zápisu dobrého kódu. Pamatujte také, že psaní kódu neater se vyplatí dlouhodobě, pokud jej musíte udržovat. Úspora času nyní vás může stát později.

2
Craig

Myslím, že psaní softwaru musí jít ruku v ruce s obchodními potřebami. Pokud se jedná o odhodlaný projekt (jako prototyp, který je třeba postavit za týden a nové vstupy přicházejí každý den), pak se nemusíte starat o spravovatelnost kódu a další věci - čas je rozhodující a potřebujete pouze Vysuňte kód ze dveří co nejrychleji.

Ale pokud píšete dlouhodobou aplikaci, pak má smysl to zvážit, protože to má značný dopad na to, jak dlouho bude trvat vytváření nových funkcí, oprava stávajících chyb, integrace do jiných aplikací a dalších věcí - a to se promítá do dopadu na podnikání (kvůli pozdějšímu času a nákladům).

Je tedy lepší citlivě rozhodovat o skutečných nákladech na neregulování kódu, kdykoli je to nutné - podle mých zkušeností, pokud jsou náklady a časový dopad obou možností vysvětleny měřitelným způsobem majiteli rozhodnutí, pak může být rozhodnutí bez přemýšlení. Neočekávejte, že vám lidé řeknou „jo, napiš krásný kód, i když to trvá dvakrát tolik času a nedává mi žádnou další výhodu“. Tak to prostě nefunguje.

1
Roopesh Shenoy

Ať je to součástí vašeho procesu, říkám tomu „extrémní refaktoring“ a bude to velké! ;) Prostě dělejte věci rychle a když bylo přidáno dost nových funkcí, že existuje jizvová tkáň, refaktorujte ji. Neustále se ptát sami sebe: „Kdybych začal od nuly, jak bych to udělal?“

Lidé, kteří si myslí, že dokážou navrhnout a přemýšlet o všem, co se děje v přední části, se většinou klamou, vy (a váš klient) se vždy učíte věci, jak budete postupovat. Využijte tyto lekce.

Protože jste dobrým programátorem, budete moci docela rychle refactor a jak to budete neustále dělat, kód začne mít „správnou formu“, což znamená, že bude flexibilnější a bude méně závislý.

Klienti by mohli být nadšeni, kdyby věděli, že „ztrácíte čas“ přepracováváním věcí, takže to nepožádá/neprozradí a je o tom opravdu rychlé.

Takto vyvinutý kód vám ušetří spoustu času na konci a zjednoduší přidávání nových funkcí.

Řekl bych také, že jedním z největších důvodů špatného kódu je strach, který někteří programátoři mají při provádění větších strukturálních refaktoringů, a čím déle budete čekat, tím horší bude.

1
Homde

Spolehněte se na vyšší výkon

Nechci se modlit. Chci říct, ujistěte se, že existuje podnikatel (tj. Projektový manažer nebo ekvivalent), který můžete umístit jako výplň mezi vámi a klientem. Pokud klient požaduje příliš mnoho, nechte obchodníka položit nohu dolů a být připraven ovládat „je to možné, ale nejsem si jistý, zda to spadá do rozsahu specifikace, viz [obchodní chlap]“.

V běžném průběhu projektu by měla být obecná specifikace zmrazena, než dojde k vážnému vývoji.

Mnoho klientů bude i nadále usilovat o změny/vylepšení/vylepšení, pokud jim to dovolíte. Mnoho z nich tuto schopnost zneužije na maximum, protože se cítí, jako by za své peníze získali maximum (i když to sabotuje váš projekt).

Požádejte osobu, aby se včas věnovala zdokonalování a zmrazování specifikace a aby ji později vymáhala.

Není nic špatného na tom, že s klientem uděláme něco navíc pro trochu dobré karmy, ale když se vymknou z ruky, buďte připraveni odložit na vyšší moc. Pokud specifikace vyžaduje směšné množství změn, možná je čas vrátit se obchodní smyčkou a přehodnotit smlouvu a/nebo přidat dodatky ke smlouvě (se spravedlivou peněžní kompenzací).

Skutečnost, že máte tento problém, má málo společného s tím, jak kódujete. Je to známka toho, že váš projektový manažer je na projektu nedostatečně využit (ať už je to vaše chyba, jeho chyba nebo obojí).

Jak již mnozí uvedli v mnoha odpovědích, je třeba u každého projektu také přidat časovou rezervu pro nepředvídané události, ale určení, které by mělo být rozhodnuto za zavřenými dveřmi, než bude specifikace zmrazena a doručena klientovi PM.

1
Evan Plaice

Nejjednodušší odpověď. Zastavil bych kódování jakéhokoli druhu, dokud nebude mít konečnou specifikaci přesně pro to, co od nynějška chce.

Pak musí upřednostnit tento seznam funkcí atd., Aby potvrdili, jaké položky musí mít právě teď a jaké lze provést později ...

Pomocí vašich zkušeností zjistíte, jaký je čas/cena každé funkce, a poté jim sdělte, jestli to chtějí, bude to trvat x množství času a peněz.

Vaše jednání s velkým zločinem plížení se do rozsahu funkcí a oni budou donekonečna přidávat funkce, dokud se nic nedělá nebo nedokončí tak špatně.

Řekněte jim, jakmile budete mít konečný seznam, že budete provádět budoucí úpravy, jak dávají přednost, ale musíte se zaměřit na prvních 15/20, které musí mít právě teď.

Pak na základě času do dokončení jim řekněte, že poté, co bylo toto vydání vydáno, budete otevřeni diskusi/brainstormingu další verze.

Jakmile bude přijato konečné rozhodnutí o tom, co je třeba udělat pro aktuální verzi, musí být všechny diskuse/nápady/návrhy zastaveny na 100%.

Pokud má nápady donekonečna, řekněte mu, aby si je zapsal do svého seznamu funkcí pro příští verzi, a nechte se soustředit na poskytování nejdůležitějších funkcí, které právě teď chtějí.

Pokud budou i nadále ztrácet čas, měňte svůj názor. Pak jsem přestal pracovat na projektu a pracovat na dalších projektech, dokud nedokončí svá rozhodnutí.

Je těžké to udělat, ale creep funkce je tak destruktivní, jako je čas, energie, motivace a jasné myšlení.

0
crosenblum

Z pohledu celého projektu:

Poučte se z kódu se svým týmem, podívejte se, co může být příště refactored a znovu použít, pak jděte si dát pivo.

Z hlediska vývoje:

Trpělivě vysvětlete, proč se vývoj zastavil, a vysvětlete, proč nemůže pokračovat, dokud nebudou všechny specifikace na stole a pochopeny. Pak jděte na pivo.

Z pohledu plánování:

Požádejte všechny specifikace předem a spolupracujte se všemi, abyste měli jasnou představu o cestě vývoje. Zapojte klienta/zúčastněné strany co nejblíže k zajištění toho, aby se všichni na stejné stránce. Později tu noc, dejte všem piva. Zítra zahajte projekt.

0
Kevin

Zabij ho ohněm.

Aka refactor co nejdříve: například když ošklivý kód pochází ze spěchu do termínu, já bych refactor po termínu, protože nemůžete (nebo byste neměli alespoň) přidat další funkce, dokud nebude existující kód udržovatelný, jinak bude to mnohem obtížnější ladit budoucí kódy.

0
wildpeaks

Počáteční řádný design nemůže pomoci vyhnout se problému. A je téměř nemožné (nebo velmi velmi obtížné) zvážit všechny budoucí „možná“ požadavky. Takže po nějaké době dorazí Big Re-factoring. A nejlepším řešením je přepsat vše.

Zkrátka: namísto namontování věže na červený Ferrari, znovu zvažte požadavky a postavte tank.

0
duros

Napište testy jednotek pro své projekty, které otestují aktuální stav, a poté, když budete mít čas, refaktor, abyste se vyhnuli rozbití projektu, když se jej pokoušíte vyčistit.

0
chiurox