it-swarm-eu.dev

Jak mohu přesvědčit vedení, aby se vypořádalo s technickým dluhem?

To je otázka, na kterou se často ptám při práci s vývojáři. Doposud jsem pracoval ve čtyřech společnostech a jsem si vědom toho, že není dostatečná pozornost na udržování čistoty kódu a řešení technického dluhu, který brání budoucímu pokroku v softwarové aplikaci. Například první společnost, pro kterou jsem pracoval, napsal spíše databázi od nuly, než aby použila něco jako MySQL, což vytvořilo peklo pro tým při refactoringu nebo rozšiřování aplikace. Vždy jsem se snažil být upřímný a jasný se svým manažerem, když diskutuje o projekcích, ale vedení se nezdá mít zájem o to, co už existuje, a je hrozné vidět dopad, který to má na morálku týmu.

Jaké jsou vaše názory na nejlepší způsob řešení tohoto problému? To, co jsem viděl, jsou lidé, kteří se balí a odcházejí. Společnost se pak stává otáčivými dveřmi, vývojáři přicházejí a odcházejí a zhoršují kód. Jak to sdělujete vedení, abyste je zajímali o třídění technický dluh ?

164
Desolate Planet

Když jsem se se svým šéfem setkal, abych o tom diskutoval, řekl, že do všech mých odhadů bych měl zahrnout refaktoring. Řekl, že to není problém, o kterém chce přemýšlet. Místo toho bych to měl zvládnout.

To není problém, o kterém by management obecně chtěl myslet. Nejsou to inženýři. Jen z toho udělejte nevyslovenou část všech vašich odhadů a zjistíte, že se technický dluh snižuje.

Nikdy to však nebude dokonalé. Technický dluh, stejně jako dluh z kreditní karty, je investicí do rychlejšího získání zákazníků a rychlejšího získání podílu na trhu u vašich konkurentů. Stejně jako úvěr, pokud je spravován správně, může vás docela uspět.

194
jmort253

Je to, jako řekl Gándhí, když se zeptal, jestli jeho taktika bude fungovat s někým, jako je Hitler. Řekl: „Bylo by to těžké.“ Ale myslím, že existuje spravedlivý argument, že odpověď je opravdu „Ne.“ Bohužel si nemyslím, že to, co se snažíte, je možné udělat. Není to tak, že se snažím být pesimistický, ale spíše se snažím být upřímný.

Problém pro mě není v tom, že manažeři potřebují přesvědčivé. Ti lepší už chápou, že dluh může být zabijákem, pokud nebude spravován. Ale ať už tomu rozumějí nebo ne, ať už jsou to dobří manažeři nebo špatní, všichni čelí tlaku na doručení a že dodání je soudí podle jejich šéfů proti datu. Kvalita záleží pouze na tom, že je to extrémně špatné, v tom případě je to chyba vývojářů, nebo extrémně dobrá, v takovém případě to vedlo k brilanci řízení. Kvalita musí být „dost dobrá“.

Myslím, že se mi líbí to, co řekla Renesis ve své odpovědi, protože je to jedna z mála, která chápe, že management myslí velmi odlišně než inženýrství. A myslím si, že jsme všichni viděli postup společností, aby se staly řízenými daty a více projektově řízeny, na rozdíl od zaměření na zákazníka a kvalitu. Tím mám na mysli typické společnosti, a ne ty skutečné společnosti, které mají odvahu říkat „Udělá to, až bude hotovo“ (jako Apple Počítač nebo id Software - a ano, já pochopit, že lidé někdy nemají takový přístup).

