Refactoring vs. YAGNI

Når man introducerer scrum eller agile softwareudvikling til et team eller i en virksomhed, kan det ske, at teammedlemmerne kun griber fat i buzzwords, men ikke de grundlæggende ideer bag dem. Dette fører til misforståelser og modstridende situationer. Det var hvad der skete på mit aktuelle projekt, da jeg bad et teammedlem om at refaktorere sin kode for at øge dens læsbarhed efter en gennemgang af kildekoden. Han svarede med ordene fra vores scrum-master, som er scrum-masteren gentager altid som et mantra: Udført er better end perfekt og du er ikke væk har brug for det (YAGNI). Begrundet med disse ord nægtede han at foretage refactoring. I fremtiden (du får ikke brug for det).

Men hvor gyldigt er dette argument? Refactoring på den ene side og YAGNI på den anden.

Projektledelsesperspektiv

Fra et projektstyringsperspektiv en radikal anvendelse af YAGNI og Udført er bedre end perfekt ligesom i erklæringen ovenfra sammenlignet med refactoring fører til fordele på kort sigt. Udvikleren sparer tid og kræfter på at røre ved den allerede fungerende kildekode. Således kan udvikleren fortsætte med andre opgaver. Risikoen for brud på allerede fungerende kode under refactoring kan således undgås.

Imidlertid fører denne tilgang til problemer i det lange løb, hvis kildekoden skal læses eller ændres af andre udviklere. De første indikationer for problemer vises allerede ved kodevurderinger. Så fremtidige forbedringer kan være vanskelige, hvis kildekodestrukturen vælges uhensigtsmæssig og er blevet forbedret ved en refaktoring af.

Softwareudviklingsperspektiv

Fra et softwareudviklingsperspektiv skal udsagnet ovenfra betragtes som yderst kritisk. Forkert struktureret eller uforståelig kildekode gør udvidelse og vedligeholdelse af eksisterende software alvorligt sværere. Ud over opfyldelsen af de givne krav skal software være vedligeholdelig og læsbar. På grund af dette faktum er refactoring en godkendt metode til at nå dette mål. Softwareudvikling angiver klart nødvendigheden af refactoring. Bare spørgsmålet, hvornår man skal refactor, skal overvejes. Efter alt refactoring kan finde sted, når kildekoden faktisk er omarbejdet i fremtiden. Dette ville være i betydningen Udført er better end perfekt og YAGNI som i udsagnet ovenfor. Imidlertid fører denne tilgang til et andet problem. Viden om kildekodens adfærd og formål kunne allerede gå tabt på et fremtidig tidspunkt. Årsagen kunne ikke være den samme som den oprindelige forfatter. Selv den oprindelige forfatter kunne glemme kodens formål og opførsel efter lang tid. Disse fører til problemer, når du tilføjer fremtidige forbedringer eller udfører vedligeholdelse. For forbedringer er det måske ikke klart, hvor man skal ændre, eller hvilken del af applikationen der er. Som et resultat bliver integrering af forbedringer betydeligt sværere. For at vedligeholdelse næsten skal være, skal kildekoden tydeligt læses. Ellers spildes en masse vedligeholdelsestid med at prøve at finde ud af, hvad koden er. Det tilrådes at udføre refactoring, når viden om kodens adfærd og hensigt stadig er til stede. Derudover er det ikke målet med refactoring-processen. På trods af efterbehandlingen kan kildekoden muligvis refaktorificeres. Denne senere refactoring er dog meget lettere og hurtigere, fordi kildekoden allerede findes i en forståelig og velstruktureret form og ikke behøver at blive omdannet til en velstruktureret form.

Testdrevet udviklingsperspektiv

