Utvecklare älskar att "fixa" kod - här är varför det är ett problem

Varje produkt utvecklas på sitt eget mystiska sätt. Även det erfarna teamet kan inte förutsäga varje vändning i produktens livscykel. Enkla funktioner kan överföras till monstruösa arbetsflöden med flera villkor. Vissa snabbutvecklade sidoscenarier kan bli de mest använda. Till och med produktens popularitet kan orsaka oväntade prestandaproblem. Och det är helt normalt att anpassa mjukvara för marknadens behov. Det enda sättet att få en tillförlitlig och förutsägbar produkt är att reservera lite tid för att fixa tekniska skulder och tillhandahålla en korrekt omstruktureringsprocess.

Det är bättre att inkludera några definitioner av termer i den här artikeln. Teknisk skuld, eller teknisk skuld, är de ackumulerade kompromisser i kodbasen, som kan inträffa under snabb utveckling eller andra fluktuationer. Refaktoreringsprocessen handlar mer om att förbättra produkten i allmänhet. Det kan innebära aktiviteter relaterade till prestanda, bättre kodstruktur och enkelhet i lösningen. Men ibland kan dessa två begrepp vara mycket nära varandra. Till exempel kan ett fåtal funktioner fulla av tekniska skulder kräva ordentlig omstrukturering av hela modulen för att lösa problemet en gång för alla med nya idéer och omimplementering.

Och här är tricket. Generellt sett har bra mjukvaruutvecklare gott om idéer för produktförbättringar. "Okej, vi kan justera några saker under den här funktionen." "Åh, det är inte så viktigt men det skulle vara trevligt att fixa det här i den här sidomodulen". Ändå är det avgörande att ge dina teammedlemmar möjlighet att förbättra kodbasen, eftersom det hjälper till att bygga verkligt involverade team. Men i den här artikeln skulle jag vilja avslöja refaktoreringsprocessen ur en chefsperspektiv. Exemplen ovan har ett problem - de kan vara ogenomskinliga för hela laget utom utvecklare. Medan QA och chefer har sin plan att släppa korrekt och stabil programvara enligt schemat, kan vissa dolda förbättringar skapa oväntade vändningar och nervösa omtester under releasen. Eller till och med nya buggar i produktionen om vissa odokumenterade ändringar går obemärkta under regressfasen. Så kodförbättringar är nödvändiga, men de bör vara hanterbara.

Hur man bygger en hanterbar refaktoreringsprocess i ditt team

Lösningen är komplex. Agile är vår bästa vän eftersom vanliga principer och ritualer för Agile utvecklingsmetoder täcker problemställen. Du behöver:

1. Bygg upp tekniska skulder och fördela resurser regelbundet.
2. Upprätta korrekta grooming- och planeringsprocesser för att upptäcka potentiella förbättringar.
3. Deklarera processer vid oväntade problem under iterationen.

Med grooming menar jag kommunikation mellan teammedlemmar före iteration som syftar till att definiera iterationens omfattning, specificera krav, bryta ner uppgifter, uppskatta insatser och prioritera framtida arbetsmoment. Planeringsprocessen är kopplad till den resulterande omfattningen av iterationen. Inte alla gjorda uppgifter kanske inkluderas i iterationen.

Låt oss dyka in i varje ämne.

Byggteknisk skuldeftersläpning och resursallokeringsregel

Det enklaste sättet för varje utvecklare att bygga upp en teknisk skuldstock är att använda "Att göra"-taggar i källkoden. Senare kan du söka i kodbasen, förbättra något och skicka pull-förfrågningar för godkännande. Men det räcker inte. Det hjälper inte teammedlemmarna att planera ordentligt och vara säkra på omfattningen av utgivningen.

