Tag communicatie
Refactoring als communicatiemiddel
We refactoren niet alleen om het makkelijker te maken de code te wijzigen, we refactoren ook om de code zo helder mogelijk te laten communiceren. En code die helder communiceert is op zijn beurt weer makkelijker om te wijzigen.
Wat zegt deze test?
“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.
Wat zegt deze code?
De namen in onze code – van variabelen, velden, methoden, parameters – beschrijven wat de code doet. De naam van een class beschrijft haar wezen: integer, Url, ResourceHelper. Anders dan bij mensen gaat de existentie van code niet vooraf aan haar essentie. Code is bepaald, bepaald door haar functie. Wat die functie is, weet een goede programmeur in een naam te vangen.
De edele kunst van het pull request
Veel ontwikkelaars zien code reviews als een hinderlijke onderbreking van hun werkzaamheden. Maar het goed kunnen beoordelen van een codewijziging is essentieel om de kwaliteit van een codebase op peil te houden. Gelukkig hoeft dit proces niet pijnlijk te zijn. Aan het eind van deze sessie weet je welke vragen je moet stellen voor een geslaagde code review – en hoe je deze informatie zo effectief mogelijk overbrengt in je PR.
Formuleer je kernwaarden
Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.
De verplichte ChatGPT-blog
Met hulp van ChatGPT wist ik in een uurtje het functionele equivalent te leveren van code waar ik eerder dagen op heb zitten zwoegen. De tijdwinst is onomstotelijk. En op het vlak van informatieoverdracht is ChatGPT een ons “echte” ontwikkelaars mijlenver vooruit.
Waarom zou je manager jouw conferenties betalen?
Het is niet voldoende om te zeggen: “Ik wil graag naar die en die conferentie.” Als de manager van je manager vraagt om die kostenpost te verantwoorden, wat moet hij dan zeggen?
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.