Artefakt betyder "konstgjort föremål". De uppstår inte av sig själva eller utifrån naturliga processer. Det finns alltid en intention bakom en artefakt. En artefakt kan inte heller fullständigt förklaras utifrån den miljö och det sammanhang den kommer ifrån. För att fullt ut förstå en artefakt måste man fråga dem vars intention ligger bakom skapandet av den.
Vår civilisation är uppbyggd av artefakter. Utan dem hade vi fortfarande gått runt på savannen och samlat kottar. Artefakter har uppenbarligen sina fördelar: Vi har hus som vi kan vila i när vi har gått på savannen och samlat kottar en hel dag. Vi har prydnadshyllor att lägga kottarna på, och vi har bilar så att vi kan nå längre ut på savannen och hämta de större och finare kottarna som finns längre bort, bara för att ta några exempel. Men i programkod är artefakter av ondo. Perfekt ren kod är fri från artefakter. Perfekt ren kod är självförklarande, eller som Ward Cunningham uttrycker det i Robert C. Martin's bok Clean code: "Du vet att du arbetar med ren kod när varje rutin du läser på det hela taget är vad du förväntar dig".
Kod som är självförklarande, eller "på det hela taget vad du förväntar dig" utifrån sammanhanget och kraven, har inga artefakter. Hade där funnits artefakter så hade det också funnits behov av förklaring. Artefakter föder artefakter, vilket är orsaken till att kod som inte hålls perfekt ren med tiden blir allt mer tungarbetad. En illa döpt variabel är en artefakt, liksom den extra kommentaren som behövs för att förklara den. En överdesignad arkitektur är en artefakt, liksom den extra kod som krävs för att uppfylla den. Kod som innehåller artefakter rostar med tiden, medan ren, naturlig kod håller sig frisk genom att ny kod får spira i gammal kod som multnar bort i ett ständigt kretslopp.
Att känna igen en artefakt är inte det lättaste, vilket förklarar varför även den mest samvetsnoggranne programmeraren har så svårt att hålla sin kod ren. Alla har sina fix och trix, förkärlekar och käpphästar, som kan kännas fullständigt naturliga för en själv men för andra framstår som de artefakter de är. Någon kanske vill ha ett kommentarsblock före varje metod, oavsett om det står något i det eller inte, eller en kommentar om varje in- och utparameter, oavsett om de tillför förklaringsvärde eller inte. Sådant är artefakter. Någon annan kanske inte tycker det är så noga om det finns en eller två eller tre radbrytningar mellan metoder och block, eller om en och annan bortkommenterad kodrad ligger kvar. Men varje onödigt tecken är skräp, a.k.a. rester av en artefakt. Ytterligare någon kan ha en förkärlek för fabriker och gränssnitt. Men om varje klass har sin egen fabrik och sitt eget gränssnitt så är det mycket troligt att några av dessa är artefakter.
Det enda sättet att upptäcka artefakter i sin egen och andras kod är genom kodgranskning. Att granska sin egen kod före varje incheckning och ta bort de artefakter man hittar är nödvändigt, men inte tillräckligt. Vi måste också granska varandras kod. Ju mer olik din och din kollegas kodstil är, desto nyttigare är det att ni granskar varandras kod. Incheckad kod ska se ut som om den hade uppstått som en naturlig följd av de interna och externa krav den har att uppfylla. Incheckad kod ska vara fri från personlig stil, fri från artefakter. En professionell programmerare avhåller sig från att sätta sin personliga prägel på koden. "Don't be clever". "Don't be cute."
För att hålla sin kod fri från artefakter måste du hålla ditt ego utanför arbetet. Det är inte din intelligens som skapar koden. Det är kraven som skapar koden. Du är endast jordmånen som tillåter koden att växa. Du vill att koden ska växa sig så rak och stark som möjligt för att uppnå sin fulla potential. Men försöker du styra den så böjer du den bara. Du kanske är expert på WCF, MVC, SQL, eller någon annan TBA. Bra! Det ger koden en rikare jordmån att växa i; Men låt koden välja var den vill växa utan att försöka påverka den. Lämna alltid ditt ego och dina egna ambitioner utanför processen. Och lyssna på dina kollegor som pekar ut de artefakter som just du är blind för.
Vår civilisation är uppbyggd av artefakter. Utan dem hade vi fortfarande gått runt på savannen och samlat kottar. Artefakter har uppenbarligen sina fördelar: Vi har hus som vi kan vila i när vi har gått på savannen och samlat kottar en hel dag. Vi har prydnadshyllor att lägga kottarna på, och vi har bilar så att vi kan nå längre ut på savannen och hämta de större och finare kottarna som finns längre bort, bara för att ta några exempel. Men i programkod är artefakter av ondo. Perfekt ren kod är fri från artefakter. Perfekt ren kod är självförklarande, eller som Ward Cunningham uttrycker det i Robert C. Martin's bok Clean code: "Du vet att du arbetar med ren kod när varje rutin du läser på det hela taget är vad du förväntar dig".
Kod som är självförklarande, eller "på det hela taget vad du förväntar dig" utifrån sammanhanget och kraven, har inga artefakter. Hade där funnits artefakter så hade det också funnits behov av förklaring. Artefakter föder artefakter, vilket är orsaken till att kod som inte hålls perfekt ren med tiden blir allt mer tungarbetad. En illa döpt variabel är en artefakt, liksom den extra kommentaren som behövs för att förklara den. En överdesignad arkitektur är en artefakt, liksom den extra kod som krävs för att uppfylla den. Kod som innehåller artefakter rostar med tiden, medan ren, naturlig kod håller sig frisk genom att ny kod får spira i gammal kod som multnar bort i ett ständigt kretslopp.
Att känna igen en artefakt är inte det lättaste, vilket förklarar varför även den mest samvetsnoggranne programmeraren har så svårt att hålla sin kod ren. Alla har sina fix och trix, förkärlekar och käpphästar, som kan kännas fullständigt naturliga för en själv men för andra framstår som de artefakter de är. Någon kanske vill ha ett kommentarsblock före varje metod, oavsett om det står något i det eller inte, eller en kommentar om varje in- och utparameter, oavsett om de tillför förklaringsvärde eller inte. Sådant är artefakter. Någon annan kanske inte tycker det är så noga om det finns en eller två eller tre radbrytningar mellan metoder och block, eller om en och annan bortkommenterad kodrad ligger kvar. Men varje onödigt tecken är skräp, a.k.a. rester av en artefakt. Ytterligare någon kan ha en förkärlek för fabriker och gränssnitt. Men om varje klass har sin egen fabrik och sitt eget gränssnitt så är det mycket troligt att några av dessa är artefakter.
Det enda sättet att upptäcka artefakter i sin egen och andras kod är genom kodgranskning. Att granska sin egen kod före varje incheckning och ta bort de artefakter man hittar är nödvändigt, men inte tillräckligt. Vi måste också granska varandras kod. Ju mer olik din och din kollegas kodstil är, desto nyttigare är det att ni granskar varandras kod. Incheckad kod ska se ut som om den hade uppstått som en naturlig följd av de interna och externa krav den har att uppfylla. Incheckad kod ska vara fri från personlig stil, fri från artefakter. En professionell programmerare avhåller sig från att sätta sin personliga prägel på koden. "Don't be clever". "Don't be cute."
För att hålla sin kod fri från artefakter måste du hålla ditt ego utanför arbetet. Det är inte din intelligens som skapar koden. Det är kraven som skapar koden. Du är endast jordmånen som tillåter koden att växa. Du vill att koden ska växa sig så rak och stark som möjligt för att uppnå sin fulla potential. Men försöker du styra den så böjer du den bara. Du kanske är expert på WCF, MVC, SQL, eller någon annan TBA. Bra! Det ger koden en rikare jordmån att växa i; Men låt koden välja var den vill växa utan att försöka påverka den. Lämna alltid ditt ego och dina egna ambitioner utanför processen. Och lyssna på dina kollegor som pekar ut de artefakter som just du är blind för.
Tack vare missionärer som Robert C. Martin är vi idag många som är medvetna om värdet av att hålla koden ren och fin. Men frågar man två programmerare så är det troligt att de har olika upfattningar om vad ren kod är, eller vad som är ren kod. Om vi flyttar fokus från kodens renhet till hur vi kan frigöra koden från artefakter så blir problemet mer konkret och därmed lättare att lösa. Artefakterna ger svaret på frågan vad som är ren kod och varför vi behöver kodgranskning vid sidan av testtäckning för att hålla koden ren. Så nästa gång du stöter på en artefakt i din eller någon annans kod, fundera på om den alls behövs, och i så fall, vilken som är den naturliga konstruktionen som den kan ersättas med. Med varje artefakt som koden befrias ifrån blir den lite renare, och om du alltid checkar in koden med åtminstone inte fler artefakter än den hade när du checkade ut den så har du receptet för ren kod och ett lyckat projekt.
Kommentera