Det meste kode stinker!

  • Our industry is plagued by an epidemic of very bad code* - citat Robert Martin (kendt som Onkel Bob), grundlægger af ObjectMentor.

Denne udtalelse faldt jeg over mens jeg kigge igennem videomaterialet fra JAOO Århus 2007 (den der konference, som havde sin egen version2-blog). Videoen er et interview med Robert Martin (Onkel Bob), Pete McBreen og Mike Feathers omkring softwareudvikling som profession* - ja faktisk om softwareudvikling som et håndværk. En virkelig god video, hvor de interviewede kommer med en række udtalelser, som jeg - måske naivt - blev meget overrasket over. Og de taler blandt andet om hvordan man kommer til at skrive bedre kode og at de ting som mange f.eks. studerende (heriblandt mig) tager for givet, slet ikke er fakta ude i virksomhederne.

Til spørgsmålet om hvordan man som udvikler får lov til at bruge tiden på at skrive god kode svarer Pete McBreen, at man skal snyde chefen! Lad være med at fortælle ham, at du bruger den ekstra tid - han kommer jo alligevel ikke til at se koden. Onkel Bobs kommentar til det var kort at han ikke ville kalde det snyd - han ville kalde det professionalisme. Er du enig?

En af grundene til, at Onkel Bob er meget interesseret i at gøre opmærksom på den dårlige kode er at han meget snart udgiver en bog, der hedder Clean Code - A Handbook of Agile Software Craftsmanship - og efter at jeg har hørt Onkel Bobs snak på JAOO sidste år er det helt sikkert, at den bog skal stå på min boghylde. Onkel Bob er en mand der forstår at skære ind til benet og han er bestemt underholdende, mens han gør det.

Men har Onkel Bob ret' Er du også plaget af dårlig kode' Og hvorfor skrev du det så?

*Hvis du er interesseret i at se flere videoer fra JAOO så er der en masse på jaoo.blip.tv om blandt andet DSL'er, Ruby og smuk kode.

Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Kastoft Nielsen

Jeg vil nærmere sige at man bør kode programmet så man kan stå inde for det bagefter.

Det syntes jeg egentlig er vores pligt som udviklere.

Man er vel altid plaget af dårlig kode - når man ser sit eget program et stykke tid efter man har skrevet det. - Der er spørgsmålet så om man skal refaktorere eller..

  • 0
  • 0
Thomas Hansen

Nok ser bossen ikke koden, men han ser heller ikke den dårlige kode. Og når skidtet umiddelbart virker, så er det svært at forklare hvorfor det tager en dobbelt så lang tid at lave som kollegaen der ikke har de samme etiske kvaler.

Tidspres er den primære grund til dårlig kode i mit tilfælde. Det skal bare virke og helst i går. Jeg ville som oftest hellere sidde og nulre det indtil det bliver godt, men i disse tider hvor der er megen fokus på effektivitet og optimering af processer kan det være svært at få lov til det.

  • 0
  • 0
Peter Makholm Blogger

Jeg vil især fremhæve tre grunde til at jeg får sat dårlig kode i produktion:

En prototype der lige pludselig bliver sat i produktion. Det kan der være flere grunde til, både selvforskyldt og fordi en gren af organisationen ikke lige vidste at det kun var en test...

Nogle gange får kode bare lov til at udvikler sig i for lang tid, inden man får sat det på todo-listen at skrive det om fra bunden af. Og med mindre man har været orakuløst forudsigende kan det let ende med en seriøs knobskydning at lapper.

Og endelig er der tider man skriver for smart kode. Koden selv er smart nok, men man får ikke kommenteret det godt nok til at kunen vedligeholdes. Sidder man lang tid med noget kode og kender det ud og ind bliver man let blind for hvad der egentligt er nødvendigt at kommentere - men efter et par dage har man glemt den smarte lille detalje.

Jeg har ofte fået en kollega til lige at læse et stykke kode og en kommentar igennem for at høre om det gav mening, når jeg har måtte være specielt smart.

  • 0
  • 0
Thomas Jensen

Næ, det er såmænd ikke forkert, men i den "virkelige" verden, sidder man med en projektleder der er mere interesseret i at holde en forretningsbestemt deadline, da det er det han bliver målt, vejet og måske bonuslønnet for, end at koden er smuk og nem at rette senere. For senere er det jo ikke hans problem.

