Kehittäjät rakastavat "korjaa" koodia – tässä on syy, miksi se on ongelma

Jokainen tuote kehittyy omalla salaperäisellä tavallaan. Kokenutkaan tiimi ei voi ennustaa jokaista tuotteen elinkaaren käännettä. Yksinkertaiset ominaisuudet voidaan siirtää hirviömäisiin moniehtoisiin työnkulkuihin. Joistakin nopeasti kehitetyistä sivuskenaarioista voi tulla eniten käytettyjä. Jopa tuotteen suosio voi aiheuttaa odottamattomia suorituskykyongelmia. Ja on täysin normaalia mukauttaa ohjelmistoja markkinoiden tarpeisiin. Ainoa tapa saada luotettava ja ennustettavissa oleva tuote on varata aikaa teknisen velan korjaamiseen ja kunnolliseen uudelleenjärjestelyprosessiin.

On parempi sisällyttää tähän artikkeliin joitain termien määritelmiä. Tekninen velka tai tekninen velka on koodikannan kertyneitä kompromisseja, joita voi syntyä nopean kehityksen tai muiden vaihteluiden aikana. Refaktorointiprosessissa on enemmän kyse tuotteen parantamisesta yleisesti. Se voi sisältää toimintoja, jotka liittyvät suorituskykyyn, parempaan koodirakenteeseen ja ratkaisun yksinkertaisuuteen. Joskus nämä kaksi käsitettä voivat kuitenkin olla hyvin lähellä toisiaan. Esimerkiksi muutama ominaisuus, joka on täynnä teknistä velkaa, saattaa edellyttää koko moduulin kunnollista uudelleenjärjestelyä ongelman korjaamiseksi lopullisesti uusien ideoiden ja uudelleentoteutuksen avulla.

Ja tässä on temppu. Yleensä hyvillä ohjelmistokehittäjillä on paljon ideoita tuoteparannuksiin. "Okei, voimme säätää joitain asioita tämän ominaisuuden aikana." "Voi, se ei ole niin tärkeää, mutta tämä asia olisi mukava korjata tässä sivumoduulissa". Silti on erittäin tärkeää antaa tiimisi jäsenille mahdollisuus parantaa koodikantaa, koska se auttaa rakentamaan todellisia osallistuvia tiimejä. Tässä artikkelissa haluaisin kuitenkin paljastaa refaktorointiprosessin johtajan näkökulmasta. Yllä olevissa esimerkeissä on yksi ongelma - ne saattavat olla läpinäkymättömiä koko tiimille paitsi kehittäjille. Vaikka laadunvarmistuksella ja johtajilla on suunnitelma julkaista oikea ja vakaa ohjelmisto aikataulussa, jotkin piilotetut parannukset voivat aiheuttaa odottamattomia käänteitä ja hermostuneita uudelleentestejä julkaisun aikana. Tai jopa uusia bugeja tuotannossa, jos jotkin dokumentoimattomat muutokset jäävät huomaamatta regressivaiheessa. Joten koodin parannuksia tarvitaan, mutta niiden pitäisi olla hallittavissa.

Kuinka rakentaa hallittava refaktorointiprosessi tiimiisi

Ratkaisu on monimutkainen. Ketterä on paras ystävämme, koska ketterän kehitysmetodologian yhteiset periaatteet ja rituaalit kattavat ongelmakohdat. Sinun tulee:

1. Rakenna teknistä velkakantaa ja kohdista resursseja säännöllisesti.
2. Luo asianmukaiset hoito- ja suunnitteluprosessit mahdollisten parannusten löytämiseksi.
3. Ilmoita prosessit odottamattomien ongelmien varalta iteroinnin aikana.

Hoitotyöllä tarkoitan ryhmän jäsenten välistä viestintää ennen iteraatiota, jonka tarkoituksena on määrittää iterointilaajuus, määritellä vaatimukset, hajottaa tehtäviä, arvioida ponnisteluja ja priorisoida tulevia työkohteita. Suunnitteluprosessi liittyy tuloksena olevaan iteroinnin laajuuteen. Kaikkia hoidettuja tehtäviä ei voida sisällyttää iteraatioon.

