Rubber duck debugging is een simpele techniek waarbij een developer zijn code hardop uitlegt, stap voor stap, om een bug te vinden. Er komt geen slimme tool aan te pas. Het vertragen en de logica in gewone woorden gieten brengt de fout aan het licht, vaak nog voordat je de zin hebt afgemaakt.
De naam komt uit een bekend programmeerboek waarin een developer een badeendje op zijn bureau hield en elke regel code eraan beschreef. Het klinkt onnozel, maar het werkt om dezelfde reden dat een probleem doorpraten met een vriend helpt: je wordt gedwongen het gat onder ogen te zien tussen wat je dénkt dat de code doet en wat hij werkelijk doet. In dat gat zitten de meeste bugs, en het maakt dit een van de goedkoopste debugging-gewoontes die een developer kan opbouwen. Het is ook het alledaagse neefje van pair programming, waar een tweede persoon het eendje speelt en terugpraat.
Waarom helpt hardop praten als stil herlezen dat niet doet? Bij het lezen van je eigen code vult je brein in wat je bedoelde, dus je glijdt langs de regel die echt kapot is. Hardop praten dwingt je elke stap op volgorde te verwerken, helemaal, zonder sluiproutes, en daar struikelt een aanname eindelijk over de werkelijkheid. Veel developers zien de bug al halverwege de uitleg en komen nooit bij het einde.
De luisteraar kan van alles zijn: een collega, een schrift, het echte eendje. Wat telt, is dat je de logica uitlegt alsof het tegen iemand is die nergens van weet, want dán komen je verborgen aannames eindelijk boven.
Bij TopDevs leunen we op simpele gewoontes als deze naast formele reviews, want een bug die je in vijf minuten uitpraat is veel goedkoper dan eentje die je in productie vindt.
