Dette indlæg er alene udtryk for skribentens egen holdning.

Død kode

19. juni 2008 kl. 08:0012
Artiklen er ældre end 30 dage

Kender du det: Du sidder og arbejder på et modul, koder, designer, tester, koder. Undervejs får du bygget et hierarki af klasser op, du følger designmønstre udtænkt af kloge hjerner og verden udgår fra dine fingerspidser, der danser lystigt over keyboardet. Farten er høj, men de små grå synes alligevel det går for langsomt, er utålmodige for at få skabt noget.

Du har styr på kravene til dit modul, omgivelserne, snitfladerne til de andre moduler, funktionaliteten. Det skal være perfekt denne gang: SMUK kode af en skønhed så høj, det kan skrives ud og hænges op i foyen til alles glæde. Der er en plads lige bag hende den søde sekretær, der smiler så pænt om morgenen.

Releasen nærmer sig og du har for længst skrevet unittest suiten, der afprøver alle mulige og umulige situationer dine metoder kan forventes at komme ud for gennem deres (antager du) lange levetid. Snitfladerne klikker pænt på plads med de andre moduler, som forventet og Q&A er gået i gang med at teste.

Pludselig en eftermiddag står han der, ham den lidt småsure testmanager, siger han har et problem og bag ham (oh schreck!) uber-teknik-arkitekten. Nej, der er ikke de store fejl i funktionaliteten, lidt småting, men ikke noget alvorligt. Jo, alle metoderne i de offentlige snitflader er implementeret, det er heller ikke det.

Artiklen fortsætter efter annoncen

Problemet er, at der er alt for meget kode ...

Når alle testscenarierne er kørt igennem ligger code coverage på lige under 40% og det er ikke bare exceptionblokke, der aldrig bliver udført. Der er simpelthen METODER der aldrig bliver kaldt! Uber-teknik-arkitekten er trådt hen ved siden af dit skrivebord nu og han ser eddikesur ud. 

Du har kodet mere end der skulle til for at løse opgaven! Hvem skal vedligeholde det' Hvem skal teste det og med hvilke scenarier' Hvad kunne den kostbare tid ikke have været brugt på?

Jamen, forsvarer du dig med, de ubrugte metoder skal nok komme i sving i næste release eller næste igen, men han smiler ikke. Så du forsøger dig med argumenter om den højere symmetriske skønhed i at have en set-metode når der også er en get-metode og at CRUD altså er en forkortelse for Create, Read, Update and Delete og så kan man ikke bare nøjes med Read ...

Hvor går grænsen' Skal man nøjes med det absolut nødvendige eller er det OK at kode lidt (død) kode på forventet efterbevilling fordi det får vi jo nok brug for' 

Hvad gør du?

12 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
19. juni 2008 kl. 08:43

Hej Kåre,

Jeg har nok en tendens til at gøre lige som dig :-)

Da jeg for snart mange år siden læste Kent Beck's Extreme Programming, bed jeg mærke i følgende sætning:

Use the simplest possible solution. Don't plan for future features, don't plan for reuse. Change the software in the future when you need to. Think "Return On Investment" (ROI)

Det er som bekendt meget svært at spå - specielt om fremtiden. Med de værktøjer man som udvikler har til rådighed, her tænker jeg specielt på refaktoreringsfaciliteterne, er det nemt på et senere tidspunkt, at fx organisere kode anderledes, ved at trække metoder ud til et generelt interface etc.

Jeg prøver altid at huske Kent's læresætning, når jeg sidder arbejder med kode, hvilket hjælper mig til at komme i mål med en løsning der er spot-on i forhold til problemet.

Hilsen Christian

2
19. juni 2008 kl. 09:12

Hvis jeg laver et modul, som har et fast defineret formål, så laver jeg kun dét, der er brug for.

Men man kan i sine model-klasser godt åbne op for, at f.eks. antal returnerede elementer fra en metode kan variere.

Hvis jeg derimod laver generel kode eller bare et modul, som andre skal integrere med, så vil jeg tænke endnu mere over fleksibiliteten og "hvad nu hvis man har brug for at sortere dem anderledes? Hvad nu hvis man kun vil have et subset - hvilke parametre vil man så bruge?"

3
19. juni 2008 kl. 11:48

Jeg starter også med flotte klassehierarkier, men forsøger holde det indenfor rimelighedens grænser. Programmering er en balanceakt i gråzonerne.

Jeg KAN ikke lade være med at tilføje koden en vis grad af fremtidssikring, enten ved at gøre koden letlæselig eller ved at lave metodernes parameterhover så de ikke støder på grænser. Jeg gør meget konsekvent brug af navngivningsstandarder, blokke og indrykninger. Uanset hvor banal objektet er bliver det pakket ind i en finally-sektion så det frigives; det ligger som genveje i mit udviklingsmiljø. Jeg vil aldrig bruge en statisk array hvis der er minimal risiko for kommer flere end de nuværende data. Den bliver dynamisk fra starten.

Man kan sammenligne det med at lave en cykel (eller gynge ...) Et hjul, et sæt pedaler og en saddel kan gøre det, men turen bliver ikke flot for den uøvede. Jeg foretrækker to hjul og hvad der hører til, så mange kan bruge cyklen fra A til B - og måske også til C.

Jeg klynger mig nemlig til påstanden om at læsbar og stringent kode allerede lønner sig ved Version2.

4
19. juni 2008 kl. 14:13

Ja, det er jo nærliggende at citere Kent Beck med hans XP-matra: "Do the simplest thing that could possibly work."

Men det er ikke bare en nymodens XP-ting - gode gamle Albert E. sagde "Make everything as simple as possible, but not simpler."

Se DET er jo smukt - og sådan bør man efter min mening også skrive kode.

5
19. juni 2008 kl. 14:43

Men simpel kan være mange ting. Simpel kan være 'mindst mulig kode'-simpel, men det kan også være 'nemt at forstå'-simpelt. Menneskets hjerne er ikke særlig velegnet til at huske, men er derimod god til at genkende mønstre og regler. For at udnytte denne egenskab kan man lave sin kode symmetrisk og egensartet - derved undgår man at stresse sin stakkels overbebyrdede hjerne. Virker på min grønært.

6
19. juni 2008 kl. 14:53

Jeg vil vende spørgsmålet og sige, hvorfor skrive kode som ingen (tilsyneladende) har brug for? Hvis du ikke kan finde nogen, der har glæde af den ekstra funktionalitet, hvorfor så bruge resourcer på at skrive og vedligeholde den?

Brian

7
19. juni 2008 kl. 16:19

Indrømmet: jeg har også prøvet at udvikle klasser der havde metoder som aldrig kom i brug, en ekstra overloadet constructor her eller der eller en sandsynlig funktion - just in case.

Personligt mener jeg dog det er en fordel at rydde ud i kode der aldrig bliver anvendt, da det går ud over vedligeholdbarheden, hæver tærsklen for at nye udviklere kan arbejde videre, kræver større indsats at skrive og teste, etc.

Et særligt tilfælde er når man har skrevet kompleks kode, der alligevel ikke skal bruges og hvor det er uklart om det nogensinde kommer til det f.eks. som følge af ændrede krav. Men så er der jo heldigvis altid et versionskontrolsystem, så man med sindsro kan fjerne metoden fra sin klasse efter at have checket den ind.

9
19. juni 2008 kl. 17:01

Der stod det jo - mit blogindlæg kunne have været så meget kortere :-)

10
20. juni 2008 kl. 10:55

En anden måde at sige Kent Becks rædselsfulde motto på er "Dont invest". I alle andre sammenhænge er velovervejede investering en god ide, hvorfor så ikke med software? Kent Beck mener i det store og hele at man bare skal tilrette arkitekturen løbende efter hånden som man får brug for det. Konsekvensen er i min verden et kludetæppe af rettelser som er langt svære at vedligeholde end et gennemtænkt design.

Når det er sagt så er micro-investering ala dine setter metoder ret ligegyldige og spild af tid. De kan jo skrives når man skal bruge dem, uden at det ændrer noget nævneværdigt ved resten af programmet.

11
22. juni 2008 kl. 17:37

Jeg er absolut også modstander af lad-os-tage-skyklapper-på-og-få-skrevet-noget-kode-mentaliteten, der hersker i XP-kredsene. Yes, at diskutere get- og set-metoder er overkill, men på et lidt højere abstraktionsniveau bliver det sgu nødvendigt at se mere end en uge ud i fremtiden. Jeg har i min tid set adskillige "kludetæpper af rettelser", som er forfærdelige at vedligeholde og udvide, og som kører bare nogenlunde fejlfrit.

Det er en uskik, som IT-folk er de eneste der praktiserer; hvor mange ingeniører ser du gå i gang med at lave en bro uden at have en detaljeret plan og et punkt på den anden side af sundet at sigte efter? Nej, fri mig for det makværk der kommer ud af kortsigtede planer.

12
22. juni 2008 kl. 18:14

Det er sjovt som disse blog-tråde har det med at blive drejet og få nye vinkler og det er fint.

For en god ordens skyld vil jeg dog lige sikre mig, at jeg ikke bliver taget til indtægt for at være tilhænger af tilfældigt sammenklasket kode.

Tværtimod.

Hvis man ikke tager arkitektur alvorligt fra begyndelsen og designer nonfunktionelle egenskaber som sikkerhed, performance, skalerbarhed, etc. ind fra starten bliver systemet netop et kludetæppe af lap på lap. Når det er sagt vil man jo stadig skulle kode systemet på et eller andet tidspunkt og her kan man have en mere eller mindre færdig klassemodel inden man går i gang og dermed varierende frihedsgrader til at fylde mere eller mindre på. Det var min vinkel.

Jeg må dog indrømme at det er totalt umuligt for mig at se sammenhængen til agil udvikling?! Uanset hvilken udviklingsmodel man anvender er en tilfældig arkitektur aldrig ønskelig.

Mht. get og set metoder var de valgt ud fra devisen "overdrivelse fremmer forståelsen" ...