Een evolutie in software die effect heeft op de broncode van de ‘klanten’, hoeft op zichzelf geen ramp te zijn. Het effect van deze veranderingen moet echter wel eerst in kaart worden gebracht. Pas dan kunnen ontwikkelaars onderbouwde beslissingen nemen over het wel of niet introduceren van veranderingen, de consequenties en de daarbij behorende strategieën.
Tot die conclusie komt Lina Ochoa in haar proefschrift ‘Break the Code? Breaking Changes and Their Impact on Software Evolution’. De Colombiaanse expert op gebied van softwareontwikkeling promoveerde op vorige week aan de TU Eindhoven.
Softwareprojecten zijn vaak onderdeel van grote software-ecosystemen met veel onderlinge afhankelijkheden, onder meer vanwege het hergebruik van softwarebibliotheken. Softwareprojecten hebben vaak een dubbele rol. Enerzijds dienen ze als bibliotheek om functionaliteit te bieden aan andere projecten. Anderzijds hebben ze zelf een klantrol; de software is afhankelijk van andere bibliotheken om de vereiste functionaliteit te implementeren.
Uit het onderzoek van Ochoa blijkt dat gebruikers meestal niet de best practices
toepassen bij het definiëren van afhankelijkheden. Verder ziet ze bibliotheken over het algemeen semantische versiebeheer gebruiken wanneer er syntactisch brekende wijzigingen worden geïntroduceerd. Dit wordt in toenemende mate toegepast. Een beperkt aantal klanten heeft last van deze veranderingen. Tools om de evolutie van software te ondersteunen blijken accuraat, toepasbaar, en relevant voor een pull-gebaseerd manier van werken.
Evolueren
De Colombiaanse computerwetenschapper beschrijft in haar proefschrift hoe bibliotheken gaandeweg evolueren. Softwareontwikkelaars passen de bibliotheken aan om (extra)functionele en verbeteringen door te voeren. Het doel van deze veranderingen is om de bruikbaarheid van de bibliotheek te vergroten.
Maar tegelijkertijd hebben deze wijzigingen ook effect op de projecten van de klanten. De veranderingen kunnen leiden tot broncode die niet meer voldoet of zelfs niet meer werkt, zogenaamde ‘brekende wijzigingen’ of ‘breaking changes’.
Versiebeheer wordt vaak gebruikt om de aard van de geïntroduceerde veranderingen inzichtelijk te maken, namelijk veranderingen die mogelijk negatieve effecten op de broncode van de klant hebben.
De ontwikkelaars van bibliotheken staan daarom voor een dilemma: moeten ze veranderingen introduceren ten koste van het veroorzaken van (grotere) veranderingen in de broncode van hun klanten of zelfs het kwijtraken van hun klanten? Of moeten ze veranderingen vermijden ten koste van een hogere technische schuld?
Twee methoden
Om deze vragen te beantwoorden introduceerde Ochoa twee methoden. Als eerste gebruikte ze een statische impactanalysemethode om brekende wijzigingen, en de effecten op software van de klant, te detecteren. Met een statische compatibiliteittestmethode spoorde ze de omgekeerde afhankelijkheden. Dit als onderdeel van een pull-gebaseerd manier van werken. De eerste methode is geïmplementeerd in Maracas, een statisch analyse tool voor Java-projecten. De tweede methode is geïmplementeerd in BreakBot, een GitHub bot die bibliotheek-evolutie ondersteunt.
Geweldig, die titel. Waar gaat het over ?
Waar het over gaat : dependencies en dan met name in bibliotheken maar geldt natuurlijk voor alle dependencies.
Een oplossing: versiebeheer. Briljant.
Semantisch versie beheer zelfs. Tja dat was er voor ontworpen. Breaking changes alleen in de major releases..
Maar toen moest alles ineens rolling en failfast. Dat failfast is eigenlijk meteen tegen een breaking change aanlopen, alleen dan is het cool.
“veranderingen die mogelijk negatieve effecten op de broncode van de klant hebben”.
Als je zoiets leest weet je al dat het misgaat.
Net zoals iemand Oewebsite zegt ipv Website. Dan snappen ze er geen reet van.
Het mooie van bibliotheken is dat ze aan iedereen kunnen aanbieden. Maar hoe weet je nou wie waarvan gebruik maakt. Toch wisten we dat vroeger al. In boek stond een stempel, tot wanneer je het boek in bruikleen had en de bibliotheek hield in dikke boekwerken bij wie nou welk boek geleend had. Zoiets kan ook handig zijn voor software libs. Loggen wanneer wat waarvan gebruik maakt, misschien zelfs met welke parameters. Want wie bewaart die heeft wat.
De link verwijst naar een document met meer informatie, de boodschapper van Computable is niet de onderzoeker. Dilemma dat geschetst wordt lijkt om een keus voor ‘technical debt’ of verandering te gaan. En wat betreft die verandering wordt aangegeven datje daarin de onderbouwde beslissingen moet kunnen nemen. Dat staat keurig in dik gedrukte letters in de inleiding want ook ik heb niet alle bladzijden gelezen maar vooraf weten wat de consequenties van een vernieuwing zijn lijkt me geen slecht idee.
Wat betreft Dino en het afstempelen in de bibliotheek aangaande de populariteit introduceert hij een risicofactor, de breaking change van Log4J. Want wie wat bewaard die heb nog wat wordt vooral dit non-functionele aspect nog weleens vergeten. Over een ‘breaking change’ van het moeten versus de updateritis van het willen als het om de disciplines van configuratie- en change management op het niveau van de services gaat betekent dit prioriteiten stellen op basis van risico’s. Ik het het hier over de business case voor verandering want onderbouwde beslissingen voor de keus van onderliggende software gaat uiteindelijk om het ontzorgen.
En hierin gaan de vragen niet om de details van software versies, onderzoeker concludeerde dat de best practices van versiebeheer niet gevolgd worden. Wat betreft de papieren tijgers van de theorie en de werkelijke beren van de praktijk niet echt een verrassende conclusie. Het probleem met open source is namelijk het gebrek aan contractuele verplichtingen want het is een nogal opportunistisch speelveld. De ‘breaking change’ van de lifecycles van software en een behoudendheid van services levert nogal wat ‘technical debt’ op als ik kijk naar vermeende veiligheid van code die je kunt lezen.
Tja … good practices als semantic version zijn mooi, maar inderdaad, als je leverancier zich er niet aan houdt dan wordt het lastig
Als change- en configuration management kun je, zoals Oudlid al aangeeft, een heleboel doen in een poging om de “dependency-hell” een beetje te managen, maar voor een deel ben je daarbij wel afhankelijk van wat je ontwikkelaars zeggen en/of doen
Een tweetal voorbeelden
– ontwikkelaars die zeggen dat de wijzigingen backwards compatible zijn, maar ondertussen toch zogeheten breaking changes implementeren (al dan niet bewust, dat is weer een heel andere discussie)
– ontwikkelaars die change- en configuration management vooral als overhead zien en externe bibliotheken rechtstreeks in hun software archief kopiëren in plaats van gebruik te maken van dependency-management tools
Dat laatste hadden we bij één van mijn vorige werknemers op een gegeven moment redelijk goed onder controle door te stellen dat de broncode archieven alleen nog maar ascii(tekst) files mochten bevatten, ofwel puur broncode. Voor alles wat afweek moest men een goede verklaring hebben. Hier werd wekelijks op gecheckt.