Ale tady je ta věc: společnosti, které přistupují k přístupu první kvality ... co si o nich všimnete? Správně, řídí je inženýři, ne prodejci, obchodníci, vedoucí projektů nebo účetní. Zamyslete se nad společnostmi HP, Apple, id, Google, Microsoft a IBM. Vše začalo a bylo úspěšné inženýry, ne prodejci, i když prodejci určitě hráli roli, a jsem si jist, že mnozí by debatovali o tom, že Microsoft bude spojovat kvalitu :). A z těch, kteří sjeli z kopce, uniklo strojírenství. V tomto prohlášení je však celá řada argumentů, protože existuje spousta technických společností, které nakonec selhaly kvůli neschopnosti přizpůsobit se měnícím se časům a řídit svůj vlastní růst. Nevidím inženýrské vedení jako příčinu těchto selhání, pro mě je to otázka dovedností a obchodních záležitostí, které jsou nezávislé na tom, že někdo je vývojář nebo účetní. Obecně si ale myslím, že v inženýrství existuje odhodlání přísným povinnostem a disciplíně, z nichž mají prospěch společnosti, kde je inženýrství součástí.

Vážně, rozhlédněte se kolem. Vedení IT velmi chybí. Důraz je kladen vždy na náklady a čas a jen zřídka na kvalitu, pokud je to dost dobré. IT lídři už jen zřídka podávají zprávy generálnímu řediteli, nyní je to vždy CFO. IT se zasekává o podporu produkce a stále více se dívá na projektové manažery, kteří se zaměřují na menší, stravitelnější a měřitelnější kousky, nikoli na významné změny revoluční hodnoty (ne že to je nutně špatné; rozdělení a dobytí je dobrá věc, ale vize, ale vize, musí tam být pro větší obrázek).

Litujeme, že na tomto příspěvku trvalo tak dlouho, ale nakonec si myslím, že vaše otázka o tom, jak zajistit, aby se management staral o technický dluh, se často lépe vyřeší hledáním správného vůdce, než změnou stávajícího. Vysvětlení technického dluhu standardním myslitelům znamená změnit zaměření na peníze a náklady, jak řekla Renesis, a myslím si, že v překladech hodně ztrácí; i když jste v tom byli úspěšní, záleželo by jen na tom, kdyby si ji koupil přední vůdce společnosti. Přesvědčíte-li svého středního manažera, aby udělal správnou věc, pravděpodobně ho vyhodí.

48
Bernard Dy

První věc, kterou musíte udělat, je změnit formulaci. Volání „technického dluhu“ dává vedení myšlenku, že je to investice nějakého druhu - když je to vlastně spíš virus. (Jsem jako Dave Ramsey technický dluh.)

Umožnění nezaplacení přichází s obrovskými náklady, které nelze vidět ani snadno kvantifikovat.

Seznam problémů, jako jsou následující pro správu:

  • Odhady nových funkcí jsou mnohem vyšší, než je třeba. Nebo úplně nemožné.
  • Špatný kód vyvolává další špatný kód
  • Seznam chyb roste, i když je vývojáři vždy opravují
  • Členové týmu odcházejí (to samo o sobě může ukázat, že existuje problém, jak je vysvětleno v tato vynikající odpověď )
43
Nicole

Můj management se skutečně začal vážně snažit řešit technický dluh, což je jeden z důvodů, proč tam pracuji, ale je to dlouhodobé úsilí a nikdy jim neuškodí připomenout jim, proč toto úsilí stojí za to.

Jedním ze způsobů, jak udržovat tlak, je kdykoli jsem požádán o odhad, a čas by mohl být ušetřen, kdybych nemusel řešit konkrétní technické problémy s dluhy, zahrnuji to do svého odhad. Například: „ Tato chyba mi potrvá 2-3 dny, ale pokud bychom již řešili tyto 2 další chyby„ nízké priority “, které byly ve frontě navždy, bylo by to pravděpodobně trvat méně než jednu. "Často bude odpovědí jít dopředu a opravit ty ostatní, když jste u toho.".

