Tag software ontwikkelen
Feature branches belemmeren een beter begrip van koppeling
Laatst brak een kleine wijziging aan de back-end – die we zo snel mogelijk richting de testomgeving hadden gebracht – functionaliteit aan de front-end. Voor mijn collega was het een ideale gelegenheid om zijn bias voor Gitflow bevestigd te zien. “Dit zou nooit gebeurd zijn als we van feature branches gebruik hadden gemaakt!” concludeerde hij. – En niet onterecht, want het apart houden van de wijziging in kwestie zou de functionaliteit op testomgeving inderdaad intact hebben gehouden.
Wie is er bang voor adapterfuncties?
Adapters zijn een bekend ontwerppatroon in de softwareontwikkeling. Toch kwam deze oplossingsrichting niet onmiddellijk bij me op toen ik een stuk code in onze zoekindex begon te refactoren (om van de oorspronkelijke schrijver nog maar te zwijgen!). In plaats daarvan gaven onze eerste pogingen er blijk van koste wat kost te willen blijven werken met de “standaard”-functies. – Waarom?
Het ontologische argument
Onlangs pairde ik met een nieuwe collega. We hadden een refactortaak opgepakt om wat ondoorgrondelijke code rondom onze zoekindex te versimpelen. Ergens halverwege die refactorslag zei hij iets wat mijn aandacht trok.
Een kleine stap voor de code...
Toen een collega van me laatst vastliep op het omschrijven van wat authenticatielogica, sprong ik graag bij. Ik wist immers wat de juiste weg voorwaarts was: heel veel heel kleine stapjes. Maar zo simpel bleek het toch niet te zijn…
Drielagencargocult
Goede abstracties worden niet bedacht. Goede abstracties worden ontdekt. Ze vinden pas het levenslicht als reactie op een concrete vraag van de codebase. Softwareontwikkeling is in wezen een empirische aangelegenheid.
Waar zit de fout?
Mijn collega bracht een argument in dat vaak wordt genoemd als ik mensen vertel over testen via de voordeur: maar door de code direct aan te roepen, geven mijn tests onmiddellijk feedback over waar de fout zit. Als deze tests beginnen te falen, dan weet ik zeker dat daar de fout zit. En dat scheelt tijd in het debuggen van de code. – Maar dat laat de volgende vraag onverlet: is een unittest (waarbij “unit” wordt opgevat als “eenheid van code”) het beste middel om erachter te komen waar de fout zit?
De wet van Postel
Het is niet de verantwoordelijkheid van de aanroepende partij om de input van een functie te schiften opdat er valide waarden worden meegegeven. Een functie moet zo eerlijk mogelijk zijn in wat het accepteert – maar daar waar er speelruimte bestaat is het de verantwoordelijkheid van de functie zelf om de inputs te valideren.
Ik loste het op met een monad
Een soort van monad. Denk ik.
Bind, Map en Match
Ik schrijf al twee jaar op dit blog over functioneel programmeren in C#, dus je zou denken dat ik de basis inmiddels wel een beetje zou moeten beheersen – en toch overkomt het me nog regelmatig dat ik uitroep: och, zit het zo! Zo had ik onlangs – na een hoop gepiel (en een beetje hulp van Scott Wlaschin) – een openbaring met betrekking tot de Map- en Bind-functies.
Gedrag versus structuur
Een systeem dat niet precies doet wat het moet doen, maar wel eenvoudig aan te passen is, is meer waard dan een systeem dat precies doet wat het moet doen maar slechts met grote moeite gewijzigd kan worden. Want het gedrag van een systeem zal veranderen, hoe dan ook. De wereld verandert, en daarmee de wensen van onze gebruikers en stakeholders. Het is onze taak als softwareontwikkelaars om daarop voorbereid te zijn, en een systeem te ontwikkelen dat daarop voorbereid is.