Tag Boeken
Refactoren na Tolstoj
Laatst las ik een verhaal van Lev Tolstoj genaamd Uit de aantekeningen van vorst D. Nechljoedov. Luzern (1857), een verhaal gebaseerd op zijn ervaringen tijdens een reis door Zwitserland. Het is geschreven in dagboekvorm en gaat over een Russische vorst die een nacht verblijft in het Schweizerhof, een prachtig chique hotel in Luzern, Zwitserland. Mij deed het aan refactoren denken. - Ja sorry: beroepsdeformatie!
Tevreden ontwikkelaars én stakeholders dankzij speelruimte
Dit is denk ik voor veel teams een herkenbare situatie: de ene Sprint verbranden jullie achttien effort points, de volgende twintig, de keer daarop vijftien. Wat is dan de capaciteit van het team? Hoe kun je voorspellen wat jullie de volgende Sprint gaan opleveren, als de capaciteit fluctueert van keer tot keer? Het antwoord is: dat kun je niet. Maar in The Art of Agile Development van James Shore vond ik hier een oplossing voor.
De ontwikkelaar als chirurg
Working Effectively with Legacy Code van Michael Feathers staat vol met adviezen waar je cleancodershart een slag van overslaat. Vrijelijk raadt Feathers je aan encapsulatie uit het raam te smijten of onhandelbare methods zomaar tot class te promoveren. Zijn inzichten gaan lijnrecht in tegen alle richtlijnen om goede, onderhoudbare code te schrijven. Het boek is zonder twijfel een aanrader voor elke softwareontwikkelaar.
Legacy code en Test-Driven Development
TDD gaat over het toevoegen van nieuwe features - per definitie. Immers, wie tests toevoegt voor bestaande code is niet test-driven aan het developen. Maar de meeste ontwikkelaars werken helemaal niet aan greenfield-applicaties. Ze slepen zich dag na dag, week na week door het moeras dat we legacy code noemen. TDD lijkt te zijn weggelegd voor de lucky few onder ons die nieuwe applicaties mogen ontwikkelen. De rest van ons mag ploeteren in bestaande drek. Maar die conclusie gaat toch niet helemaal op.
To polyglot or not to polyglot
Laten we aannemen dat sommige programmeerproblemen zich meer voor objectgeoriënteerde talen lenen, en andere meer voor functionele. Is het dan niet logisch om de taal te kiezen die het best bij het probleem past? Het antwoord op die vraag is: ja en nee. Ja, het is verstandig om the right tool for the job te kiezen - dat is een open deur. Maar zelfs als we aannemen dat de ene taal zich beter leent voor het probleem, is het maar de vraag of het verstandig is dat jij die taal nu inzet om dat probleem op te lossen.
Eén test per keer
Ik hou niet van programmeerboeken die van me vragen dat ik onder het lezen code schrijf. Daar kan zo’n boek niks aan doen, ik houd er nu eenmaal van om een boekje op de bank te lezen, ver weg van mijn laptop. Voor één boek maak ik een uitzondering, en dat is Learning Test-Driven Development van Saleem Siddiqui. Dat boek draait namelijk niet om het eindproduct, de code. Het draait om het proces.
Aansluiting (z)onder emoties
Onlangs mocht ik getuige zijn van een mooi moment. In een video-opname van een coachingsgesprek, zei de coachee van één van mijn medecursisten, met een verwonderde trilling in haar stem: “Goh, zo had ik het nou nog nooit bekeken.” Haar coach stelde toen de vraag die, denk ik soms, wordt gezien als de heilige graal onder de coaches(-in-opleiding?): “Wat voel je daarbij?”
Agile en Test-Driven Development
De meeste ontwikkelaars (waaronder ondergetekende!) schrijven als volgt code. Ze bekijken de specificaties en beginnen vervolgens te klungelen. Dat duurt een tijd, totdat ze iets hebben wat werkt. Of dat zo is, verifiëren ze middels handmatige tests. Pas als de code werkt als bedoeld, schrijft men - als het goed is! - een reeks geautomatiseerde tests. Het is een hardnekkig misverstand dat TDD deze praktijk van software schrijven omdraait: eerst de geautomatiseerde tests (meervoud!) schrijven, en dan pas de productiecode. De werkelijkheid ligt wat genuanceerder.
Blog #100!
Een minimijlpaal: dit is mijn honderste blog! In krap een jaar heb ik 80.168 woorden over softwareontwikkeling geschreven, gecategoriseerd onder 112 tags. Het leek me een mooi moment voor een knap staaltje navelstaren, met hier en daar een snuifje zelfpijperij. Bij dezen: tien blogs waar ik met iets van plezier op terugkijk.
Communiceren naast coderen
Veel programmeurs denken dat hun werk begint en eindigt bij het schrijven van code. Helemaal onterecht is dat niet, want het is precies die vaardigheid die hen hun baan heeft opgeleverd. Maar er komt veel meer kijken bij het ontwikkelen van software. Denk bijvoorbeeld aan: bedenken wat je gaat bouwen en hoe je dat gaat doen, het beoordelen van de code van je collega’s, en presenteren wat je hebt opgeleverd aan stakeholders. Zulke taken hebben een gemene deler: communicatie.