Nogle gange kan man som udvikler eller udviklingschef ønske sig en tidsmaskine, så man kunne smutte tilbage og råbe højt, at et lidt klumset hack i en snæver vending under udviklingen af systemet har været anledning til utallige hovedpiner ti år efter.
Det er bare ikke så nemt – så i stedet kan man prøve at gøre verden til et bedre sted for sine efterfølgere med de beslutninger, der bliver taget i dag. Sådan lød budskabet fra udvikleren Ashic Mahtab, da han holdt oplæg om ’neo-legacy’ på Warm Crocodile Conference, der fandt sted i København i sidste uge.
Legacy-kode definerede han som software, vi har arvet med en masse problemer indbygget, men som stadig giver nok værdi til, at det kan betale sig at holde det i gang. Og der bliver også taget masser af beslutninger i dag, som nok skal give problemer for fremtiden, mente han og kom med sine bud på, hvad vi skal undgå.
»Har I en kodebase på mere end 500 megabyte? En gigabyte? Det skal I prøve at undgå. I skal gøre noget ved det nu,« sagde han.
Et firma, han havde arbejdet for, var endt med en helt enorm kodebase på 25 gigabyte, og så var det nærmest for sent at lave om på. Det var kode fra mange forskellige projekter, der ikke nødvendigvis havde den store sammenhæng, men der var tilpas mange koblinger til, at det var en kæmpeopgave at skulle rede trådene ud.
»At få det hele fra hinanden er deres største udfordring nu. Det begyndte i 2002, og siden da har der været en masse rewrites. De har også prøvet at køre Git (versionsstyringssystem, red.), men det virkede ikke for dem. Så at køre videre med de 25 gigabyte er det, der giver dem færrest problemer lige nu,« sagde Ashic Mahtab.
Mange af fremtidsproblemerne i softwareudvikling kommer på grund af dårlige beslutninger fra højere sted end hos den enkelte udvikler, og en af de værste syndere er ’design by committee’, hvor alt skal godkendes i et stort udvalg, der ender med beslutninger baseret på mavefornemmelser eller ’highest paid persons opinion’, også kendt som HIPPO.
Er man heldig, betyder det bare en langsom beslutningsproces, men det kan også gå meget værre end det, lød budskabet med et eksempel fra det virkelige liv.
»Vi havde engang noget kode fra et eksternt firma, som var meget langsomt til vores formål. Så vi gav dem en række muligheder, som alle ville virke, og som ville tage et par uger at implementere. Syv måneder senere kom de tilbage med en beslutning, med ny teknologi, og uden at bruge nogen af vores forslag. Det ville kræve en masse ændringer, og det løste ikke problemet. Sådan går det, når det er ’design by committee’,« sagde Ashic Mahtab.
Regler om kun ét sprog hæmmer udviklerne
En firmapolitik, der ensretter udviklingsarbejdet i hele firmaet, for at gøre det mere strømlinet, kan også hurtigt give bagslag. At alt skal integreres til samme database kan give problemer, hvis folk bruger det forskelligt, og mange opgaver er nemmere, hvis man selv kan bestemme, hvordan databasen skal indrettes.
Ligeså vil en politik om, at alt skal køre igennem en enterprise service bus (ESB) gøre mange ting komplicerede. Og krav om, at alle løsninger i firmaet skal udvikles i ét sprog, er også at skyde sig selv i foden.
»Det er ikke nødvendigvis dårligt at have standarder, men det bliver problematisk, hvis det bliver håndhævet overalt til alt. For eksempel kan Erlang være en rigtig god løsning til nogle opgaver. Hvis .Net er standardsproget og du er tvunget til at bruge det, kan du ende med at skulle skrive og teste mange linjers kode bare for at få samme muligheder som i Erlang,« sagde Ashic Mahtab.
Agil udvikling er blevet uhyre populært, men det kan også give problemer, mente han. Nogle steder tager det overhånd med møderne – for eksempel faste møder for at planlægge, hvad sprint-planlægningsmødet skulle handle om – og andre gange er filosofien lidt farlig.
»Mange praktiserer agil udvikling ved at tænke ’det klarer vi senere, vi tilpasser os’. Men nogle ting kan man ikke ordne senere, for eksempel grundlæggende performance-problemer eller sikkerhedsproblemer,« lød Ashic Mahtabs anti-legacy-råd.
Udover de mere langsigtede tanker om arven, man efterlader til kommende udviklere på opgaven, er der også tilsvarende problemer at overveje bare fra udvikling til lancering. Tit kommer et website for eksempel i stormvejr, når det går live, selvom det er blevet kapacitettestet.
»En webside lanceres – og så går den ned. Det sker faktisk tit, selvom man tester og tester og synes, man har gjort den ’klar til kamp’. Hvis oppetid betyder noget, skal du tænke over de her problemer, også de problemer, du ikke forventer vil komme,« sagde Ashic Mahtab.
Han supplerede med et grumt eksempel, hvor en webbutik lancerede en ny version af websiden natten før det store, årlige udsalg, og betalingsfunktionen så går ned. Det tog 10 timer at få siden til at virke igen, fordi roll-back-løsningen ikke virkede. Den var aldrig blevet testet.
Warm Crocodile Conference fandt sted den 15. og 16. januar i Empire Bio i København. Version2 var mediepartner på konferencen.
Leave a Reply