Souhlasím také s dalšími odpověďmi, které se týkají toho, že za svou práci považujete jen část vylepšení a pokud to není příliš rušivé, děláte je na cestách. Můj aktuální úkol spočívá v doplnění některých velmi špatně navržených kódů. Spíše než přidávání do nepořádku psáním nového kódu, aby odpovídal, trávím trochu času dopředu konsolidací běžné funkce, takže odesílání paketu se stává hovorem s jednou linkou namísto neustálého opakování 15 řádků mírně modifikovaných kopií a kopií vložit plotnu.

Skutečně vím, že to nějak zachrání zdravý rozum nějakého správce dále na silnici. Já vím, protože jsem dnes tím správcem. Věřím však také, že to zrychlí můj současný úkol, kdy se tato funkce dostane a odladí.

Další technikou, kterou jsem použil v minulosti a měl bych to udělat znovu, je ponechat refactorující větve DVCS kolem samostatného pracovního strom na tuto dobu, kdy jste kompilovali, čekali na dlouhý test, nebo stačí trochu změnit tempo, když jste vyhořel na chybu. Dokud se občas sloučíte z protisměru, takže se neodchylujete příliš daleko, můžete trvat tak dlouho, jak chcete, na změny refaktoringu s velmi malým okrajovým úsilím. 15 minut sem a tam denně se může časem opravdu sčítat.

30
Karl Bielefeldt

Můžete zkusit analogii kreditní karty. Zeptejte se jich „Cítíte se pohodlně nechat své výpisy z kreditní karty nezaplacené po delší dobu?“

Manažeři rozumí nákladům a výhodám, ale (obvykle) ne technickým pojmům používaným našimi vývojáři. Termín „technický dluh“ byl již vynalezen, aby pomohl překonat tuto komunikační bariéru, ale možná ji budete muset jasněji formulovat. Většina manažerů ví velmi dobře (často z vlastní zkušenosti), že po splatnosti kreditní karty rostou s hroznou úrokovou sazbou, takže bolí je nechat nezaplacené. To jim může pomoci získat závažnost problému týkající se softwarové entropie.

Pokud je to nepřesvědčí, pokuste se shromáždit faktografické důkazy a provést některé výpočty. Např. kolik to stojí pro společnost - jak v tvrdé hotovosti, tak ve ztraceném čase - nahrazení odcházejícího zaměstnance.

20
Péter Török

Nikdo nedá peníze za nahrazení něčeho, co funguje, něčím, co (s trochou štěstí) také funguje.

Co můžete udělat, je navrhnout jeho nahrazení něčím, co dělá více, tj. Spojit obsluhu technologického dluhu do upgradu, který přináší okamžité a hmatatelné obchodní výhody.

Samozřejmě byste o tom měli být otevřeni, nemluvíme zde o tom, že se do toho vplížíte v novém projektu.

Zjistil jsem, že na druhé straně, že vývojáři těžší zvládnout. Zjednodušeně řečeno: pro některé vývojáře je jistota, že váš kód je nejlepším možným kódem, se kterým můžete přijít, je věcí profesionální hrdosti. Pro ostatní je to jen další práce a cílem je rychle to udělat a jít domů.

Žádné množství přesvědčivých nezmění tuto situaci, a pokud zavedete povinný standard kvality kódu, devět až pět vývojářů najde způsob práce systému, zatímco vaši oddaní vývojáři budou nevyhnutelně otráveni celým postupem (což není Zaměřili jsme se na ně, ale nemůžete říci, že vývojář X musí dodržovat pravidla, zatímco Y může dělat, co chce).

Funguje to, ale stále může být velmi frustrující, že vaši nadšení a znalejší vývojáři dohlížejí na kodebázu, což je pravděpodobně dobrý kompromis mezi pokračováním a úklidem toho, co je v něm všude.

12
biziclop

Faktem je, že v mnoha společnostech, zejména s ohledem na současnou ekonomickou situaci, musí být někomu účtována každá hodina každou hodinu.

Nebo jdou dolů, rychle.