Når man udvikler sig på en testdrevet måde, er sagen klar. Testdrevet udvikling er baseret på TDD-cyklus eller rødgrøn cyklus, der består af tre faser: Testen mislykkes, når en rød brudt testindikation. I den anden fase tilføjes kildekode til fastsættelse af den mislykkede test. Testen lykkes nu med at få testindikationen til at blive grøn. Refactoring er den tredje og sidste fase, før en hel cyklus er afsluttet. Den testdrevne udviklingscyklus er således ikke fuldstændig uden en endelig refactoring. Refactoring finder sted straks og hurtigst muligt Udført er better end perfekt og YAGNI som nævnt ovenfor.

Agilt softwareudviklingsperspektiv

Målet med smidig softwareudvikling er at levere arbejdssoftware kontinuerligt og tidligt. Fleksibel til hurtig reaktion på ændringer, softwarekvaliteten skal være høj, og selve softwaren skal være fleksibel. Denne procedure fremmer trinvis udvikling. Som allerede beskrevet i softwareudviklingsperspektivet involverer efterfølgende refactoring tidstab og problemer i sammenligning med refactoring på oprettelsestidspunktet. Indtil den efterfølgende refactoring har fundet sted, er kvaliteten og fleksibiliteten af en software faldet. Regelmæssig refactoring og en ren kildekode hører til software af høj kvalitet. Under denne forudsætning er en udsættelse af refactorings ingen mulighed for dette perspektiv.

Ser på YAGNI og Udført er better end perfekt i deres fødested, smidig softwareudvikling i sig selv. De skal ikke være i stand til at gøre en nødvendig indsats for fremtidige funktioner på nuværende tidspunkt. Disse funktioner kan implementeres om nødvendigt eller når de endelig er planlagt til implementering. Den tid, der frigøres med denne tilgang, skal derefter bruges til forbedring af softwarekvaliteten, som også inkluderer refactoring. YAGNI er en opmuntrende software til at være fleksibel. Derfor er YAGNI og refactoring ikke i modstrid med, men afhænger endda bogstaveligt talt af hinanden.

Konklusion

Her er en kort oversigt over alle grunde ovenfra:

funktionalitet kan ikke brydes	højere softwarekvalitet
tidsbesparelser på kort sigt	læsbar kildekode
at udvide softwaren i fremtiden er lettere
kendskab til formålet med kildekoden, der stadig er tilgængelig
TDD-principper tilfredse
Hurtigere vedligeholdelse

Kort sagt er refactoring på oprettelsestidspunktet under alle omstændigheder nødvendigt. At antage, at YAGNI og refactoring modsiger hinanden, er en misforståelse for visse softwareudviklere.

Endelig en anbefaling: Det argumenteres ofte mod refactoring, at der ikke er klare mål. Overordnet set kan et stykke software refaktorificeres og optimeres i ethvert tidsrum. Det er nødvendigt at definere klare mål for softwarekvalitet og refactoring. Så en “Udført” opnås således til refactoring. Således er det mit råd at bruge definitionen af gjort i scrum til at definere kvalitetskriterier ved hjælp af kodeanalyseværktøjer såsom sonarqube og checkstyle. Derefter finder refactoring sted, indtil kildekoden opfylder kravene.

“>

Arv: grad af forhold, der bestemmes af retten

arv Arvelov regulerer aktiverne for de overlevende pårørende Hvis der ikke foreligger en hensigtserklæring i form af en effektiv testament, træder den…
Realkreditudlån: sammenligning, tjekliste – vigtige oplysninger (2019)

Sammenligning af realkreditudlån Sammenligning, tjekliste vigtige spor til dig Den vigtigste ting kort sagt Realkreditudlån er ekstremt kompliceret og…
Implantologi – implantater berlin tandlæger – – ku64

Implantater af KU64 Implantater af KU64 Alt for ofte glemmer vi, hvor dyrebare nogle ting er, indtil vi mister dem for godt. Dette gælder også vores…
Lungeinfarkt – årsager, klager og terapi

lungeinfarkt På én lungeinfarkt Det er en lungeemboli, der ofte har sin oprindelse i patologiske ændringer i venerne. Lungeemboli er en alvorlig…