Technologie kiezen voor het team na de overdracht

Wie voert de volgende wijziging uit?

Een technologiekeuze raakt ook het team dat de toepassing na overdracht beheert. Kan het de juiste bron wijzigen, controleren en problemen herleiden? Die vraag vult functionaliteit en inspanning bij de eerste bouw aan.

Googles reviewrichtlijn houdt expliciet rekening met ontwikkelaars die de code later gebruiken. Loop daarom bij de gereedschapskeuze een typische latere wijziging door met het beoogde beheerteam.

Voorbeeld: dezelfde adresaanvulling, andere werkroutes

Dit plan is fictief. De keuze gaat tussen een gangbaar framework dat het latere team kent en een eigen formuliergenerator waarmee het leverende team tot nu toe vertrouwd is. De generator moet de eerste formulierbouw versnellen; gemeten tijdwinst ontbreekt hier.

Beide vragen runtime, pakketbronnen, controles en begrijpelijke documentatie. Bij de generator moet ook duidelijk zijn waar blijvende wijzigingen horen. Een handcorrectie in gegenereerde bestanden kan bij opnieuw genereren verdwijnen. Controleer dat in plaats van geleverde bestanden vanzelf als onderhoudbare bron te zien.

Maak beheer onderdeel van de keuze

SEI rekent wijzigbaarheid tot wezenlijke architectuurkwaliteiten. Leg vast wie afhankelijkheden en gereedschappen beheert, welke ondersteuning nodig is en hoe vervanging werkt. Een gedocumenteerde introductie kan een kennisgat dichten; alleen bestandstoegang doet dat niet.

Een eigen generator kan bij passende taken en betrouwbaar beheer gerechtvaardigd zijn. Een gangbaar framework vraagt ook kennis, updates en helder eigenaarschap. Beoordeel beide bij dezelfde latere taak en documenteer resterende afhankelijkheden.

Bronnen

• Google: What to look for in a code review

• SEI: Software architecture