Det bättre alternativet till att använda "Att göra" är att skapa en process för att skapa uppgifterna för framtida förändringar. Om utvecklaren hittar någon potentiell problemplats eller har en idé för att förbättra kodbasen, bör de skapa ett arbetsobjekt i biljettsystemet (Jira, Azure DevOps eller vilket system teamet nu använder). Det skulle vara överdrivet att kräva att ingenjörer tillhandahåller en detaljerad beskrivning av sin idé för varje gruppmedlem, men förklaringen bör vara tillräckligt tydlig för att teamledaren ska förstå nyckelpunkten och omfattningen av förändringar. Detta täcker det första steget - hur vi kan skapa en lista över potentiella uppgifter och ge en beskrivning på hög nivå av framtida förändringar.

Steg två är att göra det begripligt för alla. Denna uppgift kan hanteras av utvecklingsteamledaren, releasechefen eller produktchefen, beroende på deras kvalifikationer. Resultatet bör ge följande detaljer:

• Vad gör vi? – En förklaring på hög nivå av idén.
• Varför gör vi detta? - En beskrivning av hur dessa förändringar kan förbättra utvecklingshastigheten, minska risken för instabilitet orsakad av spagettikod eller öka mjukvarans prestanda.
• Hur viktiga är dessa förändringar för framtida utveckling? - Förändringars prioritet. Till exempel, utan dessa förändringar, kan kostnaden för framtida förbättringar eller affärsfunktioner växa exponentiellt.
• Vilka risker skapar dessa förändringar? - En lista över berörda funktioner eller moduler för att hjälpa QA att verifiera ändringarna.

Om arbetsobjektet har svar på alla dessa frågor hjälper det till att lindra potentiella problem i framtiden. Det räcker dock inte att enbart ha en eftersläpning för en hanterbar omstrukturering. Du måste planera möjliga förändringar, och de bör vara en ständig del av din process. Visst, du kommer att möta trycket från affärsfunktioner och marknadskrav, där frestelsen att utelämna tekniska uppgifter är stor. Men utan ordentligt underhåll kommer du att möta ännu större problem i framtiden.

Rekommendation för den tekniska eftersläpningen är:

1. I varje iteration måste teamet reservera tid för tekniska förbättringar.

2. Om det finns någon idé till förbättring bör den formaliseras som ett arbetsobjekt med en korrekt beskrivning.

3. Arbetsuppgifter bör delta i groomingprocessen och diskuteras av hela teamet tills alla fördelar och risker har identifierats och uppskattningar från alla teammedlemmar har samlats in.

4. Arbetsobjekt ska planeras till agila iterationer enligt deras uppskattningar.

   
   

Teamet bör erkännas för möjlig teknisk skuldvolym i iterationen. Reserverad tid kan ökas vid behov, men bör aldrig vara mindre än det ordinarie beloppet. Detta hjälper till att uppmuntra ingenjörer att skapa nya uppgifter i eftersläpningen och prioritera dem. Alla vet att deras förslag skulle kunna implementeras och eftersläpningen kommer att krympa en dag, inte växa till en enorm demoraliserande lista.

Använda grooming och planeringsprocesser för potentiella tekniska skuldavslöjande

Ibland kan tekniska skulduppgifter avslöjas under diskussion och uppskattning, medan teamet stötte på oväntade hinder som gjorde realiseringen mindre tillförlitlig och flexibel. Till exempel kanske du inser att det finns liknande funktioner och att skapa en helt ny skulle bara förvärra kodbasen. Men de funktionerna innehåller inte den affärsfunktionalitet som krävs i nya. Och det är bättre att skapa en enhetlig tjänst som kopplar ihop alla liknande funktioner för att förenkla underhållet i framtiden. Ändå kan denna förändring påverka och destabilisera gamla funktioner och det är där utmaningen ligger. Kanske finns det ett sätt att utveckla nya funktioner billigt och blunda för brister. Eller kanske just nu är den bästa möjligheten att skapa en enhetlig tjänst medan det bara finns ett fåtal liknande funktioner. Det viktigaste är att etablera en process som hjälper teammedlemmar att fatta ett beslut baserat på avslöjade fakta och korrekt gjorda uppskattningar. Det är avgörande att ha ett system som förhindrar situationer där sådana beslut bör fattas under implementeringsfasen i en engagerad eftersläpning.

