Programmering

7 vigtige kodningsmetoder for agile udviklere

Agil softwareudvikling handler ikke kun om agile principper og praksis. For at få succes med at frigive software, der positivt påvirker slutbrugere, adresserer teknisk gæld og implementeres pålideligt, skal udviklingsteamet også overveje deres agility-drivende kodningspraksis og arkitekturstandarder.

En endnu vigtigere overvejelse står på spil for teknologiorganisationer. Så svært som det er at udvikle software, er det endnu sværere at implementere forbedringer og opgraderinger regelmæssigt over en længere periode. Devops CI / CD og IAC (infrastruktur som kode) behandler delvist en kritisk faktor, da automatiseringen muliggør pålidelige og gentagelige måder at implementere applikationer på. Tilføj kontinuerlig test, og udviklingsteams har en måde at validere, at kodeændringer ikke påvirker eksisterende funktionalitet.

Da applikationer bliver ældre, går de originale udviklere imidlertid videre til andre projekter og nogle gange andre virksomheder. Når nye udviklere slutter sig til teamet, skal de lære softwarets arkitektur og forstå koden, før de pålideligt og effektivt kan ændre den.

Desuden ønsker udviklere, der bygger applikationer, ofte at udvikle nye. Det kan føles behageligt og sikkert at være knyttet til de applikationer, du udvikler, men at være bundet til din kode er ikke sundt for din karriere eller organisationen.

Den bedste måde at gå videre til nye og spændende softwareudviklingsinitiativer er at gøre din arkitektur, applikation og kode let understøttet af andre udviklere. Agile teams og udviklere skal etablere og håndhæve kodningspraksis, der opretholder løbende softwareudvikling.

1. Genopfind ikke hjulet igen

Den første regel for kodning: Kod ikke noget, der ikke behøver at blive kodet! Hvordan?

  • Overvej at stille spørgsmål om kravene. Hvorfor er en funktion vigtig? Hvem drager fordel? Mere specifikt, udforsk ikke-kodende muligheder for at løse problemet. Nogle gange er den bedste løsning slet ingen løsning.
  • Har nogen i din organisation allerede kodet en lignende løsning? Måske er der en mikroservice, der bare har brug for en forbedring eller et softwarebibliotek, der har brug for en mindre opgradering? Sørg for at gennemse din organisations kodebase, før du koder noget nyt.
  • Er der tredjepartsløsninger, herunder SaaS-værktøjer til overkommelige priser eller optioner med open source, der opfylder minimale krav?
  • Har du kigget på åbne kodningsopbevaringssteder som GitHub for kodeeksempler og uddrag, der opfylder din organisations overholdelseskrav?

2. Overvej udviklingsmuligheder med lav kode

Hvis du har brug for at kode en løsning, kan alternative lavkodeplatforme muligvis muliggøre udvikling af funktionerne mere effektivt sammenlignet med kodning på udviklingssprog som Java, .Net, PHP og JavaScript.

Lavkodeplatforme som Caspio, Quick Base, Appian, OutSystems og Vantiq giver alle værktøjer til at udvikle applikationer med lidt kode og undertiden endda uden kodning overhovedet. Hver platform har specialiseret sig i forskellige muligheder og er således velegnet til en bestemt klasse af applikationer. Caspio gør det f.eks. Nemt at integrere formularer og arbejdsgange på websteder. Quick Base har robuste workflow- og automatiseringsfunktioner, og Vantiqs hændelsesstyrede arkitektur er velegnet til IoT og andre realtidsdataprogrammer.

Der er tidspunkter, hvor kodning er påkrævet, men udviklere bør også være dygtige i en eller flere udviklingsmuligheder med lav kode og overveje dem for passende brugssager.

3. Automatiser test

Ud over at skrive kode, der opfylder kravene, er en af ​​de vigtigste ting, som udviklere skal gøre, at teste den. Test-drevet udviklingspraksis og automatiserede testværktøjer er modnet, og udviklingsteam skal inkludere enhed, regression, ydeevne og sikkerhedstest som en del af deres agile estimater.

