Intressant om YAGNI-designregeln

Hittade en intressant bloggartikel om YAGNI-principen för design av mjukvara: You Ain’t Gonna Need It. Det är en princip som jag tagit till mig sedan några år tillbaka och är starkt positiv till, en av mina tre “programmeringsdygder”, tillsammans med DRY (Don’t Repeat Yourself) och KISS (Keep It Simple, Stupid!). Den sista är iof. närbesläktad med YAGNI, kanhända droppar jag den ur listan en dag..

Taggar: programmering, YAGNI

Konjunkturdynamik

Funderade på konjukturcykeln idag. Kom på följande lösa idé: i högkonjunktur utnyttjas vinstbringande mekanismer till fullo - plattan i mattan. Ett sådant system innehåller säkerligen icke-hållbara delar, t.ex. människor som “bränns ut” pga. det höga tempot och leveranskraven. Nyckelpersoner alltsomoftast. Till sist spricker en länk i kedjan - och andra delar av systemet belastas än mer. Som ringar på vattnet fortplantar sig sprickorna och snart är hela företag i gungning. De icke-hållbara delarna faller isär och vi är inne i en lågkonjunktur. Nya strukturer tar form och vi är på väg upp igen.

Diktatur Sverige

Korttids-todo

Ofta när jag sitter och programmerar, stör jag mig på någon liten detalj. Det kan vara ett API som är konstigt namngivet, en parameter som är svår att förstå, en färg på GUIt eller vad för någon liten detalj som helst.

När det sker blir ofta resultatet en liten minnesanteckning i huvudet: “Fixa - Sen“. “Sen” är det viktiga ordet här. Det där sen har en tendens att dra ut på tiden! Det kommer annat emellan nu och “sen”.

Så idag prövade jag en ny kodvana. Jag öppnade ett tomt dokument i OpenOffice, och såfort jag fick den där irritationen i mitt sinne, skrev jag ned en kort punkt om det i dokumentet, en enkel todo-lista alltså.

När jag under dagen fastnade på något problem, eller blev klar med något, skummade jag igenom listan och tittade efter om det fanns någon liten punkt att fixa, och åt upp den.

Fördelarna som jag upplevde direkt var att jag avlastade mitt korttidsminne, slapp hålla reda på listan samtidigt som jag grötade ner mig i något annat tekniskt problem. Nackdelen är att det tar lite tid att formulera en punkt. Billigt pris för att avlasta min stackars hjärna!

Läs andra bloggar om programmering, metod, todo, feedback

“Caribbean blue”

Läs andra bloggar om musik, enya

“When you were young”

Läs även vad andra bloggar om musik, youtube, thekillers

Ett BDD-experiment, observation ett

Jag började uppifrån-och-ned, som är tanken i BDD. Då blev jag satt i följande situation:

1. Indata till NAutoDoc är en sökväg till en mapp som ska scannas.
2. Utdata från NAutoDoc är en HTML-fil.

Försökte mig på detta i kod:

public interface IFileWriter {
  void WriteFile(string path, string content);
}

[Test]
public void NoInputFilesDoesNotProduceAnOutputFile()
{
  // Dependency
  DynamicMock fileWriter = new DynamicMock(typeof(IFileWriter));
  fileWriter.ExpectNoCall("WriteFile");

  // SUT (subject under test)
  TestDocGenerator gen = new TestDockGenerator(
    (IFileWriter)fileWriter.MockInstance,
    "somepath");
  gen.GenerateReport("report.html");

  fileWriter.Verify();
}

Men här låser det sig i min hjärna: hur specificerar jag att “somepath” inte innehåller några filer? Jag tänkte mig att TestDocGenerator skulle instansiera någon “filescanner”-klass mha. “somepath” internt, och använda denna för att rekursivt söka igenom en sökväg.

Satt fast med denna problematik nästan en hel dag innan jag kom på mitt tankefel: “somepath” är ett beroende! Det borde alltså mockas, inte instansieras internt i TestDocGenerator!

Försök två blir alltså:

public interface IFileList {
 List<string> GetFiles();
 }
 public interface IFileWriter {
 void WriteFile(string path, string content);
 }

