Programmering

7 viktige kodingsrutiner for smidige utviklere

Agil programvareutvikling handler ikke bare om smidige prinsipper og praksis. For å lykkes med å gi ut programvare som positivt påvirker sluttbrukere, adresserer teknisk gjeld og distribuerer pålitelig, må utviklingsteamet også vurdere deres smidighetskjørende kodingspraksis og arkitekturstandarder.

Et enda viktigere hensyn står på spill for teknologiorganisasjoner. Så vanskelig som det er å utvikle programvare, er det enda vanskeligere å distribuere forbedringer og oppgraderinger regelmessig over en lengre periode. Devops CI / CD og IAC (infrastruktur som kode) behandler delvis en kritisk faktor ettersom automatiseringen muliggjør pålitelige og repeterbare måter å distribuere applikasjoner på. Legg til kontinuerlig testing, og utviklingsteam har en måte å validere at kodeendringer ikke påvirker eksisterende funksjonalitet.

Imidlertid, når applikasjoner blir eldre, går de originale utviklerne videre til andre prosjekter og noen ganger andre selskaper. Når nye utviklere blir med på teamet, må de lære programvarens arkitektur og forstå koden før de kan endre den pålitelig og effektivt.

Videre ønsker utviklere som bygger applikasjoner ofte å utvikle nye. Det kan føles behagelig og trygt å holde seg knyttet til applikasjonene du utvikler, men å være bundet til koden din er ikke sunt for karrieren din eller organisasjonen.

Den beste måten å gå videre til nye og spennende programvareutviklingsinitiativer er å gjøre arkitekturen, applikasjonen og koden din lett støttet av andre utviklere. Agile team og utviklere må etablere og håndheve kodingspraksis som opprettholder løpende programvareutvikling.

1. Ikke finn opp hjulet på nytt

Den første koden for koding: Ikke kod noe som ikke trenger å kodes! Hvordan?

  • Vurder å stille spørsmål om kravene. Hvorfor er en funksjon viktig? Hvem har fordeler? Mer spesifikt, utforsk alternativer uten koding for å løse problemet. Noen ganger er den beste løsningen ingen løsning i det hele tatt.
  • Har noen i organisasjonen din allerede kodet en lignende løsning? Kanskje det er en mikroservice som bare trenger en forbedring eller et programvarebibliotek som trenger en mindre oppgradering? Husk å se gjennom organisasjonens kodebase før du koder noe nytt.
  • Finnes det tredjepartsløsninger, inkludert rimelige SaaS-verktøy eller alternativer for åpen kildekode, som oppfyller minimale krav?
  • Har du sett på åpne kodingsregister som GitHub for kodeeksempler og utdrag som oppfyller organisasjonens samsvarskrav?

2. Vurder utviklingsalternativer med lav kode

Hvis du trenger å kode en løsning, kan kanskje alternative plattformer med lav kode gjøre det mulig å utvikle funksjonene mer effektivt sammenlignet med koding i utviklingsspråk som Java, .Net, PHP og JavaScript.

Plattformer med lav kode som Caspio, Quick Base, Appian, OutSystems og Vantiq gir alle verktøy for å utvikle applikasjoner med lite kode og noen ganger til og med uten koding i det hele tatt. Hver plattform spesialiserer seg på forskjellige funksjoner og er dermed egnet for en bestemt klasse applikasjoner. Caspio, for eksempel, gjør det enkelt å bygge inn skjemaer og arbeidsflyter på nettsteder. Quick Base har robuste arbeidsflyt- og automatiseringsfunksjoner, og Vantiqs hendelsesdrevne arkitektur er egnet for IoT og andre sanntids dataprogrammer.

Det er tider det kreves koding, men utviklere bør også være dyktige i ett eller flere utviklingsalternativer med lav kode og vurdere dem for passende brukstilfeller.

3. Automatiser testing

Utover å skrive kode som oppfyller kravene, er en av de viktigste tingene utviklere trenger å gjøre, å teste den. Testdrevet utviklingspraksis og automatiserte testverktøy har modnet, og utviklingsteam bør inkludere enhet-, regresjons-, ytelses- og sikkerhetstesting som en del av sine smidige estimater.