Om dina iterationssteg fungerar bra, kommer avslöjandet av sådana ögonblick att ske automatiskt via en ordentlig grooming- och planeringsprocess. Det finns några grundläggande regler och steg som i de flesta fall kan skydda laget från oväntade hinder:

1. Grooming backloggen bör innehålla uppgifter med tydliga och genomförbara krav.
2. Grooming eftersläpningen bör delas med teammedlemmar innan diskussion och uppskattning.
3. Alla gruppmedlemmar måste vara förberedda och förtrogna med uppgifterna innan de görs.
4. Om någon eftersläpning kräver ytterligare utredning eller omimplementering bör problemet diskuteras.
5. Krav på problematiska eftersläpningsobjekt bör slutföras baserat på avslöjade egenheter. Alla potentiella problemområden bör dokumenteras.
6. Varje eftersläpningspost bör uppskattas.

Problematiska eftersläpningsobjekt skulle kunna delas upp i separata uppgifter och planeras enligt prioriteringar. Beslut om implementeringsstrategin kan vara upp till release manager, beroende på risker och deadlines. Men detta tillvägagångssätt hjälper till att dokumentera alla beslut. Även om den tekniska skulduppgiften sköts upp, läggs den fortfarande till eftersläpningen. Senare bör dessa uppgifter ses över och schemaläggas. Denna process fixar scenarier där några bra och nödvändiga idéer glöms bort under en hektisk iteration.

Upprättande av process vid oväntade problem under iterationen

Ändå är det möjligt att stöta på oväntade och tidskrävande hinder under utveckling, även med en väl underhållen teknisk skuldstock och en fungerande skötsel- och planeringsprocess. Programvaruprodukter kan vara komplicerade, särskilt gamla eller innehållande rik funktionalitet.

Att använda agila metoder hjälper till att samla information tidigt och fatta ett korrekt beslut. En av de enklaste lösningarna är dagliga möten.

Om en ingenjör står inför något problem bör det dyka upp under mötet och diskuteras senare. Varje hinder är unikt och kan ta olika lång tid. Det spelar ingen roll om ändringen kommer att implementeras i den aktuella iterationen, istället för en "Nice to have"-funktion, eller kräver en fullständig revidering av iterationens omfattning. Emissionen bör skapas som en typisk teknisk skulduppgift i spårningssystemet, dekomponeras och beskrivs som vilken annan liknande uppgift som helst i tidigare artiklar. Konsekvens är nyckeln, och teamet måste veta hur de ska hantera dessa situationer.

Kritik mot ytterligare byråkrati och hur man svarar på den

Alla dessa metoder kan verka som ett ytterligare sätt att ta hela lagets tid med värdelös byråkrati. Och det kan vara så om bara frånvaron av strikta och tydliga regler inte skapade svåra tider för alla. Det är OK att inte följa dessa rekommendationer i kortsiktiga projekt eller vid minimalt värdefull produkt (MVP). Att arbeta i produktionen med kvalitetsansvar och stora produkter kräver dock ett väldefinierat internt processsystem. Låt oss gå igenom de vanligaste invändningarna.

Att skapa sådana uppgifter är tidskrävande och ibland går det snabbare att göra ändringar i koden än att beskriva dem

Och det är sant. Att beskriva dina uppgifter på naturligt språk kan ibland vara svårare än att fixa koden. Men här är några lösningar:

