Pri agilnem razvoju programske opreme ne gre le za agilna načela in prakse. Da bi bila uspešna pri izdaji programske opreme, ki pozitivno vpliva na končne uporabnike, odpravlja tehnični dolg in se zanesljivo razporedi, mora razvojna skupina upoštevati tudi njihove prakse kodiranja, ki spodbujajo gibčnost, in arhitekturne standarde.
Še pomembnejši vidik je na kocki za tehnološke organizacije. Ne glede na to, kako težko je razviti programsko opremo, je še težje redno uvajati izboljšave in nadgradnje v daljšem obdobju. Devops CI / CD in IAC (infrastruktura kot koda) delno obravnavajo en ključni dejavnik, saj avtomatizacija omogoča zanesljive in ponovljive načine za uvajanje aplikacij. Dodajte neprekinjeno testiranje in razvojne skupine bodo lahko potrdile, da spremembe kode ne vplivajo na obstoječe funkcije.
Ko pa se aplikacije starajo, prvotni razvijalci preidejo na druge projekte in včasih na druga podjetja. Ko se novi razvijalci pridružijo ekipi, se morajo naučiti arhitekture programske opreme in razumeti kodo, preden jo lahko zanesljivo in učinkovito spremenijo.
Poleg tega razvijalci, ki gradijo aplikacije, pogosto želijo razviti nove. Morda se počutite udobno in varno, če ostanete povezani z aplikacijami, ki jih razvijate, vendar privezovanje kode ni zdravo za vašo kariero ali organizacijo.
Najboljši način za prehod na nove in vznemirljive pobude za razvoj programske opreme je, da drugi razvijalci preprosto podpirajo vašo arhitekturo, aplikacijo in kodo. Agilne ekipe in razvijalci morajo vzpostaviti in uveljaviti prakse kodiranja, ki podpirajo stalen razvoj programske opreme.
1. Ne izumljajte kolesa
Prvo pravilo kodiranja: Ne kodirajte nečesa, česar ni treba kodirati! Kako?
- Postavite vprašanja o zahtevah. Zakaj je funkcija pomembna? Kdo ima koristi? Natančneje, raziskati nekodiranje možnosti za rešitev težave. Včasih najboljša rešitev sploh ni nobene rešitve.
- Je nekdo v vaši organizaciji že kodiral podobno rešitev? Morda obstaja mikroservis, ki potrebuje samo izboljšavo ali knjižnico programske opreme, ki potrebuje manjšo nadgradnjo? Pred kodiranjem nečesa novega preglejte osnovno kodo organizacije.
- Ali obstajajo rešitve tretjih oseb, vključno s cenovno ugodnimi orodji SaaS ali odprtokodnimi možnostmi, ki izpolnjujejo minimalne zahteve?
- Ste si ogledali odprte repozitorije kodiranja, kot je GitHub, kjer najdete primere kode in delčke, ki ustrezajo zahtevam skladnosti vaše organizacije?
2. Razmislite o možnostih razvoja z nizko kodo
Če morate kodirati rešitev, potem morda alternativne platforme z nizko kodo omogočajo učinkovitejši razvoj zmogljivosti v primerjavi s kodiranjem v razvojnih jezikih, kot so Java, .Net, PHP in JavaScript.
Platforme z nizko kodo, kot so Caspio, Quick Base, Appian, OutSystems in Vantiq, ponujajo orodja za razvoj aplikacij z malo kode in včasih celo brez kodiranja. Vsaka platforma je specializirana za različne zmogljivosti in je tako primerna za določen razred aplikacij. Caspio na primer olajša vdelavo obrazcev in delovnih tokov v spletna mesta. Quick Base ima zmogljive zmogljivosti za potek dela in avtomatizacijo, Vantiqova arhitektura, ki jo vodijo dogodki, pa je primerna za IoT in druge podatkovne aplikacije v realnem času.
Včasih je potrebno kodiranje, vendar bi morali razvijalci obvladati eno ali več razvojnih možnosti z nizko kodo in jih upoštevati za primerne primere uporabe.
3. Avtomatizirajte testiranje
Poleg pisanja kode, ki izpolnjuje zahteve, je ena najpomembnejših stvari, ki jo morajo razvijalci narediti, to, da jo preizkusijo. Testno usmerjene razvojne prakse in avtomatizirana orodja za testiranje so dozorele, razvojne skupine pa bi morale vključiti enotno, regresijsko, zmogljivo in varnostno testiranje kot del svojih gibčnih ocen.
Poleg preskusov za preverjanje zgradb in izdaj, ti preskusi pomagajo tudi k večji podpornosti kode. Testi so dokumentacija in sklepajo pogodbo o tem, kako naj bi se koda obnašala. Ko se novi razvijalci pridružijo skupinam in nenamerno izvedejo slabo spremembo, neprekinjeno testiranje ustavi gradnjo in razvijalcu zagotovi pomembne povratne informacije, da lahko hitro reši težavo.
4. Zunanjost vseh konfiguracijskih parametrov
Razvijalcem ne sme biti izgovora, da bi v kodi vedno kodirali nastavitve na ravni sistema, uporabniška imena in gesla ali druge informacije o konfiguraciji. Videl sem, da razvijalci uporabljajo bližnjice pri razvoju prototipov, ki se znajdejo v proizvodnih okoljih. V današnjih arhitekturah tega nikoli ne bi smeli početi. Trdo kodiranje ni tehnični dolg, temveč lena in neodgovorna praksa kodiranja, ki ima lahko pomembne posledice. Če koda postane nenamerno dostopna, ustvari varnostno ranljivost, če so izpostavljene končne točke ali poverilnice za dostop.
Ko gremo še za korak naprej, ko delamo s staro kodo, bi moralo biti obravnavanje kakršnih koli trdo kodiranih konfiguracij in parametrov prednostna tehnična dolžnost, o kateri se ni mogoče pogajati.
5. Upoštevajte pravila o poimenovanju in vključite komentarje, da bo koda berljiva
Nekoč sem sodeloval z neverjetno nadarjenim razvijalcem, ki angleščine ni dobro poznal in ni bil najboljši daktilograf. Primere bi ustvaril z imeni kot a, b, in c in nato ustvarite imenovane lokalne spremenljivke zz, yy, xx. Založil bi se, da bo to očistil pred izpustom, vendar je redko nadaljeval.
Ne bi vam bilo treba uvesti programiranja za pare ali mafije, da bi prepoznali, da je to strašna praksa.
Skupine bi morale sprejeti konvencije o poimenovanju, kot sta Googlov vodnik po slogu JavaScript in Java Style Guide, in se zavezati, da bodo komentirale kodo vsaj na modularni ravni in najbolje na ravni razreda. Poleg tega bi morale organizacije razmisliti o uporabi orodij za statično analizo kode, ki razvijalcem nudijo povratne informacije, kadar je treba kodo preoblikovati za strukturo in dejavnike berljivosti.
6. Pogosto preverjajte kodo v nadzoru različic
Če kode v nadzor različic ne preverjate vsak dan ali pogosteje, lahko ustvari konflikte in druge blokade, ki vplivajo na ekipo. Ena majhna napaka lahko povzroči, da gibčne ekipe zamudijo svoje sprinterske obveznosti ali ustvarijo dodatno delo za reševanje odvisnosti.
Skupine se morajo dogovoriti o pravilih za preverjanje kode, ki ni pripravljena za proizvodnjo. Konvencionalni pristopi vključujejo funkcijske zastave in razvejanje Git.
7. Izogibajte se kodiranju junaštva in zapletenosti
Večina razvijalcev, ki jih poznam, so postali profesionalni inženirji programske opreme, ker radi rešujejo izzive kodiranja. Kodiranje je umetnost, znanost in obrt, boljši razvijalci pa iščejo naloge kodiranja, ki spodbujajo razmišljanje, in elegantne izvedbe.
Le da obstaja siva črta med reševanjem zahtevnih poslovnih in tehničnih nalog v primerjavi s kodiranjem junaštva, ki naslednjim razvijalcem pusti kodo, ki je težko razumljiva in zapletena za vzdrževanje.
Za tiste, ki že nekaj časa kodiramo, se spomnimo priročnosti enobarvnih povezav Perl ali uporabe ugnezdenih predlog v jeziku C ++. Včasih obstajajo tehtni razlogi za uporabo teh pristopov, če pa nova skupina razvijalcev teh tehnik ne razume, je zahtevnejša sprememba kode. Včasih so boljše preproste, a manj elegantne prakse kodiranja.
Spodbujanje gibčnosti pri agilnem razvoju programske opreme
Rituali, ki so vključeni v prepir in gibčen razvoj, vključno z zavezami, uvrstitvami, pregledom sprintov in retrospektivami, so zdaj preizkušene prakse, ki omogočajo skupinsko sodelovanje in spodbujajo uspešno izvedbo. Toda za dolgoročno dokazovanje gibčnosti morajo razvijalci prevzeti odgovornosti in prakse kodiranja, ki omogočajo dolgoročnejšo podporo in razširljivost kode, ki jo razvijejo.
Razvojne skupine morajo kritično gledati na svoje kodiranje. Danes ni dovolj dober za predstavitev in izdajo; Prav tako je ključno, da drugim omogočite enostavno vzdrževanje aplikacije in kode.