Pokud stávající klienti nejsou ochotni zaplatit za refaktoring, což je velmi nepravděpodobné, pokud nedojde k výrazně vylepšenému výkonu nebo funkcím. Pak se to nestane na starších kódových základnách. Možná budete moci proklouznout do rozpočtu pro novější projekty, pokud mají klienti hluboké kapsy, ale pokud nepotřebujete měnit API v refactoringu, nebude to pro starší projekty užitečné a může představit situace, kdy společnost podporuje dva kódové základny, což způsobuje další bolesti hlavy a náklady.

Jako inženýr bych ráda změnila starý kód, který již není k účelu vhodný, pokaždé, když se něco stane zastaralým nebo zastaralým. Ale jak mi MD ve všech společnostech, ve kterých jsem kdy pracoval, řekli: „Kdo zaplatí?“

12
Orbling

Vždy se snažím uklízet, když jdu. Neučiním, dokud nebude kód čistý. Problém s technickým dluhem je v tom, že mu většina lidí nerozumí. Nejlepší způsob, jak se s tím vyrovnat, není akumulovat nic z toho. Pokud vaši manažeři důvěřují vývojářům, že se rozhodnou, jak problém vyřešit, můžete hygienu kódu učinit součástí každé programovací úlohy. Pokud nikdy nezkontrolujete špatný kód, neshromažďujete dluh. Pokud také dodržujete Boy Scout Rule (vždy ponechte kód čistší, než jste jej našli), váš stávající dluh pomalu zmizí.

Refaktoring nevidím jako úkol oddělený od implementačních funkcí. Je jeho nedílnou součástí.

12
EricSchaefer

Pokud máte co do činění s netechnickými manažery, pomohlo by vám to, kdybyste svou diskusi vrhli do podmínek, kterým rozumějí. Pokud dokážete vytvořit realistický případ pro kladnou návratnost investic do práce vynaložené na splacení technického dluhu, můžete se někam dostat. Toto cvičení bude záviset na vašich okolnostech, ale příkladem může být něco takového:

Analyzujte, kolik času jsou vývojáři nuceni strávit pomáháním Podpora s problémy s výrobou, a pak se ujistit, že by stanovení opraveného starého kódu A. snížilo počet problémů s podporou, B. Usnadněte podpoře řešení problémů bez eskalace rozvoje a C. zkrátit čas, který vývoj vynakládá na výrobní problémy, když k nim dojde. Řekněme to v podobě dolarů ušetřených tím, že vývojáři nejsou svázáni při provádění podpůrných prací. Upozorňujeme také, že každou hodinu, kterou vývojář věnuje podpoře, je „dvojitá whammy“, protože nejenže platíte vývojáři za podporu, ale pálíte také příležitostné náklady na to, co by tento vývojář mohl dělat (přidávání nových funkcí atd.) .)

Ano, některá čísla budou voodoo/kouř-a-zrcadla ... to je v pořádku, špinavé tajemství managementu je, že vědí, že většina čísel, která se pohybují kolem, je celkem B.S. Pokud jim dáte něco zdánlivě konkrétního, s čím mohou pracovat, aby si to mohli vzít do hlavy, máte šanci na boj.

7
mindcrime

Po tomto vysvětlení technického dluhu by měla být vaše vedení přesvědčena, aby vám vyplatila:

Představte si, že máte velmi špinavou kuchyň plnou kecy. Před přípravou jídla musíte nejprve strávit jednu hodinu úklidem. A je to jako vždy, když chcete jíst. Také při přípravě jídla musíte být obzvláště opatrní, abyste se ujistili, že svinstvo nespadá do vašeho jídla.

Kuchyň je váš kód, jídlo je váš produkt a jídlo je prodejem vašeho produktu.

Pokud si mohou dovolit déle čekat na provedení změny, bez bezpečné sítě testů jednotek, pak je ve vaší společnosti něco špatného.

6
BЈовић

