Den berømte Økse...

Tilbage i det gode gamle pioner-dage i FreeBSD var der en masse vittigheder om "vikingernes økse" der med beslutsomhed blev brugt til at sende gammel mølædt kode på pension.

Det sker stadig at der er folk der truer med at låne og bruge "the phk axe", et herligt folkloristisk levn at have sat sig.

Det er, stadig, min erfaring at de fleste synder i software-design og -vedlighold er at vi ikke smider kode nok ud.

Det er let nok at forstå, det tog os tid&pizza at skrive koden og det kunne jo være at man en dag stod og manglede en X.25/X.29 PAD.

... og så ville det jo være surt at have smidt koden ud, ikke sandt ?

For det første er der ikke noget der er smidt ud når man versions-kontrol, (se bare!) man kan altid grave det ud af systemet, hvis zombie-apokalypsen sker og OSI-protokollerne rejser sig fra deres grav igen.

For det andet er existerende kode helt klart i vejen for de vilde fremtidsideer, ikke mindst hvis ingen ved hvordan det virker, ikke kan teste det og alle bare leger "du rørte lorten sidst" med det.

Men vi kommer ikke udenom at det er meget sværere at svinge øksen når man selv har skrevet koden.

I min optik er det her rigtige programmører adskiller sig fra amatørene: Evnen til at indse hvornår koden skal dø, også selv om de har skrevet den selv.

Jeg er ved at ro Varnish V4 i havn og er nået til hvor de store gode arkitektoniske ideer støder ind i den existerende kode, herunder 327 test-cases.

Enten kan jeg sætte mig ned og bane mig vej igennem de 327 test-cases, rette dem til, test for test, så de passer til nyordningen, eller også kan jeg kaste dem alle over skulderen og starte forfra.

Dengang jeg begyndte på disse test-cases havde de en overordnet struktur der afspejlede Varnish v2 som jeg forestillede mig den, men de kommer overhovedet ikke til at passe til v4's arkitektur, der er sket for meget fundamentalt i mellemtiden, altså er det så godt som givet at en stak ny test-cases vil gøre jobbet bedre på den lange bane.

Alle der kan deres Shakespeare kan genkende MacBeths dilemma her: Frem eller tilbage, der er lige meget arbejde.

Men opgaven er jo ikke at minimere arbejdsindsatsen ved at pantsætte "teknisk gæld", opgaven er at komme videre ud over stepperne, for selvom Varnish V2 er populær og udbredt, så ligger der jo både en V5, en V6 og en V7 ude i fremtiden så før eller siden skal de der test-cases jo skæres til under alle omstændigheder.

Så det var altså den der økse jeg skulle have slebet...

phk

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Dertil kommer, at gammel kode ofte er optimeret til systemer, der har andre egenskaber end moderne systemer. Det kan gøre dele af koden overkompliceret og suboptimal i forhold til moderne systemer. Så det kan være en god ide at skrive koden om fra bunden, selv om den virker. Men det går imod den "If it ain't broke, don't fix it" filosofi, der kendetegner mange softwareprojekter.

  • 6
  • 0
#5 Jan Christensen

Jeg tror vist vi alle kan blive enige om at zombie apokalypsen er lige om hjørnet. Heldigvis har de forudsende mennesker på University of Michigan et kursus parat så vi kan nå at forberede os.

Min søn på 10 evaluerer ofte tings nyttighedsværdi i hvorvidt de kan bruges til at bekæmpe zombies med eller ej (en økse scorer højt på den skala).

/Jan

  • 1
  • 0
#8 Bo Lorentsen

Når man har kodet et system i et stykke tid, lære man en masse og denne viden er koden jo et form for øjebliks billed af.

Men når man så er blevet klogere (hvilke man kan være heldig at blive), efter rigtig mange timers kode, kan man ende i den situation at det man først troede var en rigtig god plan viser sig at kunne laves radicalt bedre, men anderledes (og ofte simplere). Hvis man ikke skriver sin kode om, går denne viden slet og ret tabt.

Min pointe er at kode er et udtryk for viden på et betemt stadie, og hvis koden skal have gavn af vores erfaring skal det jo følge det vi lærer.

--- hmm, dages lomme filosofi :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere