Tag Boeken
Een (verre van complete) lijst boekentips
Ter voorbereiding op een praatje, heb ik de lijst aan softwareboeken die ik de afgelopen jaren heb gelezen eens goed doorgelopen. Het resultaat zou als referentiemateriaal kunnen dienen voor een opleidingstraject van junioren binnen een organisatie, of kan als inspiratie worden gebruikt voor een boekenclub, of als gewoon een lijst goede boeken voor wie zijn kennis over softwareontwikkeling bij wil spijkeren.
Over boeken en boekenclubs (3/3)
Dus: je wil een boekenclub starten, maar je weet niet waar je moet beginnen. Dit is een suggestie: begin eens na te denken over een geschikt boek. Lees verder voor een aantal tips.
Over boeken en boekenclubs (2/3)
Een boekenclub is een investering. Elke minuut die ontwikkelaars besteden aan het lezen en bediscussiëren van ideeën over softwareontwikkeling, is een minuut die ze niet kunnen besteden aan het daadwerkelijk ontwikkelen van software. Dat maakt het belangrijk om steun van je manager te hebben vóórdat je een boekenclub begint.
Over boeken en boekenclubs (1/3)
Het beste werkgerelateerde advies dat ik ooit heb gekregen, kreeg ik van mijn eerste manager. Ik was nog maar net begonnen als softwareontwikkelaar en worstelde met de enorme complexiteit die kwam kijken bij het onderhouden van een legacy codebase. Hij zei (ik parafraseer): “Je hebt de ballen verstand van softwareontwikkeling. Houd de vrijdagen vrij voor zelfstudie, en lees eens een boek.”
Wat is refactoring (volgens Hannah Arendt)?
Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?
Koppeling buiten code om
Koppeling is: wanneer een wijziging in het ene systeem een wijziging in het andere systeem noodzakelijk maakt. Wanneer softwareontwikkelaars het over koppeling hebben, dan bedoelen we meestal: in code aan elkaar gekoppelde systemen. Maar twee systemen kunnen ook zuiver functioneel aan elkaar gekoppeld zijn, zonder ook maar één regel code te hoeven delen.
Begin een boekenclub!
Wie software ontwikkelt, leert van zijn fouten. Wie leest over softwareontwikkeling, leert van andermans fouten. Een lust voor lezen is een cheat code die je in staat stellen in rap tempo een betere IT-professional te worden.
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.
Hoge cohesie, losse koppeling
Het mag gerust een cliché heten: bij het ontwerpen van software streven we naar hoge cohesie (high cohesion) en losse koppeling (loose coupling). Met andere woorden: de modules die we ontwerpen moeten inhoudelijk één geheel vormen, en niet onlosmakelijk verbonden zijn met andere modules; wijzigingen in de ene hoek zouden minimale gevolgen moeten hebben voor andere hoeken van het systeem. Systemen met hoge cohesie en losse koppeling worden ook wel modulair genoemd.
Gecompliceerd vs. complex
“Wat maakt code complex?” – Nee: “Wat maakt code nodeloos (of accidenteel) complex?” Dat is de vraag die centraal staat in Vlad Khononovs Balancing Coupling in Software Design. Wat de vraag oproept: wat is complexiteit precies?