Pokud jde o původní produkt a obchodní případ, musí to být velmi přesvědčivý argument, že jsem nemohl použít tyto peníze nyní, abych pro mě udělal něco důležitějšího. To se vám líbí nebo ne, vaše vedení nebo vaši zákazníci za to platí a musíte být schopni je prodat, aby je přesvědčili.

Pojďme to přeformulovat, abychom se postavili jako zákazník. Dobrá stará role.

Předpokládejme, že kupujete ledničku. A mohli byste si koupit ledničku za 1 000 USD, která fungovala v pořádku od společnosti Acme Corp. Nebo ledničku za 2 000 USD od Acme Deluxe Fridges, která vypadala stejně na vnější straně a měla stejné technické specifikace, ale díky čistší vnitřní architektuře měla nižší náklady na údržbu.

Jako zákazník, který byste si sami koupili?

A co si inženýři Acme Deluxe myslí, že je lepší odpověď?

4
jasonk

" Technický dluh " může být choulostivé téma, které může vedení představit, protože nemusí vidět jeho potřebu. Otázka by mohla být orámována jako to, zda ve společnosti existuje šampion, který říká: „Podívej, bereme X% času na práci na technickém dluhu tady. podobný. Existuje nárok na autonomii, ale také časový rámec, protože jinak se vedení může ptát, jak dlouho, dokud neuvidí nějaké výsledky, které jsou spíše nebezpečným územím.

Prvním bodem je však to, zda to vidí jako problém. Pokud osoba se špatným zrakem neví nic o brýlích a jaké změny může poskytnout, jak pochopit, proč by oční test mohl být cenný? Stejná myšlenka zde, kde je předmět spíše technický a bohužel není snadno kvantifikovatelný.

3
JB King

Měli byste na to přestat stěžovat.

Zde je proč:

  1. Nikdy neplánují používat software déle než rok
  2. je to jen ztráta času vyladit to, pokud mají v úmyslu jej poté vypsat
  3. teď jsou nějaké skutečné problémy, které je třeba nyní opravit
  4. programátoři se prostě musí naučit vypořádat se s údržbou, i když to není vždy zábava
  5. stěžovat si, že víte, že to, co je třeba udělat, je arogantní - někdo jiný činí rozhodnutí a měli byste být z toho spokojeni
  6. V každém případě ti věří, že píšete dobrý kód

Nejlepší cesta vpřed je:

  1. Když vám dají nový úkol, zkuste jej implementovat co nejlépe v daném čase
  2. Napiš to poprvé poprvé. Potřebujete-li to později změnit, udělali jste chybu poprvé a každá změna se vždy ukáže špatným směrem - a programátoři to mají příležitost učit se, když dělají chyby.
  3. Nepožádejte o to více času, nezískáte to, existují termíny, které znáte.
2
tp1

Beru to, že jste nikdy nebyli zapojeni do projektu na přepisování/nahrazování nebo dokonce upgrade a stávající systém.

Toto jsou některé z nejtěžších projektů, které lze úspěšně dokončit. Některé z problémů, se kterými se setkáte, jsou:

  1. Obchodní pravidla jsou ztracena v čase.
  2. Dokumentace a implementace jsou zcela mimo synchronizaci.
  3. To, co vidíte jako chybu, uživatelé vidí jako funkci.
  4. Naopak na mnoho „funkcí“ budou uživatelé pohlížet jako na vady.
  5. Nebudete uživatele kupovat - budou považovat vaše „zjištění faktů“ za „blbce, kteří kladou hloupé otázky“, pokládají testovací úsilí za ztrátu času, budou trvat na přidávání nových funkcí, takže prodloužení projektu bude už jsou pozadu.
  6. Šance, že zdrojový kód neodpovídá 100% spuštěnému spustitelnému souboru.
  7. Zatímco vaše oddělení se hádá o refaktoring vývoj podnikání skutečně chce, není hotovo.
  8. Je pravděpodobné, že vaše re-factoring bude zahrnovat „čistší vylepšená rozhraní“, čímž se ostatní projekty dostanou do vaší kritiky pozdního doručení a neúspěšných testů.
  9. Poté, co je projekt konzervovaný (více než 50% těchto snah zcela selže), ztratíte veškerou důvěryhodnost - budete se muset přestěhovat do jiné společnosti v jiném městě, abyste našli někoho, kdo je připraven vás také poslouchat.
  10. Pokud projekt uspěje, všichni si budou pamatovat, jaká to byla noční můra - budete .......

