Robert Martin (die ook schrijft onder de naam Uncle Bob) is een geweldige spreker en een wereldberoemd schrijver van publicaties over software craftmanship. Hij is dermate gepassioneerd over het op een hoger niveau brengen van ons vak, dat hij zelfs voor een groepje jonge engineers die de schoolbanken nog niet hebben verlaten een vlammend betoog komt houden.

Hij raasde in een uur tijd door zijn slides over Clean Code heen, lardeerde dat met leuke verhalen en analogieën en onderbouwde zijn betoog met praktijk voorbeelden. Hieronder een greep uit de tips die we kregen over het schrijven van functies.

Leesbaarheid

Eigenlijk gaan alle onderstaande tips over de leesbaarheid van de code. Iemand die jouw code ziet (en dat kun je ook goed zelf zijn) moet met lichte verveling van boven naar beneden door je code kunnen gaan, waarbij de code steeds gedetailleerder wordt.
- “Ja”
- “Mmmh, mmh”
- “Duidelijk”
- “Ja”
- “Logisch”
Totdat de code een nivo van detaillering bereikt dat je als lezer denkt “Ja, ja, nu begrijp ik het wel. Saai”. Dan heb je het goed gedaan. Saaie code, waar niemand lang bij hoeft stilt te staan (want daar heb je gewoon geen tijd voor). Niemand zit te wachten op briljante code, behalve jouw ego. Briljante code is de eerste code die ik vervang als ik onderhoud moet doen; vervang door saaie, begrijpelijke code.

Descriptive names

Gebruik een naam voor je functie die zegt wat de functie doet. Dus niet “Process()” maar “AddOrderLineToOrder()”.

Do One Thing

Een functie moet slechts 1 ding doen. Als een functie 2 dingen doet, moet je ‘m in 2 functies opdelen. De functie “AddOrderAndCalculateTotals()” wordt dan dus “AddOrder()” en “CalculateTotalsForOrder()”.

Small functions

Functies mogen niet meer dan 4 regels lang zijn (tussen de accolades). Het liefst 2 of 3, maar als het echt moet dan kan 4 ook. Een functie moet eigenlijk niet veel meer doen dan bijvoorbeeld een test uitvoeren in een if-statement en dan een andere functie aanroepen. En de test in de if is natuurlijk ook een functie.
Hoe kom je aan kleine functies? Die kun je niet van scratch af aan maken. Je maakt eerst je bekende grote bak code van wel 20 of 30 regels, zodat je je test aan de praat kan krijgen (je weet wel “Red-Green-Refactor”). Daarna ga je je grote functie opknippen met een van de standaard Refactor-tools die jouw IDE ondersteunt, meestal “ExtractMethod” geheten. En na elke ExtractMethod draai je je tests om te weten of je niets stuk gemaakt hebt.

No error codes

Functies moeten exceptions gebruiken en try/catch blocks. Binnen een try moet bij voorkeur 1 regel code staan: de aanroep van een functie.
Return-codes zijn om iets nuttigs terug te geven aan de aanroepende code, bijvoorbeeld een Boolean als je functie “IsValidDate()” heet, maar niet om te laten weten dat er iets is mis gegaan. Error-codes leiden tot veel geneste if’s en tot out-parameters (zie verderop).

No more than 3 parameters

Een functie heeft bij voorkeur geen parameters, dat leest het makkelijkst, maar is niet zo realistisch. Als een functie meer data dan 3 parameters nodig heeft om zijn werk te kunnen doen, moet je gaan refactoren. Waarschijnlijk hoort al die data bij elkaar in één class.

No out-parameters and no boolean-parameters

Een functie heeft dingen aan de rechterkant (parameters) die erin gaan en een ding aan de linkerkant (return-value) die eruit komt. Als er dingen aan de rechterkant uitkomen verwar je de lezer enorm. Tijd voor een refactoring.
Booleans lezen helemaal moeilijk en verraden dat je eigenlijk een functie hebt die 2 dingen doet, gestuurd door de vlag die je erin stop.
Wat doet het onderstaande?

var html = GetHtmlForControl(button, true)

Zou het niet beter zijn om 2 functies te hebben die beter laten zien wat ze doen?

private string GetUnformattedHtmlForControl(button)
{ ... }
private string GetFormattedHtmlForControl(button)
{ ... }

Unit tests

