Velg teknologi for teamet etter overleveringen

Hvem gjør den neste endringen?

Teknologivalget gjelder også teamet som skal vedlikeholde applikasjonen etter overleveringen. Kan det endre riktig kilde, kontrollere og spore problemer? Spørsmålet supplerer funksjoner og innsats ved første utvikling.

Googles veiledning om kodegjennomgang tar eksplisitt hensyn til fremtidige utviklere. Derfor foreslår vi å gå gjennom en typisk senere endring med det planlagte vedlikeholdsteamet ved verktøyvalget.

Eksempel: samme adressetillegg, ulike arbeidsveier

Planen er oppdiktet. Valget står mellom et utbredt rammeverk som det fremtidige teamet kjenner, og en egen skjemagenerator som leveringsteamet hittil har behersket. Generatoren skal gjøre første skjema raskere å lage; eksemplet har ingen målt tidsbesparelse.

Begge trenger runtime, pakkekilder, kontroller og forståelig dokumentasjon. Med generatoren må også stedet for varige endringer være tydelig. En manuell retting i genererte filer kan forsvinne ved ny generering. Kontroller det fremfor automatisk å se leverte filer som vedlikeholdbar kilde.

Gjør vedlikehold til en del av valget

SEI regner endringsvennlighet blant viktige arkitekturkvaliteter. Registrer hvem som vedlikeholder avhengigheter og verktøy, nødvendig støtte og stedfortredelse. En dokumentert innføring kan lukke et kunnskapsgap; filtilgang alene kan ikke.

En egen generator kan være begrunnet for passende oppgaver med pålitelig vedlikehold. Et utbredt rammeverk krever også kunnskap, oppdateringer og tydelig ansvar. Vurder begge ved samme senere oppgave og dokumenter gjenværende avhengigheter.

Kilder

• Google: What to look for in a code review

• SEI: Software architecture