Vyzývám vás, abyste se vyhnuli jakémukoli přepisování/refaktoringovým projektům, jako je mor, mohou být jedny z nejnepříznivějších zkušeností v jakékoli profesní kariéře.

Ve fráze „Pokud to není zlomeno, je mnoho moudrosti, neopravujte to“.

2
James Anderson

Poté, co jsem se již zapojil do velkého přepisu (nejen refaktora), mohu souhlasit s tím, že přimět finanční kluky, aby souhlasili s projektem, byly jednou z hlavních překážek. Překonání této překážky vyžadovalo, abych napsal, předložil a hájil zprávu, která upozornila na řadu problémů, které znamenaly, že obchodní společnosti budou v blízké až střednědobé perspektivě mrtvé ve vodě.

Klíčové faktory pro dosažení dohody:

  • Existující kód byl v již nepodporovaném řetězci nástrojů (MicroPower Pascal), který fungoval pouze na téměř nepodporovatelné vývojové platformě (PDP11-23).
  • Hledání vývojářů, kteří by mohli pracovat na nástrojích a cílech, bylo téměř nemožné.
  • Cílový hardware již nebyl k dispozici, pokud by byly zapotřebí náhradní díly a výrobce se stále více zdráhal poskytovat opravárenskou službu.
  • Problémy v kódu vedly k snadno identifikovatelné nespokojenosti zákazníků a přímým nákladům na servis.
  • Přidávání nových funkcí nebo dokonce opravy chyb se staly téměř nemožnými kvůli omezením cílového hardwaru, což vedlo k potřebě refaktorovat jiné oblasti, aby poskytovaly místo při řešení problémů.
  • S 8 hodinovým vývojovým časem byl vývoj a testování jakékoli změny nákladné.

Zpráva podrobně popsala problémy s odhady probíhajících nákladů a nabídla 3 možnosti:

  1. Zamrzněte tam, kde jsme v blízké budoucnosti pravděpodobně nebyli ani opraveni chybami.
  2. Optimalizujte kód pouze pro prostor, bez ohledu na udržovatelnost, poukazují na to, že kdokoli, kdo by se pokusil udržet optimalizovaný kód, by musel být chytřejší než kdokoli, kdo provedl optimalizaci.
  3. Znovu implementujte, s možností testování a údržby jako vysokých faktorů, v průmyslovém standardu, široce vyučovaným jazykem (ANSI C), na nový, nízkonákladový hardware COTS (PC-104), s více prodejci, kteří jsou k dispozici v domě navržená karta rozhraní, která umožňuje práci se zbývajícím existujícím hardwarem. V rámci vývoje, jako je například energeticky nezávislé úložiště, přidána omezená sada nových funkcí, časovač hlídacího psa, který zajistí automatický restart v poruchovém stavu některé jednotky havarovaly vícekrát denně a vyžadovaly servisní hovor 40 GBP) out to reset, lepší diagnostika v procesu.

Poté, co jsem se rozhodl pro 3. variantu, se moje 3 měsíční smlouva změnila na 3 roky velmi tvrdé práce, jak vývoje nového softwaru, tak hardwaru, ale s velmi dobrým výsledkem.

Pro případy s méně extrémním technickým dluhem mám sklon přijímat to, čemu říkám partyzánské refaktoring:

Pokud se vyskytne problém s konkrétním modulem:

  1. Napište sadu testů, které demonstrují problém které pravděpodobně také selžou bez refaktoring
  2. Refaktor v rámci vývoje, který zdůrazňuje, že testy stále selhávají.