Als je geen unit-test hebt kun je nooit bewijzen (voor jezelf, je teamgenoten of je baas) dat de code die je gemaakt hebt echt werkt.
Accountants controleren hun eigen werk door elke boeking 2 keer op te nemen: één keer aan de debet kant en één keer aan de credit kant. Onderaan moet dan nul staan. Je kunt nog steeds de pech hebben dat je twee fouten hebt gemaakt die elkaar precies opheffen, maar die kans is niet zo groot. In ieder geval heb je een Standard Practice toegepast.
Dat kunnen wij software-engineers minstens even goed doen. Code schrijven en tests schrijven.

Design Patterns

Ken je patterns. Het boek van de Gamma et al is volgens Robert Martin het belangrijkste boek dat de afgelopen 20 jaar is geschreven op het gebied van software design.

Maar daar hebben we geen tijd voor!

Je zult het zelf misschien onmiddellijke roepen als je bovenstaande hebt gelezen: “Allemaal leuk en aardig, en ja, ik wil goeie code schrijven, maar het moet af, ik heb hier echt geen tijd voor”.
Fout. Als je het op bovenstaande manier doet, houd je tijd over. Om de simpele reden dat iedereen gedurende het project zijn bestaande code moet uitbreiden, aanpassen, verbeteren of overdragen. Als je clean-code schrijft dan kost dat wroeten in je eigen code je veel minder tijd dan wanneer je de gebruikelijke bak spaghetti heb geschreven. En omdat je unit-tests hebt, weet je ook dat je aanpassing niets stuk gemaakt heeft.

Robert Martin haalde het voorbeeld aan van Hongaarse arts Ignaz Semmelweis die ontdekte dat het aantal vrouwen dat overleed in het kraambed van 8 op de 10 zakte naar 1 op de 100 als je eerst je handen waste nadat je een autopsie had gedaan. Hij begreep niet waarom, maar stelde onomstotelijk vast dat het werkte. Desalniettemin duurde het tot vele jaren na zijn dood voordat deze activiteit tot het standaard repertoire van de arts ging behoren.

Zou jij tegen je chirurg zeggen vlak voordat je de operatiekamer ingereden werd “Laat dat handen wassen maar achterwegen hoor, daar heb je helemaal geen tijd voor”? Vast niet. En omgekeerd? Als jouw patiënt dat zou zeggen, zou je dan naar hem luisteren?
In jouw vak ben jij de chirurg en is je opdrachtgever degene die onder het mes gaat.

Word een professional

Wij zijn geen loonwerkers, ons werk is niet te vergelijken met het op elkaar stapelen van stenen. En onze verantwoordelijkheid gaat verder dan “maar hij heeft gezegd dat dat zo moest”. Als professional heb je de plicht om tegen je opdrachtgever/klant/baas “nee” te zeggen als hij/zij vraagt om iets slechts af te leveren.
- “Kun je het niet zonder tests?”
- “Nee”
- “Maar daar hebben we geen tijd voor!”
- “Dus er mogen bugs zitten in mijn werk?”
- “Uh, nou ja, het hoeft niet perfect te zijn”
- “Als er bugs in mogen zitten, dan ben ik klaar wanneer je wilt. Nu al, feitelijk”
- “Kom op, je begrijpt best wat ik bedoel”
- “Nee, wil je nou dat ik m’n handen was of niet?”
- …..?

• What is your definition of software architecture?
• How is software architecture positioned in your organization (value and benefits)?
• …

(There were more questions; ask us to invite Dana again if you want to know them all )

Usually, to such a list of questions you really find some (sometimes shallow) answers to work with but the ones Dana posed really got me started on the role of software architecture in general. What indeed is a good definition of software architecture ? Is the value of (good) software architecture a measurable entity ? I think not. Many times during the course of the workshop I pondered about quality and got thrown back to college time when I read “Zen and the art of motorcycle management”, that also addresses the notion of quality: That what you just like. Is that enough ? Certainly not ! With respect to software architecture it also counts if the product (or products) that is (are) based on the architecture even get to production state and actually start adding value for your company. If they do not, then it has all been in vain…

Many issues like these got addressed during the workshop. Also the political forces that influence technical decisions where explained with such clarity that my understanding of what it takes to be a good software architect (and what personal skills I lack !) has grown enormously.

In short, a must-attend workshop for all stakeholders to the process of employing software to extend business for a company: manager, CEO, CFO, engineer and last but certainly not least the architects.