Door karma4: De gegenereerde code in een source repository opnemen omdat het kan is vrij onzinnig je kan er weinig mee ander dan een backup/restore.
Ik heb met een codegenerator gewerkt die de specificaties voor de gegenereerde code als commentaar voorin de source opnam. Een SCM levert ook een gedetailleerde audit trail op, faciliteert parallelle projecten die dezelfde broncode raken, het is veel meer dan alleen opslag of backup/restore. Het sluit inderdaad niet goed aan bij data die in een DBMS zijn opgeslagen.
Als je code genereert vanuit een datamodel heb je echt niet alles te pakken wat er in een programma moet gebeuren. Als je software het niveau van geautomatiseerde kaartenbakjes overstijgt moeten er ook nog ouderwets algoritmes geïmplementeerd worden voor dingen die niet in een datamodel te vatten zijn of die niet of niet direct aan een datamodel gerelateerd zijn. Er blijft dus wel degelijk ouderwets programmeerwerk over dat gebaat is bij een goed SCM.
Als ik te maken zou krijgen met een hybride systeem waarin code voor een deel uit een DBMS gegenereerd werd en voor een deel handwerk was, dan zou ik het verdomd belangrijk vinden om de werking van het systeem van wijziging tot wijziging vastgelegd te hebben op een manier die het mogelijk maakt om achteraf te kunnen nagaan hoe het systeem zich gedragen heeft. Je zal maar met een schadeclaim zitten die correspondeert met een versie van de gegenereerde code die je niet meer hebt en die je niet meer met zekerheid kan reproduceren omdat de codegenerator inmiddels een of meer versies verder is en/of het datamodel inmiddels is aangepast. Je moet in dat soort situaties
zeker weten welke code op welk moment gebruikt werd. Banken moeten, als ik me goed herinner uit de tijd dat ik als onwikkelaar voor een bank werkte, tot in detail minstens tien jaar terug kunnen in de tijd. Vanuit zulke eisen zou ik bij elke wijziging zowel de gegenereerde broncode als de gegevens van waaruit die gegenereerd is vastgelegd willen hebben in een SCM. Het is absoluut niet onzinnig om dat te doen.
En het artikel waarop we reageren gaat over de Linux-kernel. Je kan echt niet met zoiets als de erwin Data Modeler process scheduling opzetten, een hardware device driver schrijven of een journaling file system implementeren. Je hebt het over specifieke toepassingsgebieden waar een deel van de broncode gegenereerd kan worden, maar daarmee dek je lang niet alles wat. De overgang waarvan je zegt dat die gaande is dekt dus ook echt niet alles.
De ML AI omgevingen gaan een stap verder. De training data is de werkelijke broncode. denk een aan 10Gb of veel meer. De algoritmes spuwen er rustig gegenereerde code uit van 100Mb of veel meer. Veel succes met je code beheer en het ethische in de processen brengen als gebruik van git de opgelegde eis is. Dan ligt de focus totaal verkeerd hoe je verantwoord met gegevensverwerking omgaat.
De trainingdata zijn geen broncode. Het ML-systeem dat die data verwerkt is geprogrammeerd en daar is broncode van, waarvoor een goed SCM net zo belangrijk is als voor andere softwareprojecten.
Die trainingsdata kan binaire data als afbeeldingen en video's bevatten, afhankelijk van de toepassing. Git is niet in staat om daar diffs van aan te maken, in dat opzicht is het tekstgebaseerd, maar het is prima in staat om binaire data op te slaan. Als het nodig is om de ontwikkelgeschiedenis van die trainingsdata te bewaren en als diffs voor specifieke binaire bestandsformaten daar sowieso geen rol in spelen dan kan software als git daar wel degelijk voor ingezet worden.
Ik heb voor de grap een directorystructuur met 20GB aan foto's onder git gebracht, verdeeld over dertien commits, en dat leverde een git-repository van 19GB op (er staan wat comprimeerbare bestanden tussen). Op een bescheiden computertje met een consumentenlaptopschijfje kostte een checkout van de volledige 20GB me zojuist een kleine 10 minuten. Checkouts die niet alles veranderen in de werkdirectory gaan aanzienlijk sneller - checkouts van alle commits in chronologische volgorde kosten bij elkaar ruim 10 minuten op hetzelfde systeem. Als je niet aan de lopende band moet wisselen tussen versies van de dataset kan dat heel werkbaar zijn.
Ik beweer hiermee niet dat git per se het ideale hulpmiddel is voor dit soort datasets, maar schuif het ook niet bij voorbaat aan de kant omdat het primair voor broncode bedoeld is. Het kan je nog steeds een nauwkeurige vastlegging van de ontwikkelingsgeschiedenis van zo'n dataset opleveren, met vastlegging van wie wat heeft gewijzigd op welk moment, en het stelt je net als bij source code in staat aan parallelle ontwikkeling te doen en de resultaten daarvan weer samen te voegen, met behoud van die audit trail van wie wat op welk moment heeft gedaan. Als dat soort vastleggingen ertoe doen voor een toepassing dan hebben dergelijke SCM-tools nog steeds zeer interessante eigenschappen.