Sukellaan jokaiseen aiheeseen.

Teknisen velkakannan rakentaminen ja resurssien allokointisääntö

Helpoin tapa jokaiselle kehittäjälle rakentaa tekninen velkakanta on käyttää "To do" -tageja lähdekoodissa. Myöhemmin voit etsiä koodikannasta, parantaa jotain ja lähettää vetopyyntöjä hyväksyttäväksi. Mutta se ei riitä. Se ei auta tiimin jäseniä tekemään asianmukaista suunnittelua ja varmistamaan julkaisun laajuuden.

Parempi vaihtoehto "To Do" -käytölle on luoda prosessi tulevien muutosten tehtävien luomiseksi. Jos kehittäjä löytää mahdollisen ongelmakohdan tai hänellä on idea koodikannan parantamiseksi, hänen tulee luoda työkohde lippujärjestelmään (Jira, Azure DevOps tai mikä tahansa tiimin käyttämä järjestelmä). Olisi ylimielistä vaatia insinöörejä antamaan yksityiskohtainen kuvaus ideastaan jokaiselle tiimin jäsenelle, mutta selityksen tulee olla riittävän selkeä, jotta tiimijohto ymmärtää muutosten keskeisen kohdan ja laajuuden. Tämä kattaa ensimmäisen vaiheen - kuinka voimme luoda luettelon mahdollisista tehtävistä ja antaa korkean tason kuvauksen tulevista muutoksista.

Vaihe kaksi on tehdä siitä ymmärrettävä kaikille. Tämän tehtävän voi hoitaa kehittäjätiimin johtaja, julkaisupäällikkö tai tuotepäällikkö pätevyydestään riippuen. Tuloksen tulee sisältää seuraavat tiedot:

• Mitä me teemme? - Idean korkeatasoinen selitys.
• Miksi teemme näin? - Kuvaus siitä, kuinka nämä muutokset voisivat parantaa kehitysnopeutta, vähentää spagettikoodin aiheuttaman epävakauden riskiä tai parantaa ohjelmiston suorituskykyä.
• Kuinka tärkeitä nämä muutokset ovat tulevan kehityksen kannalta? - Muutosten prioriteetti. Esimerkiksi ilman näitä muutoksia tulevien parannusten tai liiketoimintaominaisuuksien kustannukset voivat kasvaa eksponentiaalisesti.
• Mitä riskejä nämä muutokset aiheuttavat? - Luettelo vaikutuksen alaisista ominaisuuksista tai moduuleista, jotka auttavat laadunvarmistusta vahvistamaan muutokset.

Jos työkohdassa on vastaukset kaikkiin näihin kysymyksiin, se auttaa lieventämään mahdollisia ongelmia tulevaisuudessa. Pelkkä ruuhka ei kuitenkaan riitä hallittavaan uudelleenjärjestelyyn. Sinun on suunniteltava mahdollisia muutoksia, ja niiden tulee olla jatkuva osa prosessiasi. Varmasti joudut kohtaamaan liiketoiminnan ominaisuuksien ja markkinoiden vaatimusten paineet, joissa houkutus jättää teknisiä tehtäviä on suuri. Mutta ilman asianmukaista huoltoa kohtaat vielä suurempia ongelmia tulevaisuudessa.

Suositus teknistä ruuhkaprosessia varten on:

1. Jokaisessa iteraatiossa tiimin on varattava aikaa teknisiin parannuksiin.

2. Jos parannusideoita on, se tulee muotoilla työkohteena asianmukaisella kuvauksella.

3. Työkohteiden tulee osallistua hoitoprosessiin, ja niistä on keskusteltava koko tiimin kesken, kunnes kaikki hyödyt ja riskit on tunnistettu ja kaikkien tiimin jäsenten arviot on kerätty.

4. Työkohteet suunnitellaan ketteriksi iteraatioiksi niiden arvioiden mukaan.

   
   

