How does updating Retrospect work?
There has been a lot of confusion on how Retrospect update work. So this KB article is an attempt to explain the main ideas and principles behind the system. And...
Home of Retrospect
Gedurende het ontwikkeltraject van de meeste applicaties of systeemintegraties kom je als software-architect wel eens voor de keuze te staan tussen het ‘zelf maken’ van een onderdeel of het gebruiken van een (extern) component van derden. Geen gemakkelijke keuze, aangezien beide opties voordelen en nadelen hebben en je eigenlijk het meeste zelf zou willen doen, maar je ook niet opnieuw het wiel wilt uitvinden. Wat zou je mee moeten nemen in je overwegingen?
Als je zelf een component ontwerpt zal je er voor zorgen dat dit precies doet wat jij wilt dat het zou moeten doen. Niet meer, want dat is zonde van de tijd en geld, en zeker niet minder. Bij een extern component heb je vaak wat minder keuze: de functionaliteit ligt immers reeds vast en deze sluit meestal niet volledig aan bij de wensen. Zo kunnen componenten veel te uitgebreid zijn en vaak te complex of ze sluiten net niet aan bij de wensen. Vooral in het laatste geval komt het dan vaak neer op het gebruiken van een combinatie van eigen code en het extern component. De vraag is of je er dan veel voordeel van zal hebben. Maar ook een te complex component kan nadelen hebben, zoals het onnodig complex maken van de onderhoudbaarheid van je oplossing.
Een ander afweging ligt op het gebied van de onderhoudbaarheid van het component. Je eigen oplossing zal je door en door kennen en eventuele problemen kun je zelf analyseren en oplossen. Bij een externe component ligt de zaak een stuk complexer. Zelfs als de broncode beschikbaar is, blijft het lastiger om problemen op te sporen en te verhelpen. Je hebt immers minder inzicht in het ontwerp en de code en dus is het lastig om in te schatten wat voor impact een aanpassing zal hebben op het geheel. De enige hulp die in sommige gevallen ingeschakeld kan worden is, indien deze bestaat, een community rondom het component. Maar over het algemeen kun je stellen dat de onderhoudbaarheid een stuk lager is bij een extern component. Zonder broncode wordt het meteen al een stuk lastiger en kan je enkel hopen op een meewerkende fabrikant.
Net viel het woord broncode al. De meeste externe componenten hebben een licentie waar aan je moet voldoen. Vaak is dat geen probleem, maar het kan wel je keuze beïnvloeden. Zo mag niet elke component voor commerciële doeleinden worden gebruikt en vaak legt het ook restricties op aan je eigen licentie. Uiteraard heb je met eigen componenten geen last van licenties behalve van die van je zelf.
Is er een goede of een foute keuze? Ik denk het niet. Behalve de bovenstaande punten zijn er ongetwijfeld nog veel meer voors en tegens. Ook persoonlijke voorkeur, die van een klant of een corporate policy, kan een rol spelen in de keuze. Dus wellicht is het beter om iets minder algemeen te kijken en te stellen dat je per klant en/of oplossing een keuze moet maken. Het is lastig om bij een klant te verantwoorden dat je per release of per applicatie een ander component gebruikt hebt voor bijvoorbeeld logging. Het is immers voor de klant ook iedere keer weer een leerproces om met nieuwe componenten te werken.