Man ender ofter op med en "quick and dirty" løsning for at honorere en deadline og så bliver man spist af md at man jo altid kan få tiden til at refaktorere senere. Problemet er bare at "senere" aldrig kommer, for så er man på nye projekter.

Det er i hvert fald min erfaring fra de større virksomheder jeg har arbejdet for.

  • 0
  • 0
Dennis Krøger

Initiel hurtighed og genveje skal vel betales tilbage senere i projektet, når den dårlige kode skal vedligeholdes, ændres og udvides?

Helt enig, og refactoring (og dokumentering) er meget nemmere mens koden stadig er frisk i hukommelsen.

Det gælder selvfølgelig også når man skal udvide, men hvis koden allerede er refactored, har man (forhåbentlig) et nemmere/bedre/simplere interface, der er velbeskrevet, og en overskuelig struktur.

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg kan sådan set ikke være mere enig, langt største delen af den kode jeg møder er klytkode i et eller andet omfang, kun sjældent møder man kode som er værd at tage hatten af for.

Der er kun en måde at gøre det bedre på:

Professionalisme hos programmørene.

Poul-Henning

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jeg vil lige bidrage med noget kode, som jeg lige har haft fornøjelsen at sidde og omskrive. Program-stumpen blev lavet, da man ikke kunne løse disse problemer:

  1. Hvordan sikres, at en DataType (.Net 1.1) føres over et WS-interface uden at blive ødelagt

  2. Hvordan laver man en "nullable" DataType (.Net 1.1) så man får mulighed for at kunne afgøre, som en decimal eller DateTime er "valid" eller ej.

Til dannelse af fx en af disse DateTimes blev følgende programstump bla. brugt:

[code=csharp]
public clsDecimal( object d )
{
if( d == null ) return;

if( d is string )
{
// Konverter fra streng med livrem og seler
string s = (string) d;
int i0 = s.IndexOf (",");
int i1 = s.LastIndexOf (",");
int j0 = s.IndexOf (".");
int j1 = s.LastIndexOf (".");
if( i0 != -1 && i1 != -1 && i0 != i1 )
{
// der er to ,
s = s.Replace (",","");
i0 = -1; i1 = -1;
}
if( j0 != -1 && j1 != -1 && j0 != j1 )
{
// der er to .
s = s.Replace (".","");
j0 = -1; j1 = -1;
}
if( i1 != -1 && j1 != -1 && i1 != j1 )
{
// der er både , og .
if( i1>j1 )
s = s.Replace (".","");
else
s = s.Replace (",","");
}
s = s.Replace (",","."); // brug altid .
try
{
NumberFormatInfo nfi = new CultureInfo( "en-US", false ).NumberFormat;
nfi.NumberGroupSeparator = "";
nfi.NumberDecimalSeparator =".";
_value = decimal.Parse ( s,nfi );
_IsNull = false;
}
catch
{
_IsNull = true;
}
}
else if( d is clsDecimal )
{
if( ((clsDecimal )d).IsValid )
Value = ((clsDecimal )d).Value;
}
else if( d is decimal )
{
_value = (decimal)d;
_IsNull = false;
}
else
{
try
{
_value = Convert.ToDecimal ( d );
_IsNull = false;
}
catch
{
_IsNull = true;
}
}
}
[/code]

Efter omskrivning endte funktionaliteten med at kunne implementeres på tre linier i alt.

  • 0
  • 0
Henrik Liliendahl Sørensen

Den med at snyde chefen lyder som en typisk ‘amerikaner’ – de har en hel anden kultur med hensyn til at kontrollere medarbejderne i begge ender.

Som de andre kommentarer også oser af, så er det her i landet i høj grad op til den enkelte medarbejder at sikre sin egen professionalisme – med det ydre tidspres, som den tungtvejende eksterne faktor.

Man skal bare huske på, at mange fejl lander på ens bord senere i forløbet – så tager det bare 10 gange så lang tid at rette op, blandt andet fordi man så måske også skal rette data, som er blevet fejlbehæftet.

Nogle vælger så også her at springe over gærdet, hvor det er lavest.

  • 0
  • 0
Peter Makholm Blogger

