Vi kan hevde at mye av fremgangen som har blitt gjort nylig i programvareindustrien, skyldtes en kamp for å imøtekomme to tilsynelatende motstridende mål: hastighet og kvalitet. For å forbli konkurransedyktige, må bedrifter levere kvalitet til kundene sine med intervaller som stadig blir kortere.
Det nytter imidlertid ikke å sende programvare raskt hvis du sender ødelagt programvare.
Så hvordan kan organisasjoner ta i bruk effektive kvalitetstiltak uten å bremse programvareleveringsprosessen?
Svaret var, kanskje ikke overraskende, automatisering. Som i bruken av automatisering for å forbedre selve programvareutviklingsprosessen. I dag dekker vi ett spesifikt aspekt ved dette:kvalitetsporter.
Kvalitetsporter er verifikasjoner du kan sette på tvers av programvareutviklingspipelinen din for å forhindre at kode beveger seg videre hvis den ikke oppfyller de angitte kvalitetskriteriene. Hvis den analyserte koden er OK, kan den fortsette til den når neste port. På den annen side, hvis det ikke ser så bra ut, stopper det der.
Det er mer enn det, skjønt.
- Hva er fordelene med å ta i bruk kvalitetsporter?
- Hvordan forhindrer faktisk kvalitetsporter at feil kode beveger seg fremover?
- Hva er noen eksempler på ekte kvalitetsporter?
For å lære svaret på disse og flere spørsmål, fortsett å lese.
Hva er en kvalitetsport i programvareutvikling?
Som du har sett, har vi allerede gitt en enkel definisjon av kvalitetsporter. Men nå skal vi gå litt dypere.
Du vil se at definisjonen av "kvalitetsport" faktisk kan være todelt. For det første kan du ha en generell definisjon av kvalitetsport, litt mer abstrakt og subjektiv. På den annen side har du de mer konkrete og objektive kvalitetsportene, som implementeres av ulike verktøy.
La oss nå se forskjellene mellom disse to.
Kvalitetsporter som i "Beste fremgangsmåter"
Du kan tenke på kvalitetsporter som kvalitetskontrollpunkter i hver programvareprosjektfase. Hver gang prosjektet er i ferd med å nå en viktig milepæl, kan det være lurt å pause og verifisere om det nåværende resultatet oppfyller de forventede standardene.
Hver gang prosjektet når en port, skal det vurderes opp mot de definerte kvalitetskriteriene. Den får da en status, som kan være et binært alternativ (enten det bestått eller mislyktes) eller et mer nyansert alternativ (f.eks. suksess/fiasko/advarsel).
De spesifikke kriteriene som brukes vil selvfølgelig variere avhengig av en rekke faktorer, som typen produkt eller tjeneste som er under utvikling, størrelsen og arten av organisasjonen, med mer.
For eksempel, du vet det sikkertnoen felt er sterkt regulert—økonomi og helsevesen er eksemplene som dukker opp. Det er fornuftig at programvareprosjekter for disse bransjene har kvalitetsporter som kreves for mange juridiske aspekter. Prosjekter som ikke er like kritiske eller regulerte kan ha færre kvalitetsporter, slik at de kan få produktene eller tjenestene sine raskere i hendene på kundene.
Hvordan fungerer denne typen kvalitetsport?
Igjen, det varierer. Du kan ha alt fra mer uformelle tilnærminger til en svært rigid sjekkliste som krever sign-offs fra de ansvarlige interessentene ved hver kvalitetsport.
Kvalitetsporter som i "Automatiske kontroller"
Som du har sett, er den forrige versjonen av en kvalitetsport noe subjektiv i sin definisjon og for det meste manuell i sin applikasjon. Dessuten er det mer anvendelig på prosjektnivå.
Nå skal vi dekke kvalitetsporter i betydningen automatiske verifikasjoner utført på koden. I motsetning til den forrige, er denne definisjonen av kvalitetsport objektiv, automatisert og brukes vanligvis på kodenivå.
Så i denne sammenhengen er en kvalitetsport en automatisert verifisering du kan bruke til å håndheve overholdelse av en eller flere kvalitetsstandarder. I likhet med den forrige typen kvalitetsport, bevarer også denne metaforen. Tenk på det som en faktisk port som hindrer koden i å gå videre i programvareutviklingslivssyklusen (SDLC) hvis den ikke oppfyller de definerte kvalitetskriteriene.
OK, men hva skjer egentlig når koden blir blokkert av en kvalitetsport?
Igjen, det kommer an på. Ting kan variere avhengig av verktøyet og konfigurasjonen. Alt annet likt, minimum du bør sikte på er en varsling, enten via e-post eller meldingsapper – f.eks.Slakkeller liknende.
Du kan for eksempel integrere kvalitetsporter i pull request-prosessen (PR). Hver gang en ingeniør sender inn en pull-forespørsel, blir koden deres sjekket mot de definerte kvalitetsportene.
For eksempel kan være PR-størrelse. Hvis teamet etablerer et mål om at PR ikke skal være mer enn 225 endringer,WorkerB-boten vår kan advare teamet når en PR er for stor.Anmelderen kan deretter bestemme om den skal slås sammen eller ikke.
Et annet alternativ kan være implementering av kvalitetsporter for grunnleggende anmeldelser. Overfladisk "ser bra ut for meg" kan anmeldelser tillate dårlig kode å slippe gjennom sprekkene. WorkerB-boten vår kan advare teamet ditt når en overfladisk anmeldelse er i ferd med å bli slått sammen eller har blitt slått sammen, slik at du kan tildele et ekstra sett med øyne for å se etter kvalitetsproblemer.
Vil du ha en mer radikal, men også mer garantert måte å forhindre at kode som svikter kvalitetsporter når produksjonen? Vel, i så fall vil du sannsynligvis konfigurere dinCI/CD(kontinuerlig integrasjon / kontinuerlig distribusjon) programvare slik at byggingen mislykkes når koden ikke passerer portene.
Kvalitetsporter: Her er noen virkelige eksempler
Før vi avslutter, viser vi noen eksempler på kriterier for ekte kvalitetsporter, samlet fra ulike verktøy. På den måten får du en reell følelse av hvordan en automatisert kvalitetsportprosess ser ut og hvilken type tilbakemelding den kan gi deg.
- Kodedekning:Prosentandelen av kode som dekkes av automatiserte enhetstester.
- Filialdekning:En mer spesifikk versjon av kodedekning som måler prosentandelen av utførelsesbaner som dekkes av tester.
- Kodedekning på ny kode:Det samme som det første eksemplet, men kun rettet mot ny kode.
- Kode churn:Hvor raskt og ofte koden skrives om, noe som kan være et rødt flagg på forskjellige måter.
- Antall blokkeringsproblemer:Antall kritiske problemer i koden.
- Avhengighet eller arkitektoniske regler brutt: Du kan ha arkitektoniske begrensninger på koden din – for eksempel klasser fra “Domene”-modulen kan ikke referere til “Presentasjon”-modulen – og det kan være verdifullt å sikre at disse ikke blir ødelagt.
Lukk døren for enkle beregninger …
Den nåværende tidsånden i programvareindustrien er at du må gå fort. Jo før – og oftere – du leverer verdi til kunden, jo bedre. Mens du gjør det, må du imidlertid holde kvaliteten høy. Du må iverksette tiltak for å kontrollere kvaliteten på programvareutdataene dine for å forhindre forsendelse av kode som ikke oppfyller standardene.
Ved første øyekast kan det se ut som om de to målene er motstridende, men det er de ikke. Gjennom de kombinerte kreftene av metoder, prosesser og verktøy, har den moderne programvareutviklingsindustrien oppnådd den bemerkelsesverdige bragden å la team gå fort uten å ødelegge ting.
I dette innlegget har vi dekket en av brikkene i puslespillet som gjør dette mulig: kvalitetsporter. Du har lært definisjonene av kvalitetsporter, hvorfor du ønsker å bruke dem, hvordan de fungerer, og til og med noen virkelige eksempler.
Til slutt er det viktig å huske på at når det gjeldertekniske beregninger-kvalitetsporter og annet - du må sørge forskuddet gir ikke tilbakeslag. Beregninger kan spilles, spesielt når de anses ute av kontekst og brukes som et mål. Så hvordan sikrer du at det ikke skjer med utviklerteamet ditt?
... Og åpne portene til programvarekvalitet
Vårt råd er å sikte mot det store bildet. Ikke vurder beregninger isolert.
Vurder heller å ta i bruk verktøy som kan korrelere beregninger fra ulike kilder, for eksempel depotet ditt og prosjektstyringsprogramvaren din. På den måten kan du få et mer generelt syn på helsen til prosjektet og utviklerteamet ditt. Du kan kanskje oppdage ogredusere prosjektrisiko. Og det vil du definitivtlærei prosessen.
For eksempel er LinearB et verktøy som kan samle inn og korrelere beregninger fra både lagrene dine og prosjektstyringsprogramvare, for eksempel Jira. Som et resultat får du en svært nøyaktig oversikt over den nåværende tilstanden til lagene dine:
På bildet over, hentet fra LinearBs dashbord, kan du se at teammedlemmet Joanna har for mange aktive oppgaver og har jobbet 9 av de siste 10 dagene. Etter å ha lært det, kunne teamlederen bestemme seg for å dele arbeidet mer jevnt mellom de andre teammedlemmene. Selv om en slik beregning kanskje ikke passer til definisjonen av kodekvalitet, er det absolutt en verdifull måling en teamleder kan bruke for å forbedre kvalitetsstyringen og helsen til applikasjonene sine.
Bildet over er også fra LinearBs dashbord. Det viser en viktig beregning – omarbeid, også kjentkode churn– på tvers av iterasjoner. En slik rapport er et godt eksempel på LinearB-funksjoner. Den bringer datalager og prosjektledelse sammen. Og som et resultat gir det brukeren en visning på høyt nivå som absolutt kan fungere som en kvalitetsport.
Vi inviterer deg tilbestill en demo av LinearB. Takk for at du leste.