De flesta och vanligaste misstagen man gör när man programmerar är konstruktionsfel, tankefel, designfel, eller vad man nu vill kalla dem. Det är mer vanligt att en programmerar skriver exakt den kod han vill skriva (men det är fel ändå), än tvärt om.
Men om vi ändå skall börja med kodkvalitet är snabba återkopplingscykler och disciplin viktigast. Därför förordar jag (i slumpmässig ordning):
-
Parprogrammering (snabba återkopplingar + en massa annat bra)
-
Kodningsregler (spelar nästa ingen roll vilka, bara det finns en uppsättning regler som alla följer)
-
CI-server (återkopplingar igen) med stop-the-mill-mentalitet (släpp allt annat och fixa felet CI-servern rapporterar)
-
Automatisk kodgranskning medan du kodar (á la IntelliJ eller med någon pluggis till Eclipse). Acceptera bara "grön" kod.
-
TDD
-
Putsa på koden. En del säger att man inte skall ändra sådant som funkar och det är ju rätt i många fall, men man kan ändå alltid rätta stavfel i kommentarer, ändra dåliga variabelnamn och metodnamn, lägga till kommentarer. Det här tar ingen tid eftersom det är något man gör när man läser/bläddrar igenom gammal/andras kod för att förstå den.
Lyfter man blicken från tangentbordet bör man rikta den mot whiteboarden. Det ritas alldeles för litet på tavlan nuförtiden tycker jag. Det är inte BDUF bara för att man ritar ett UML-diagram innan man kodar! Däremot kan man kanske tänka bättre med bubblor, pilar och pseudokod innan man uttrycker sin design i Java-syntax. Det här gör man också lämpligen i par så det är inget annat än parprogrammering, fast framför tavlan.
Man skulle kunna kräva att man har ett klassdiagram och en domänmodell för den lilla del man tänker koda idag innan man sätter sig vid tangentbordet. Att rita på papper eller tavla räcker för tankeprocessen. Något av det hela kan också bli dokumentation (nu svor jag visst i agilkyrkan), men få saker kan få mej att snabbt sätta mej in i kod som ett par rutor och pilar som beskriver den övergripande konstruktionen.
Sammanfattningsvis innan du kodar:
-
Rita på tavlan innan du kodar.
-
Skapa början till och bygg sedan gradvis vidare på en domänmodell.
-
Se till att alla kan domänmodellen.
Vilka är dina bästa tips?
Jag önskar du hade definierat kodkvalité lite mer noggrant. Är det att skriva kod som kan underhållas eller kodkvalité som i minimalt med buggar? Det är förstås långt ifrån samma sak. Wikipedia har en lång lista av olika kodkvalitétsaspekter.
Buggundvikande handlar till stor del om att bry sig om små, små detaljer i koden. Ska det vara < eller <= som looptermineringsvillkor? Att tänka igenom och testa relevanta kantfall, eller skriva bra ramverk som undviker att man behöver tänka på sådana detaljer hela tiden.
Om man menar kodkvalité på ett plan som att skriva kod som har lite teknisk skuld och kan underhållas med hög velocity så är det till stor del rimliga tips. Men det viktigaste är nog ändå att man ska bry sig om koden och vilja göra den vacker.
PS. Även om en blog är ett friare skrivsätt, så känns det ändå lite märkligt med fem stavfel i ett så kort inlägg om kvalité (programmerar, diciplin, regeler, variablenamn och aldeles ser jag i skrivande stund). Eller är jag bara en hopplös pedant? 🙂
Ha ha! Tack Henrik för dina rättelser och kommentarer. Du är inte alls någon hopplös pedant. Jag borde ha kört stavningskollen. Förhoppningsvis har jag rättat de värsta grodorna nu…
Håller helt med om att det handlar mycket om att bry sig om koden. Det är ett bra sätt att uttrycka det hela.
Den här gången försökte jag hålla definitionen av kodkvalitet medvetet lös och hellre rikta in mej på praktiska tips.