Ok, det er let nok at være enige om at vi skriver alt for dårlig kode. Hvordan øger vi kodekvaliteten?

Fjerner tidspresset, selvfølgelig, men kan vi ikek gøre noget for at vi instinktivt skriver bedre kode?

En ting jeg vil anbefale er at bruge tid på at læse andres kode, og her taler jeg ikke bare om kollegaernes kode. Simpelthen får læse kode skrevet af så mange forskellige som overhovedet muligt. Det giver en et meget bedre indtryk af hvad der kode svært at forstå.

Forståelse af kode er selvfølgelig kun en af de dimensioner man måler kodekvalitet på.

  • 0
  • 0
Peter Makholm Blogger

Måske fordi det engelske ord 'art' betyder mere og andet end det danske ord 'kunst'? http://m-w.com/ forklare det blandet andet med:

1: skill acquired by experience, study, or observation <the art of making friends>
2 a: a branch of learning: (1): one of the humanities (2)plural : liberal arts barchaic : learning, scholarship
3: an occupation requiring knowledge or skill <the art of organ building>
4 a: the conscious use of skill and creative imagination especially in the production of aesthetic objects; also : works so produced b (1): fine arts (2): one of the fine arts (3): a graphic art
5 aarchaic : a skillful plan b: the quality or state of being artful
6: decorative or illustrative elements in printed matter

'Kust' er hovesagligt betydning 4 i mit sprogbrug.

  • 0
  • 0
Kristian Østergaard

Der er sjovt, jeg har den helt modsatte oplevelse.
På den arbejdsplads med størst grad af autonomitet og mindst(/intet) tidspres jeg har oplevet, har jeg set noget virkelig mærkelig kode.
Hvorimod at den arbejdsplads jeg har været på med den strengeste styring og til tider enormt tidspres, har jeg set kode som var mesterligt skrevet.

Jeg kan ikke lige forklare det på stående fod, men jeg kan da godt gå og spekulere over det og måske skrive igen.

Nu er jeg jo heller ikke så gammel i gårde, og har ikke set uhyggelig meget kode.

  • 0
  • 0
Peter Makholm Blogger

At stor autonomitet og intet tidspres giver kode af dårlig kvalitet undrer mig egentligt ikke.

Det er de færreste af os der er gudsbenåede programmører, og for at blive gode programmører skal vi jævnligt mindes om dette. Det sker oftes kun hvis der kommer et pres udefra - enten fordi ens ligestillede skælder en ud over underlige kode elelr at man kæmper mod en deadline fordi man ikke forstår sin egen kode.

Hvis man har tid nok og ens kode ikke bliver udfordret, så bliver ens kundskaber aldrig forbedret.

  • 0
  • 0
Peter Makholm Blogger

Nej, det primære formål med programmering er ikke at frembringe 'æsthetic objects'. Men som de fleste andre håndværksfag er der en niche der handler om æstetik.

Møbelsnedkeri er lige så meget grundlæggende et håndværk, selvom produktet i specielle tilfælde kan betragtes som et kunstværk.

  • 0
  • 0
Peter Makholm Blogger

Nu er det selvfølgelig let at suse ud ad en tangent uden at overveje om den egentlig er relevant for det spørgsmål vi egentlig burde diskutere.

Har det betydning for kvaliteten af vores arbejde om vi betragter professionen grundlæggende som kunst eller håndværk?

Jeg kan ikke umidelbart pege på situationer jeg har forklaret dårlig kvalitet med denne skelnen, men jeg overvejer lidt om det kan have forbindelse med at skrive for smart kode. Er det egentlig ikke når jeg er i alt for kreativt og æstetisk undersøgende humør at jeg skriver kode, som jeg efter en ugen tænker at det var nok 'for smart'?

  • 0
  • 0
Søren Hilmer

Ja, det mener jeg (det var ikke et forsøg på at hijack'e diskussionen).

Min erfaring er at æstetisk smuk kode ofte er den mest effektive (løser problemet på en elegant måde), dette er efter min mening så også høj kvalitet.

Det er efter min mening når kode bare bliver tampet ind som "håndværk", uden at der reflekteres yderligere at programmerne bliver grimme og samtidig af dårlig kvalitet.

Og jeg mener, at det primære mål må og bør være at frembringe 'æsthetic objects', som løser et givet problem.

  • 0
  • 0
Kaspar Lundsby

Min erfaring er, at det meste kodesvineri opstår, når alle parametre i projekt-trekanten (pris, tid, funktionalitet - bl.a. beskrevet her: http://office.microsoft.com/da-dk/project/HA010211801030.aspx#6 ) låses fast. Derfor plejer jeg også at fremlægge denne model som en firkant/fire-takket stjerne, hvor kvalitet er den sidste parameter, og hvor mindst én parameter altid vil være variabel - om man vil det eller ej - som regel netop kvalitetsparameteren.

Dette er især blevet tydeligt for mig, efter jeg er kommet på et (agilt) projekt, hvor det er funktionalitetsparameteren, der bliver skruet på. Det giver mig langt større tilfredshed at aflevere lidt kode af høj kvalitet end meget kode af lav kvalitet.

Til trods for modellens forsimplede tilgang til projektstyringen er det en mærkelig fornemmelse for mig, hver gang jeg som udvikler skal præsentere den for en (projekt)leder...

  • 0
  • 0
Henrik Snog

Jeg har som udvikler i flere større virksomheder forsøgt at få de forhadte timesedler til at afspejle fordelingen mellem (ny)udvikling og spildtid pga. gammel skodkode, men jeg har ikke haft nogen succes. Og modstanden stammer ikke fra udviklerne, men fra ledelsen.

  • 0
  • 0
Henrik Schmidt

Jeg tror ikke på, at det er nok at appellere til den enkelte programmør og "snyde" ledelsen ved at skrive god kode, selvom det ikke er et krav. Jeg vil vove at påstå, at man skal have en ordentlig infrastruktur som støtter op omkring programmøren, før det bliver mindre smertefuldt at skrive god kode, end at skrive mindre god kode.

Præmisset er, at god kode er næsten gratis (tidsmæssigt), så ledelsen når aldrig at opdage, at man bruger tid på kvalitet. Jeg tror, at det giver en besparelse på alt andet end den korte bane, men som udgangspunkt er det ikke min (begrænsede) erfaring, at kvalitet er gratis. Det går meget hurtigere at banke noget sammen som virker, indtil nogen ændrer et komma i specifikationen.

Automatiserede tests nævnes som et eksempel på et værktøj, som kan benyttes til at skrive bedre kode. Det er der altså ikke meget sjov ved, med mindre tests er tænkt ind i måden man bygger og deployer på. Andre ting, som jeg kan komme i tanke om er, at software komponenter skal være nemme at dele imellem projekter, og at der skal være en ordentlig versionering af disse. Det er ikke bare nok at bruge versions-styring, man skal også bruge det på en måde, så man kan finde tilbage til den kode, der kører i øjeblikket. Man skal også have lov til at hente produkter udefra, så man slipper for at opfinde den dybe tallerken, hvis der en nogen, som allerede har gjort det meget bedre, end man selv har tid til. På den anden side har ledelsen formentlig et ønske om, at din applikation ikke er alt for eksotisk i forhold til alle de andres, så der er klart et meget vigtigt ledelses-aspekt i det her, og jeg tror ikke man kommer nogen vegne uden den.

Men at det så er den enkelte udviklers ansvar, at få belyst selve processen over for ledelsen og hinanden, det kan jeg godt gå med til.

  • 0
  • 0
Kim Højgaard-hansen

En sikker måde at sørge for at vi får endnu mere dårlig kode er at have den holdning som vi ofte møder på mit universitet:

"Kode? Det er noget man får lavet i Indien"

Dermed ingen kredit til os der prøver at kode ordentligt osv, for det tæller ikke. Hvis det kan vises i en simulation, så skal man jo bare tegne noget UML, så kan enhver abe kode det.

Nej, jeg er ikke helt vild tilfreds med at gå på en datateknisk uddannelse hvor man møder den holdning :)

  • 0
  • 0
Therese Hansen

Jeg har flere gange klaget her på bloggen over IT-brancheforeningens holdning til kode som noget man får lavet i Indien og det huer mig bestemt ikke at høre at den holdning også lever på en uddannelsesinstitution - jeg vil meget gerne høre mere.

Hvilken uddannelse er du ved at tage? Er det underviserne som har den holdning eller er det de studerende - eller ledelsen?

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