Ud over at have tests til validering af builds og releases, hjælper disse tests også med at gøre koden mere understøttet. Test er dokumentation og opretter en kontrakt om, hvordan koden skal opføre sig. Når nye udviklere slutter sig til teams og uforvarende implementerer en dårlig ændring, stopper kontinuerlig test build og giver meningsfuld feedback til udvikleren for hurtigt at løse problemet.

4. Eksterniser alle konfigurationsparametre

Der burde ikke være nogen undskyldning for udviklere til altid at kode indstillinger på systemniveau, brugernavne og adgangskoder eller anden konfigurationsinformation i koden. Jeg har set udviklere tage genveje, mens de udvikler prototyper, der finder vej ind i produktionsmiljøer. I dagens arkitekturer skal dette aldrig gøres. Hård kodning er ikke teknisk gæld, men en doven, uansvarlig kodning, der kan have betydelige konsekvenser. Hvis kode ved et uheld bliver tilgængelig, skaber den en sikkerhedssårbarhed, hvis slutpunkter eller adgangsoplysninger udsættes.

Gå et skridt videre, når der arbejdes med ældre kode, skal adressering af hårdkodede konfigurationer og parametre være en ikke-omsættelig teknisk gældsprioritet.

5. Følg navngivningskonventioner og medtag kommentarer for at gøre koden læsbar

Jeg arbejdede engang med en utrolig talentfuld udvikler, der ikke kendte engelsk godt og ikke var den bedste typist. Han ville instantiere objekter med navne som -en, b, og c og derefter oprette lokale variabler navngivet zz, yy, xx. Han forpligtede sig til at rydde op inden frigivelsen, men fulgte sjældent igennem.

Du behøver ikke at have par eller mob programmering oprettet for at erkende dette er en frygtelig praksis.

Hold bør vedtage navngivningskonventioner såsom Googles JavaScript Style Guide og Java Style Guide og forpligte sig til at kommentere kode i det mindste på modulniveau og ideelt på klasseniveau. Derudover bør organisationer overveje at bruge statiske kodeanalyseværktøjer, der giver feedback til udviklere, når kode skal refaktoriseres for struktur og læsbarhedsfaktorer.

6. Kontroller koden ofte i versionskontrol

Hvis du ikke kontrollerer kode i versionskontrol dagligt eller hyppigere, kan det skabe konflikter og andre blokke, der påvirker teamet. En lille fejl kan få agile teams til at gå glip af deres sprintforpligtelser eller skabe yderligere arbejde for at løse afhængigheder.

Hold bør være enige om konventioner til kontrol af kode, der ikke er klar til produktion. Konventionelle tilgange inkluderer funktionsflag og Git-forgrening.

7. Undgå kodning af heroik og kompleksitet

De fleste udviklere, jeg kender, blev professionelle softwareingeniører, fordi de elsker at løse kodningsudfordringer. Kodning er en kunst, videnskab og håndværk, og bedre udviklere søger tankevækkende kodningsopgaver og elegante implementeringer.

Bortset fra at der er en grå linje mellem at løse udfordrende forretnings- og tekniske opgaver versus kodende heroics, der efterlader de næste udviklere med kode, der er svær at forstå og kompliceret at vedligeholde.

For dem af os, der har kodet noget tid, husker vi bekvemmeligheden ved Perl one-liners eller ved hjælp af indlejrede skabeloner i C ++. Nogle gange er der gode grunde til at bruge disse tilgange, men hvis en ny gruppe udviklere ikke forstår disse teknikker, er det mere udfordrende at ændre koden. Nogle gange er enkle, men mindre elegante kodningsmetoder bedre.

Kører agility i agil softwareudvikling

Ritualerne indlejret i scrum og agil udvikling, herunder forpligtelser, standups, sprintanmeldelser og retrospektiver er nu bevist praksis for at muliggøre teamsamarbejde og drive en succesfuld implementering. Men for at demonstrere smidighed over lang tid skal udviklere påtage sig ansvar og kodningspraksis, der muliggør langsigtet support og udvidelse af den kode, de udvikler.

Udviklingsteam skal have et kritisk syn på deres kodningspraksis. Det er ikke bare godt nok til demo og frigivelse i dag; det er også afgørende at sætte andre i stand til let at vedligeholde applikationen og koden.