• Att skapa ett system med mallar i biljettsystemet kan vara till hjälp. Det gör att uppgifter kan läggas till snabbt och fyllas med rätt parametrar och länkar.
• Det är bra att ha några biljettpolicyer på företagswikin, som Confluence/Notion/SharePoint eller någon annan teamdokumentationsplattform. Dessa sidor kan ge bra exempel på korrekt skapade uppgifter. Det ligger i teamledarens bästa intresse att underhålla teknisk dokumentation och polera mallar för att hjälpa alla andra teammedlemmar att skicka in tydliga och begripliga biljetter.
• På grundnivå räcker det att tvinga ingenjörer att skapa uppgifter med beskrivningar på hög nivå utan omfattande artiklar om strategisk vision eller potentialen i deras förslag. Beskrivningen ska hjälpa granskaren (vanligtvis teamledaren) att få huvuduppfattningen om förändringar. Senare kan teamledaren validera förslaget och fylla det med ytterligare detaljer enligt processen. Detta hjälper också till att förstå om dessa ändringar ens är nödvändiga och ger ett kvalitetsfilter.
• Om utvecklaren har tid att implementera förslaget kan funktionsgrenpolicyn vara till stor hjälp. Ändå är det nödvändigt att skapa en uppgift, eftersom det är användbart att ha en regel för att skapa funktionsgrenar namngivna efter biljett. Men som ett resultat får vi en nöjd ingenjör, som har implementerat någon bit av teknisk skuld, biljett och kopplad implementering som kan skötas och planeras för verifiering i en lämplig iteration, utan risk för oväntad destabilisering.

Alla dessa ändringar är mycket tekniska och beskrivningen hjälper inte eftersom ingen kommer att förstå idén

Kanske. Men det beror på förklaringen. Prioriteten är beskrivningen av vad som kan gå fel och vilken funktionalitet som kan destabiliseras. Det är dock användbart att skriva om effekterna av förändring eftersom det hjälper till att identifiera ytterligare möjligheter och scenarier. Även de mest djupt tekniska idéerna kan beskrivas i enkla meningar med naturligt språk. Om de inte kan det kan det vara något fel med själva idén, och det kan vara en potentiell risk, hela förslaget bör omprövas.

Skriv bara något i stil med:

"Metod "XXX" förbrukar för mycket RAM-minne vid varje samtal. Att skapa en extra cache för den här metoden hjälper till att minska RAM-förbrukningen och påskynda alla API:er. Metoden använder data som ändras sällan, det räcker att släppa cachen vid omstart. Ändringarna är säkra, men kan potentiellt påverka följande funktioner: XXX, XXX, XXX...".

I vissa fall skulle detta vara tillräckligt. I andra kan det här förslaget utlösa diskussionen, eftersom ingenjören kanske glömmer gammal men fortfarande använd funktionalitet där denna cache kan orsaka problem. Under groomingprocessen kommer idén att revideras, och teamet kommer att hitta en kompromiss.

Alla dessa policyer hindrar bara användare från att ta emot nya förbättringar

Stabilitet och tillförlitlighet är bättre än några få procentuella förbättringar under vissa funktioners exekveringstid. Ingen kommer att bli besviken över att missa en potentiell prestandaökning, men det är lätt att smutskasta en produkts rykte.

Behöver vi all denna byråkrati för en enkel kodstil som aldrig kommer att göra någon skada i 99,99 % av fallen?

Tanken är att effektivisera processer och hjälpa till att bedöma risker. Ingenjörer bör ha möjlighet att underhålla kodbasen och tillhandahålla vissa förbättringar. För saker som är små och inte destabiliserar hela produkten, är det möjligt att skapa samlade arbetsobjekt som kan slutföras under iteration. Dessa uppgifter måste fortfarande granskas som pull-förfrågningar men det är inte nödvändigt att formellt meddela dem till teamet.

Slutsats

Ständiga produktförbättringar är avgörande för företag och hjälper till att bevara den övergripande kvaliteten. Om du håller den tekniska skulden och nya idéer på hyllan kommer du att fastna med en föråldrad produkt och snart kämpa för att hitta expertingenjörer för att underhålla den.

Å andra sidan konkurrerar dessa uppgifter med affärsfunktioner och andra idéer som kan driva affärer till nya horisonter. Dessa rekommendationer om eftersläpning av tekniska uppgifter kan hjälpa till att avslöja och bedöma betydelsen av dessa uppgifter, inte bara för teammedlemmar utan också för intressenter. De hjälper till att presentera dessa idéer på ett naturligt språk och behålla och skydda tid för implementering. Det belastar ingenjörer med ytterligare åtgärder, men i slutändan hjälper det hela teamet att leverera högkvalitativa och pålitliga produkter. Och chefens ansvar är att välja rätt instrument eller policy för att upprätthålla denna process.