I tillegg til å ha tester for å validere bygg og utgivelser, hjelper disse testene også til å gjøre koden mer støttbar. Tester er dokumentasjon og etablerer en kontrakt om hvordan koden skal oppføre seg. Når nye utviklere blir med på team og utilsiktet implementerer en dårlig endring, stopper kontinuerlig testing bygningen og gir meningsfull tilbakemelding til utvikleren for raskt å løse problemet.

4. Eksternaliser alle konfigurasjonsparametere

Det bør ikke være noen unnskyldning for utviklere for å hardt innstille koden på systemnivå, brukernavn og passord eller annen konfigurasjonsinformasjon i koden. Jeg har sett utviklere ta snarveier mens de utvikler prototyper som finner veien inn i produksjonsmiljøer. I dagens arkitekturer skal dette aldri gjøres. Hard koding er ikke teknisk gjeld, men en lat, uansvarlig koding som kan ha betydelige konsekvenser. Hvis koden ved et uhell blir tilgjengelig, skaper den et sikkerhetsproblem hvis endepunkter eller tilgangsinformasjon blir eksponert.

Å gå et skritt videre, når det arbeides med eldre koder, bør adressering av hardkodede konfigurasjoner og parametere være en ikke omsettelig teknisk gjeldsprioritet.

5. Følg navnekonvensjonene og inkluder kommentarer for å gjøre koden lesbar

Jeg jobbet en gang med en utrolig talentfull utvikler som ikke kunne engelsk godt og ikke var den beste skriveren. Han ville instantiere objekter med navn som en, b, og c og opprett deretter lokale variabler som heter zz, yy, xx. Han forpliktet seg til å rydde opp i dette før løslatelsen, men fulgte sjelden gjennom.

Du trenger ikke å ha par eller mob programmering for å innse at dette er en forferdelig praksis.

Teamene bør vedta navngivningskonvensjoner som Googles JavaScript Style Guide og Java Style Guide og forplikte seg til å kommentere kode i det minste på modulnivå og ideelt på klassenivå. I tillegg bør organisasjoner vurdere å bruke verktøy for statisk kodeanalyse som gir tilbakemeldinger til utviklere når koden trenger omforming for struktur og lesbarhetsfaktorer.

6. Sjekk koden ofte i versjonskontrollen

Hvis du ikke sjekker kode i versjonskontroll daglig eller hyppigere, kan det skape konflikter og andre blokker som påvirker teamet. En liten feil kan føre til at smidige team går glipp av sine sprintforpliktelser eller skaper ekstra arbeid for å løse avhengigheter.

Lagene bør bli enige om konvensjoner for å sjekke inn koden som ikke er klar for produksjon. Konvensjonelle tilnærminger inkluderer funksjonflagg og Git-forgrening.

7. Unngå koding av heroikk og kompleksitet

De fleste utviklere jeg kjenner ble profesjonelle programvareingeniører fordi de elsker å løse kodingsutfordringer. Koding er en kunst, vitenskap og håndverk, og bedre utviklere søker tankevekkende kodingsoppgaver og elegante implementeringer.

Med unntak av at det er en grå linje mellom å løse utfordrende forretnings- og tekniske oppgaver kontra kodende heroics, som gir de neste utviklerne kode som er vanskelig å forstå og komplisert å vedlikeholde.

For de av oss som har kodet en stund, husker vi fordelene med Perl one-liners eller bruk av nestede maler i C ++. Noen ganger er det gode grunner til å bruke disse tilnærmingene, men hvis en ny gruppe utviklere ikke forstår disse teknikkene, er det mer utfordrende å endre koden. Noen ganger er enkle, men mindre elegante kodingsmetoder bedre.

Kjører smidighet i smidig programvareutvikling

Ritualene innebygd i scrum og smidig utvikling, inkludert forpliktelser, standups, sprintanmeldelser og tilbakeblikk er nå bevist praksis for å muliggjøre teamsamarbeid og drive vellykket implementering. Men for å demonstrere smidighet over lang tid, må utviklere påta seg ansvar og kodingspraksis som muliggjør langsiktig støtte og utvidbarhet av koden de utvikler.

Utviklingsteamene må ha et kritisk syn på kodingspraksis. Det er ikke bare bra nok til å demo og slippe i dag; Det er også viktig å gjøre det mulig for andre å enkelt vedlikeholde applikasjonen og koden.

$config[zx-auto] not found$config[zx-overlay] not found