“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.