Ryhmälle tulee ilmoittaa mahdollisesta teknisistä veloista iteraatiossa. Varattua aikaa voidaan tarvittaessa pidentää, mutta se ei saa koskaan olla normaalia pienempi. Tämä auttaa insinöörejä luomaan uusia tehtäviä ruuhkassa ja priorisoimaan niitä. Kaikki tietävät, että heidän ehdotuksensa voidaan toteuttaa ja ruuhka pienenee jonain päivänä, ei kasva valtavaksi demoralisoivaksi listaksi.

Hoito- ja suunnitteluprosessien käyttäminen mahdollisten teknisten velkojen paljastamiseen

Joskus teknologiavelkatehtävät voivat paljastua keskustelun ja arvioinnin aikana, kun taas tiimi kohtasi odottamattomia esteitä, jotka tekivät realisoinnin vähemmän luotettavasta ja joustavasta. Saatat esimerkiksi huomata, että samankaltaisia ominaisuuksia on, ja aivan uuden luominen vain pahentaisi koodikantaa. Mutta nämä ominaisuudet eivät sisällä uusissa tarvittavia liiketoimintatoimintoja. Ja on parempi luoda yhtenäinen palvelu, joka yhdistää kaikki samankaltaiset ominaisuudet ylläpidon yksinkertaistamiseksi tulevaisuudessa. Tämä muutos voi kuitenkin vaikuttaa vanhoihin ominaisuuksiin ja horjuttaa niitä, ja siinä piilee haaste. Ehkä on olemassa tapa kehittää uusia ominaisuuksia halvalla ja sulkea silmät puutteilta. Tai ehkä juuri nyt on paras tilaisuus luoda yhtenäinen palvelu, vaikka samanlaisia ominaisuuksia on vain muutama. Tärkeintä on luoda prosessi, joka auttaa tiimin jäseniä tekemään päätöksen paljastuneiden tosiasioiden ja oikein hoidettujen arvioiden perusteella. On tärkeää, että käytössä on järjestelmä, joka estää tilanteet, joissa tällaisia päätöksiä pitäisi tehdä toteutusvaiheessa sitoutuneessa ruuhkassa.

Jos iterointivaiheesi toimivat hyvin, tällaisten hetkien paljastaminen tapahtuu automaattisesti asianmukaisen hoito- ja suunnitteluprosessin kautta. Useimmissa tapauksissa on olemassa muutamia perussääntöjä ja vaiheita, jotka voivat suojata joukkuetta odottamattomilta esteiltä:

1. Hoitotyöskentelyn tulee sisältää tehtäviä, joilla on selkeät ja toteuttamiskelpoiset vaatimukset.
2. Hoitotyöskentely tulee jakaa tiimin jäsenten kanssa ennen keskustelua ja arviota.
3. Kaikkien tiimin jäsenten tulee olla valmistautuneet ja perehtyneet tehtäviin ennen hoitoa.
4. Jos jokin ruuhka-aine vaatii lisätutkimusta tai uudelleentoteutusta, huolenaiheesta tulee keskustella.
5. Vaatimukset ongelmallisille tilauskohteille tulee viimeistellä paljastettujen erityispiirteiden perusteella. Kaikki mahdolliset ongelma-alueet tulee dokumentoida.
6. Jokainen ruuhkan erä tulee arvioida.

Ongelmalliset ruuhkakohdat voitaisiin jakaa erillisiin tehtäviin ja suunnitella prioriteettien mukaan. Päätökset toteutusstrategiasta voivat olla julkaisupäällikköllä riskien ja määräaikojen mukaan. Mutta tämä lähestymistapa auttaa dokumentoimaan kaikki päätökset. Vaikka teknologiavelkatehtävää lykättäisiin, se lisätään silti ruuhkaan. Myöhemmin nämä tehtävät tulee tarkistaa ja ajoittaa. Tämä prosessi korjaa skenaarioita, joissa hyvät ja tarpeelliset ideat unohtuvat hektisen iteroinnin aikana.

Prosessin luominen odottamattomien ongelmien varalta iteroinnin aikana

Silti, vaikka hyvin hoidettu tekninen velkakanta ja toimiva hoito- ja suunnitteluprosessi olisivat, on mahdollista törmätä odottamattomiin ja aikaa vieviin kehitystyön esteisiin. Ohjelmistotuotteet voivat olla monimutkaisia, varsinkin vanhoja tai sisältävät runsaasti toimintoja.

Kettereiden käytäntöjen käyttö auttaa keräämään tietoa ajoissa ja tekemään oikean päätöksen. Yksi helpoimmista ratkaisuista on päivittäiset kokoukset.

Jos insinööri kohtaa ongelman, se tulee tuoda esiin kokouksen aikana ja keskustella myöhemmin. Jokainen este on ainutlaatuinen ja voi viedä eri aikaa. Ei ole väliä, toteutetaanko muutos nykyisessä iteraatiossa "Nice to have" -ominaisuuden sijasta vai vaatiiko se iterointialueen täydellisen tarkistamisen. Ongelma tulisi luoda tyypilliseksi teknologiavelkatehtäväksi seurantajärjestelmässä, jakaa ja kuvata kuten mikä tahansa muu vastaava tehtävä aiemmissa artikkeleissa. Johdonmukaisuus on avain, ja tiimin on osattava käsitellä näitä tilanteita.

Lisäbyrokratian kritiikki ja siihen vastaaminen

Kaikki nämä menetelmät voivat tuntua lisätavolta viedä koko tiimin aika turhaan byrokratiaan. Ja se voi olla niin, jos vain tiukkojen ja selkeiden sääntöjen puuttuminen ei aiheuttaisi vaikeita aikoja kaikille. On OK olla noudattamatta näitä suosituksia lyhytaikaisissa projekteissa tai minimiarvotuotteen (MVP) vaiheessa. Tuotannossa työskentely laatuvastuulla ja suurilla tuotteilla vaatii kuitenkin tarkasti määritellyn sisäisen prosessijärjestelmän. Käydään läpi yleisimmät vastaväitteet.

Tällaisten tehtävien luominen on aikaa vievää ja joskus on nopeampaa tehdä muutoksia koodiin kuin kuvata niitä

Ja se on totta. Tehtävien kuvaaminen luonnollisella kielellä voi joskus olla vaikeampaa kuin koodin korjaaminen. Mutta tässä on joitain ratkaisuja:

• Mallijärjestelmän luominen lippujärjestelmään voi olla hyödyllistä. Sen avulla tehtäviä voidaan lisätä nopeasti ja täyttää oikeilla parametreilla ja linkeillä.
• On hienoa, että yrityswikissä on joitain lippukäytäntöjä, kuten Confluence / Notion / SharePoint tai mikä tahansa muu tiimin dokumentaatioalusta. Nämä sivut voivat tarjota hyviä esimerkkejä oikein luoduista tehtävistä. On työryhmän johtajan etujen mukaista ylläpitää teknistä dokumentaatiota ja hioa malleja, jotta muut tiimin jäsenet voivat lähettää selkeät ja ymmärrettävät liput.
• Perustasolla riittää, että insinöörit velvoitetaan luomaan korkean tason kuvauksia sisältäviä tehtäviä ilman laajoja artikkeleita strategisesta visiosta tai heidän ehdotustensa mahdollisuuksista. Kuvauksen tulee auttaa arvioijaa (yleensä tiiminvetäjää) saamaan pääkäsitys muutoksista. Myöhemmin tiimin johtaja voi vahvistaa ehdotuksen ja täyttää sen lisätiedoilla prosessin mukaisesti. Tämä auttaa myös ymmärtämään, ovatko nämä muutokset edes tarpeellisia, ja tarjoaa jonkin verran laatusuodatinta.
• Jos kehittäjällä on aikaa toteuttaa ehdotus, ominaisuushaarakäytännöstä voi olla paljon apua. Silti tehtävän luominen on välttämätöntä, koska on hyödyllistä saada sääntö lippujen nimeämien ominaisuushaarojen luomiseen. Mutta tuloksena saamme tyytyväisen insinöörin, joka on toteuttanut osan teknisistä veloista, lipuista ja linkitetystä toteutuksesta, joka voidaan hoitaa ja suunnitella todennettavaksi sopivassa iteraatiossa ilman odottamattoman epävakauden riskiä.