2
Steve Barnes

Za můj život nechápu, proč se někteří lidé tak slepě bojí změny - zavrhuje nedostatek důvěry ve vaše vlastní schopnosti.

Včera v noci jsem viděl show v národním parku Yosemite a bylo poznamenáno, že od roku 1940 do konce 90. let nevyklíčil ani jeden nový strom Sequoia. Bylo zjištěno, že důvodem bylo to, že existovala přísná politika proti tomu, aby lesní požáry hořely, a že šišky Sequoia potřebovaly teplo z ohně, aby se otevřely a uvolnily jejich semena.

Víte, oheň každých deset let byl zdravý. Vyčistilo veškeré nahromaděné mrtvé dřevo a ostružiny, aby se zachovaly zdravé stávající stromy (procesy) a vytvořil se prostor pro nové (funkce).

Právě jsem na projektu, který má jasný důvod k přestavbě: Starší software byl napsán výhradně pomocí webových formulářů .NET. Téměř veškerá obchodní logika je kombinována s logikou zobrazení značek HTML/server a po rozšíření firmy ji nelze rozšířit na další aplikace.

Management je za tímto úkolem, protože mají přiměřenou důvěru ve své vývojáře, což je, jak si uvědomuji, vzácný luxus.

Ano, zeptejte se sami sebe, zda je přestavba skutečně nezbytná. Snažte se znovu použít stávající kód, který funguje tam, kde je to možné. V případě potřeby integrujte tento kód do nového sestavení. Jen nenechte nikoho přesvědčit, že obávat se odvážných změn je jediný způsob, jak existovat jako vývojář softwaru.

Hodně štěstí!

1
Matt Cashatt

Musíte dát svému vedení finanční důvod k řešení technického dluhu a rámec pro správu snižování tohoto technického dluhu.

Udržování technologický plán je jedním takovým rámcem. Začít s plánem vám pomůže zabránit hromadění technického dluhu a také vám pomůže snížit stávající dluh.

Mnoho úspěšných dlouhodobých projektů přidružilo řídící výbory a cestovní mapy k vedení vývoje. To je zvláště užitečné, když je zapojeno více vývojových týmů a zúčastněných stran.

Navrhuji, abyste tuto strategii prodiskutovali se svými manažery (a pokud možno s těmi, kdo rozhodují o tom, kde se peníze utratí).

Obecný přístup k vytváření a správě cestovní mapy je přímý, ale vyžaduje podporu vašeho řídícího týmu. Nejprve definujte cíl. Definujte prvky technického dluhu a vytvořte architekturu cílového systému, která snižuje prvky vašeho technického dluhu. Pamatujte, že to nemusí být dokonalé, jen proveditelné a lepší než to, co jste v současné době. Vezměte v úvahu software, vývojové nástroje, hardwarové platformy, hlavní nové funkce, které mohou být do systému přidány. Proveďte analýzu nákladů. Pokud máte požadovanou architekturu, jaké jsou hmatatelné výhody provedení refaktoringu? (Mezi výhody patří zkrácení doby testování, spolehlivější softwarové produkty, předvídatelnější vývojové cykly atd.) Pokud můžete prokázat dostatek výhod pro provádění refaktoringu, můžete získat podporu řízení.

Jakmile budete mít cestovní mapu a podporu správy, vytvořte řadu kroků (nazývaných také plán), které musíte podniknout, abyste se dostali do tohoto požadovaného stavu. Může být dobrý nápad sestavit řídící výbor, který udržuje plán, školí a vzdělává vývojové týmy na plánu a pravidelně kontroluje změny z hlediska architektonické integrity.

Plány jsou opravdu užitečné a možná, že 13. otázka v testu Joel by měla znít „Máte plán?“

Zde je video z první hodiny nedávné relace cestovní mapy Red Hat Linux .

1
Jay Elston