You Aint Gonna Need It är en sund princip för mjukvaruutveckling, och är dessutom naturligt integrerad i de agila metodologierna: Vi väljer den feature/story som anses viktigast för affärerna och implementerar den. Det andra får lägre prioritet, och implementeras om det behövs. För att införa ett nytt begrepp, låt oss kalla detta makro-YAGNI och likställa med vanlig verksamhetsdriven prioritering.

Lillebror, som jag självklart kallar mikro-YAGNI, är det vi hittar på Wikipedia när vi söker på YAGNI, alltså att endast implementera den funktionalitet som krävs för att lösa det omedelbara problemet, och inte ge sig på generella, framtidssäkra, gärna ramverksbaserade lösningar (på problem som ändå kommer att se helt annorlunda ut om en månad). YAGNI skyddar således mot överkreativitet och feature creeping. Man kan länge diskutera huruvida jagande att ett ‘lokalt minimum” leder till att vi utvecklar bra system, eftersom vi teoretiskt saknar helikoptervyn, men jag tror att ju bättre vi är på refactoring, desto smidigare går det att förflytta sig från design till design och forma systemet i den riktning man vill. Tror man inte på mig, kan jag dra till med ett citat av Kent Beck (tror jag): By not considering the future of your code, you make your code much more likely to be adaptable in the future”. Genom TDD integrerar vi dessutom principen naturligt i vår utveckling, eftersom ingen vill testdriva fram ett helt ramverk om resultatet bara ska bli “Hello world”.

Allt med YAGNI är såklart inte svartvitt och oproblematiskt, och den intresserade kan googla vidare (det finns ett antal relevanta invändningar), för ämnet för inlägget är tredje medlemmen i familjen: den onda tvillingen.

Den onda tvillingen frammanas så klart av onda människor. Dessa människor menar att vi kan tillämpa YAGNI-principen även på kvaliteten, och inte bara på scope. De har nämligen lärt sig att utvecklare älskar att övergeneralisera problem och gör allt i sin makt för att inte leverera affärsnytta. Verktyget mot detta är således: enhetstester – You Aint Gonna Need It, code reviews – You Aint Gonna Need It, infrastruktur för enkel automatisk deployment … Självklart är en del av kritiken befogad – ingen rök utan eld, men det jag försöker komma åt här är behovet av att utveckla den pedagogiska förmågan som behövs för att förklara vad som verkligen behövs och vad som kan tummas på… (och förstå det själv).

Eftersom bloggen är ny och hemlig när detta skrivs, är det ingen som kommenterar inläggen, men om detta inlägg någonsin läses, så är jag väldigt nyfiken på folks erfarenheter.

I alla år har jag tyckt att Law of Demeter har känts som en olustig designprincip. I teorin låter den vettig, men någonting har alltid tagit emot. För dem som inte kommer ihåg principen och inte orkar googla, så betyder den (i korthet) att man bara får göra anrop på ett objekts metoder, men inte dess ingående eller relaterade objekt. Alltså t ex car.turn() och inte car.getWheel().turn(). Detta får till följd att de “yttre” objektet måste tillhandahålla ett gäng delegatmetoder, som i exemplet ovan void turn() {getWheel().turn();}. Förespråkarna menar att detta är ett billigt pris för att reducera klassers kunskap om varandra och öka inkapslingen.

Mina erfarenheter kring delegatbiten är att delegatmetoder inte ser så bra ut i praktiken som i designböckerna. Man får ett gäng till synes meningslösa metoder, ökar en klass ansvarsområde och följaktligen minskar dess cohesion. Testtäckningen sjunker på klassnivå, eftersom delegatmetoder faller inom ramen för “too simple to break”. Detta är ett kosmetiskt problem, men ändå.

Å andra sidan är tanken bakom Law of Demeter att designen ska växa fram underifrån, vilket rimmar väl med TDD, vilket i sin tur med stor förmodan leder till att man verkligen först hade designat den “yttre” klassen, och sedan refactorat in de inre allteftersom de kom att behövas. I bilexemplet hade man förmodligen enligt YAGNI+TDD verkligen först implementerat turn() i bilklassen, och kanske sedan kommit på att en rattklass också behövs.

Å det tredje kan det kanske också vara bra att ha en princip som uttryckligen förbjuder spagettiprogrammering (här tänker jag främst på program skrivna i VB av någon anledning), speciellt om man lär ut programmering.

Man kan också vända på steken och fråga om trotsande av Law of Demeter är ett problem i praktiken. En någorlunda bra programmerare kommer inte att skriva spagetti, dels för att det är fult, dels för att koden blir svår att testa; det blir svårt att rigga alla relationer i testfixturen…

Enmannajuryn är långt ifrån enig, men det är ganska kul att ha strukturerat sina tankar kring denna princip i skrift. Droppa gärna en eller flera kommentarer om denna designprincip.