[Test]
 public void NoInputFilesDoesNotProduceAnOutputFile()
 {
 // Dependency
 DynamicMock fileList = new DynamicMock(typeof(IFileList));
 fileList.ExpectAndReturn("WriteFile", new List<string>());
 DynamicMock fileWriter = new DynamicMock(typeof(IFileWriter));
 fileWriter.ExpectNoCall("WriteFile");

// SUT (subject under test)
 TestDocGenerator gen = new TestDockGenerator(
 (IFileList)fileList.MockInstance,
 (IFileWriter)fileWriter.MockInstance);
 gen.GenerateReport("report.html");

fileList.Verify();
 fileWriter.Verify();
 }

Slutsats: att instansiera grejer i konstruktor eller annanstans verkar inte vara BDD-vänligt! Det är detta Michael Feathers kallar ett “internt beroende” i sin bibel “Working Efficiently With Legacy Code” om jag minns rätt. Det är ett hälsotecken; BDD tvingar fram renare kod.

Läs även andra bloggares åsikter om bdd, nautodoc, programmering, tdd

Ett BDD-experiment: NAutoDoc

Har läst om Behaviour Driven Development, artikeln “Mocks Aren’t Stubs” av Martin Fowler först, som gjorde skillnad på begreppen Dummy, Fake, Stub och Mock. Det var den artikeln som fick upp mitt intresse för BDD. Surfade runt ett tag och fastnade för artikeln “A new look at test-driven development” av Dave Astels, en artikeln som verkar ligga på framkanten av BDD. Bland annat så diskuteras ramverket rSpec (Ruby Specification) som låg i sin linda när artikeln skrevs, och bygger på artikelns nya kontext-inriktade synsätt.

I alla fall så håller jag nu på att testa (no pun intended!) detta nya angreppssätt att utveckla programvara. Det lilla experimentet blir en enkel implementation av TestDoc-idéen, dvs. att testkod ofta är bra dokumentation av klasser. Det funkar så här. Säg att vi utvecklar en medelvärdes-klass. Vi bygger ett test som kontrollerar att medelvärdet av “inga tal” inte går att beräkna, och ska ge ett Exception. Så här ser det ut med NUnit:

[TestFixture]
public class MeanComputerFixture {
  [Test, ExpectedException]
  public void CallingComputeWithNoAddsIsAnError() {
    MeanComputer cpu = new MeanComputer();
    double mean = cpu.Compute();
  }
  [Test]
  public void TheMeanOfASingleValueIsTheValueItself() {
    MeanComputer cpu = new MeanComputer();
    cpu.Add(5);
    Assert.AreEqual(5, cpu.Compute());
  }
}

Detta lilla test skulle producera följande “dokumentation” av MeanComputer-klassen:

MeanComputer:
- calling compute with no adds is an error
- the mean of a single value is the value itself

Lite nice, och förhoppningsvis något som är användbart också i praktiken. Planerar köra det på både mitt spelprojekt (Dogfight2008) och på jobbprojektet. (nackdelen som jag ser det är de obekvämt långa metodnamnen…)

Detta känns som ett lagom stort projekt att ta sig an BDD med. Kommer att parsa .cs-filer direkt, och generera en HTML-fil som resultat. Eller varför inte en .rtf-fil..? Har varit sugen på att lära mig .rtf-filformatet då det innehåller page-breaks till skillnad från HTML, något som kan vara riktigt användbart.

Läs även andra bloggares åsikter om bdd, tdd, programmering, nautodoc

Mockobjects

Har börjat läsa om Mock Objects och det som verkar kallas “behaviour driven development“, BDD. Det verkar vara en top-down version av TDD; precis omvänt min erfarenhet av TDD hittills alltså - jag brukar alltid ha en lös idé om min “arkitektur” i huvudet, och så TDD:ar jag fram klasserna på “lägst nivå” först, dvs. bottom-up.

Ska pröva denna metod i kombination men NUnit’s inbyggda mock-object-funktionalitet, se om det funkar i praktiken. Om det gör det, så är det ett paradigmskifte för min syn på systemdesign. Då går nämligen hela systemet att “odla fram” mha. TDD, inte bara enskila “öar”!

Checked examples: bättre namn än TDD..?

Hittade en artikel på nätet om “Exploration Through Example”. Intressant läsning! Speciellt gillar jag hans namn på TDD: checked examples. Han använder också förkortningen “EDD” - Example Driven Development. Det är ett bättre uttryck än Test Driven Development…

Läs även andra bloggares åsikter om tdd, edd, checked examples, programmering