Kaikki nämä muutokset ovat erittäin teknisiä, eikä kuvaus auta, koska kukaan ei ymmärrä ideaa

Ehkä. Mutta se riippuu selityksestä. Prioriteetti on kuvaus siitä, mikä voi mennä pieleen ja mitkä toiminnot saattavat horjua. Muutoksen vaikutuksista on kuitenkin hyödyllistä kirjoittaa, koska se auttaa tunnistamaan lisämahdollisuuksia ja skenaarioita. Myös syvimmätkin tekniset ideat voitaisiin kuvata yksinkertaisilla lauseilla luonnollisella kielellä. Jos he eivät voi, itse ideassa voi olla jotain vikaa, ja se voi olla mahdollinen riski, koko ehdotusta on harkittava uudelleen.

Kirjoita vaikka jotain tällaista:

"Menetelmä "XXX" kuluttaa liikaa RAM-muistia jokaisessa puhelussa. Ylimääräisen välimuistin luominen tälle menetelmälle auttaa vähentämään RAM-muistin kulutusta ja nopeuttamaan kaikkia API:ita. Menetelmä käyttää harvoin muuttuvia tietoja, riittää, että pudotat välimuistin uudelleenkäynnistyksen yhteydessä. Muutokset ovat turvallisia, mutta saattavat vaikuttaa seuraaviin ominaisuuksiin: XXX, XXX, XXX…”.

Joissakin tapauksissa tämä riittäisi. Toisissa tämä ehdotus voi laukaista keskustelun, koska insinööri saattaa unohtaa vanhat mutta edelleen käytetyt toiminnot, joissa tämä välimuisti voi aiheuttaa ongelmia. Harjoitusprosessin aikana ideaa tarkistetaan ja tiimi löytää kompromissin.

Kaikki nämä käytännöt estävät vain käyttäjiä vastaanottamasta uusia parannuksia

Vakaus ja luotettavuus ovat parempia kuin muutaman prosentin parannukset joidenkin ominaisuuksien suoritusaikaan. Kukaan ei tule pettymään mahdollisen suorituskyvyn parantamisen puuttumisesta, mutta tuotteen maine on helppo pilata.

Tarvitsemmeko kaiken tämän byrokratian yksinkertaiseen koodityyliin, joka ei koskaan tee mitään haittaa 99,99 prosentissa tapauksista?

Ajatuksena on tehostaa prosesseja ja auttaa arvioimaan riskejä. Insinööreillä pitäisi olla mahdollisuus ylläpitää koodikantaa ja tehdä joitain parannuksia. Pienille asioille, jotka eivät horjuta koko tuotetta, on mahdollista luoda koottuja työkohteita, jotka voidaan suorittaa iteroinnin aikana. Nämä tehtävät on vielä tarkistettava vetopyyntöinä, mutta niitä ei tarvitse virallisesti ilmoittaa tiimille.

Johtopäätös

Jatkuvat tuoteparannukset ovat liiketoiminnan kannalta kriittisiä ja auttavat säilyttämään yleisen laadun. Jos pidät teknisen velan ja uudet ideat hyllyssä, juuttuu vanhentuneeseen tuotteeseen ja on pian vaikeuksia löytää asiantuntevia insinöörejä ylläpitämään sitä.

Toisaalta nämä tehtävät kilpailevat liiketoiminnan ominaisuuksien ja muiden ideoiden kanssa, jotka voivat viedä liiketoimintaa uusiin horisonteihin. Nämä teknisten tehtävien ruuhkaa koskevat suositukset voivat auttaa paljastamaan ja arvioimaan näiden tehtävien tärkeyttä paitsi tiimin jäsenille myös sidosryhmille. Ne auttavat esittämään nämä ideat luonnollisella kielellä ja säilyttävät ja suojaavat toteutusaikaa. Se kuormittaa insinöörejä lisätoimilla, mutta lopulta se auttaa koko tiimiä toimittamaan korkealaatuisia ja luotettavia tuotteita. Ja johtajan vastuulla on valita oikea väline tai käytäntö tämän prosessin ylläpitämiseksi.