Sorte huller i udviklingsafdelingen

“Programkode har masse og dermed tyngdekraft. Programkode tiltrækker mere programkode og hvis man ikke passer på, ender man med et sort hul, der til sidst opsluger alle udviklingsresourcer.”

Det er et af de udsagn, som hænger fast i hovedet på mig efter årets GOTO. Kevlin Henney formulerede det måske en smule anderledes – primært fordi han er Brite – men pointen er den samme: Systemer har tendens til at vokse sig store – for store – med mindre man aktivt arbejder på at undgå det. Man skal hele tiden forsøge at nedbryde det i mindre, sammenhængende dele. Det er særlig vigtigt at have gjort, når systemet på et tidspunkt overgår til at blive et af de legacy-systemer vi alle frygter at vedligeholde. Gerne er systemerne sovset ind i antagelse og undtagelser, som muligvis gav mening da de blev implementeret, men ikke giver mening længere og ingen kan længere huske præmiserne for antagelserne og undtagelserne. Ved at holde systemet i mindre, overskuelige bidder, kan det blive lettere at fjerne kode, der ikke længere skal bruges – og kode skal fjernes.

Et af de tidligere år på GOTO, var der nogen – og jeg har virkelig gravet for at komme i tanker om hvem det var – som talte om “Code as liability”. Det kunne godt have været Kevlin, men jeg er ikke sikker. Da jeg kort vendte det med ham senere på dagen, nikkede han i hvert fald ivrigt. Anyway, det betyder, at hver kodelinie er en omkostning for virksomheden – som en vare der blot ligger på lageret og samler støv og derved er em omkostning. Med dette udsyn, bliver udviklerens opgave at skrive så lidt kode som muligt, men stadig nok til at løse problemet. I ekstremet er “kode der ikke bliver skrevet” det, som giver den største værdi, da man får løst et problem uden at have skabt noget, som bagefter skal vedligeholdes. Desværre er det ikke ofte vi får mulighed for at lave den slags løsninger, og så gælder det om at skrive kode, der er let at vedligholde: små, overskuelige “klumper”. Man kan sige, at buskabet var, at systemer skal skrues sammen på en måde, så de er lette at skille ad. Kevlin lagde, som jeg hørte det, op til at kigge i retning af Microservices som et middel til at komme nærmere dette.

Personligt deltog jeg ikke i Microservice-sporet, så jeg håber at nogle af de andre, her på kanalen, dækker det, for der var helt givet nogle take-aways. Selv fokuserede jeg primært på Deep Learning Analytics-sporet og Tactics for better Teams-sporet, men det vil jeg vende tilbage til i nogle opfølgende posts. Jeg lige kommet hjem og skal have de hele fordøjet.

Share Button
The following two tabs change content below.
Profile photo of Andreas Ryge
Med en baggrund i datalogi og psykologi, er jeg humanisten i datalogi. Arbejdsmæssigt har jeg været lidt omkring. Har været selvstændig, lavet systemer til skattemyndigheder i det meste af verden, arbejdet med musikbranchen, lavet systemer til telebranchen og er idag endt i AudienceProject. Gennem tiden har jeg prøvet en del roller, blandt andet projektleder, scrum master, afdelingsleder og arbejder i øjeblikket som Data Scientist - en lidt anden rolle, end den typiske udvikler-rolle. Har også været en del omkring i sprog og teknologier, bla C/C++, Tcl, Prolog, Java, Perl, Python, Ruby, Clojure og arbejder idag mest med Scala. Mine interesser mange, særligt machine learning, distribuerede systemer og sikkerhed. Og så interesserer jeg mig også lidt for filosofi. Forvent at skriblerierne stritter i alle retninger.
Profile photo of Andreas Ryge

Nyeste indlæg af Andreas Ryge (se alle)

Flattr this!

Post navigation

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *