clean code
- ons 13 aug, 2008 kl 22:26
- 8 kommentarer
- Allmänt, Konferenser, Programmering, TDD
”All you have to do is change a 5 to a 6, how hard can it be?!”
Kunden verkar vara lite irriterad. Han blickar frustrerad runt salen där jag och några andra hackers stirrar missnöjda på våra skärmar. Ingen har kunnat fixa hans program inom den utsatta tiden på 30 minuter. Som kunden ser det är det en enkel förändring. Det är en liten applet som spelar tic-tac-toe. Man behöver 5 i rad för att vinna, men det är för svår att besegra. Kunden vill att datorn ska behöva 6 i rad för att vinna medans han fortfarande behöver 5.
När man tittar på koden är det allt annat än en enkelt förändring. Det ryktas om att koden skrevs ursprungligen på serbiska. Eller C. Eller båda två. I alla fall är det nu en enda stor Java class med massor med global control flags, nested loops och håriga långa metoder. Suck. Jag sjunker ner i stolen och tänker – det här kan ta flera dagar att fixa.
Lyckligtvis är det här scenen inte hela sanningen. I verkligheten heter ”Kunden” Patrick Wilson-Welsh, som är själv en skicklig programmerare, och jag sitter i en ”Clean code clinic” på agile2008. Nu ta Patrick fram en annan kodbas för oss att jobba med. Det är också en applet som spelar tic-tac-toe, och om man bara titta på UI:et ser det precis likadan som det första. Under huven är det helt annorlunda dock. Det finns Java packages som heter ”model”, ”view”, ”controller”. Klasserna är småa med bra namn som ”Board” och ”Move”. Det finns till och med omfattande enhetstester. Inom en halvtimme har de flesta i rummet klarat av att ändra koden efter kundens önskemål.
(Vill du testa själv, tic-tac-toe koden finns att ladda ner här)
Alla programmerare som har jobbat ett tag förmodligen känner igen sig. ”Clean code” är bra för båda kundens tidsplan och programmerarnas mental hälsa. Hur kan det uppnås? En bra början vore att läsa Bob Martins senaste bok. Tänk efter, prata med kunden om ”technical debt”. Be a professional. Vi har inte råd att bygga flera produkt där det tar flera dagar att ändra en 5 till en 6.
Låter kul det där Emily!
Håller verkligen med till 110% om att ‘clean’ kod är superviktigt. Viktigare än att koden fungerar t.o.m.!
”Clean Code That Works” är ju Kent Becks klatschiga sätt att uttrycka detta på: ‘Clean’ i första hand och ‘Works’ i andra hand.
Läste någonstans att en genomsnittlig rad kod ändras ca 12 gånger under sin livstid (hur man nu mäter det…). Detta skulle innebära att det faktum att koden fungerade felfritt som ‘nyfödd’ tillför nästan ingenting på lång sikt.
det du säger där låter lite eXtreme ;-)
Kent är underbar med sina kontroversiella åsikter som få en att tänka till. Jag tycker dock att man ska satsa på båda ‘Clean’ /och/ ‘works’. :-)
Jovisst, naturligtvis är det både Clean och Works som gäller, men om jag måste välja bort en av dem i kod som jag är ansvarig för, så är det Works som ryker. Allt i långsiktighetens ärade namn! :-)
Hur jag än vrider och vänder på det hela förstår jag inte hur Works kan välja bort. Om det inte fungerar är det ju inte användbart, bortkastade pengar.
Works måste alltid komma först.
Mina vänner, ni missförstår mig! Eller, mer troligt, jag uttrycker mig oklart…
Jag menar naturligtvis inte att koden inte behöver fungera. Vad jag menar är att LÅNGSIKTIGT så är KOSTNADEN för ett system som inte fungerar (just nu) men är snyggt kodat, mycket lägre än för ett system som råkar fungera just idag, men ser ut som skit under ytan. Därför menar jag att Clean har ett högre värde än Works. Långsiktigt!
Underförstått här är ju också att ”inte fungerar” betyder ”nästan fungerar”, eller iallafall att det är kodat för att lösa nästan rätt problem.
Mycket underförstått här :)
I skolan fick jag lära mig att ett system i regel har en kostnad där 20 % ligger fördelad under utveckling och 80 % under driften,
Med bra kod dras driftskostnad (förändring, buggfixning..) ner markant (som Emily beskriver) utan att kostnaden för utveckling ökar lika mycket.
Därför borde Clean code prioriteras före Works om kostnaden får styra (vilket den oftast gör?).
Personligen tycker jag att man ska prioritera Clean code mycket högt. Men jag tycker att man även bör ta ”människan” i akt, dvs verkligheten. Ta en stor avdelning(irl) med många utvecklare. Ca 10% är passionerade och duktiga kodare, resten bryr sig inte egentligen. Här har vi ungefär samma syndrom som när man pluggade där de flesta egentligen ville bli ”projektledare”. En sådan här avdelning kodar inte clean code hur mycket man än vill(tyvärr). Om man inte prioriterade Works högs, skulle inte bara dem 90% Puke-vänner bli arbetslösa men även dem där 10% passionerade talangfulla kodare.
Sammanfattat menar jag att verkligheten är oftare ett kvalitativt underverk med mjuka negativa faktorer som ofta vinner.