Jonge ontwikkelaars die van start gaan, horen allerlei tegeltjeswijsheden rondvliegen, maar er is een aantal concepten waar je in de praktijk mee te maken krijgt en rekening mee moet houden - vooral als je de carrièreladder bestijgt en te maken krijgt met de samenloop van business en IT. Dat gaat niet altijd even goed in bepaalde organisaties. Hier zijn 10 dingen om in de gaten te houden.
1. Pas op voor verantwoordelijkheid zonder autoriteit
Als je al een tijdje meedraait in de IT, heb je dit waarschijnlijk wel meegemaakt. Ook in security zie je dit concept veel terug: mensen worden verantwoordelijk gehouden voor bepaalde zaken, zonder dat ze de macht hebben om daadwerkelijk iets te veranderen.
Je kunt het in een extreem voorbeeld zien als de schoonmaker die verantwoordelijk is voor de kwartaalcijfers. Hoe hard hij ook werkt en wat hij ook doet, zijn taken hebben geen enkele invloed op de winstgevendheid van het bedrijf. Als hij naar een vergadering gaat met verkopers, kan hij niets doen om ze meer te laten bellen en als hij bij de marketingafdeling is, kan hij personeel geen opdracht geven om een nieuwe campagne te starten.
Oké, zo erg is het meestal niet, maar vaak zie je een gapend gat tussen waar mensen verantwoordelijk voor worden gehouden en wat ze daadwerkelijk kunnen verbeteren. Dat is een bekende bron van frustratie. Verantwoordelijkheid zonder autoriteit is een belangrijk teken dat de organisatie niet goed functioneert en je ziet dit bijna overal terug. Het is een duidelijke oorzaak van een groot verloop onder het personeel en kan alleen worden opgelost door mensen ofwel meer autoriteit te geven of minder verantwoordelijkheid. Eén van de twee.
2. Val niet in herhalingen
Dit principe slaat in het geval van ontwikkeling dat je één overkoepelend design moet hebben in een systeem. Als je op meerdere plekken een blok code moet knippen en plakken, schort er iets aan het centrale concept en dat moet eerst worden opgelost. Er zijn diverse manieren om dit probleem op te lossen, van het ontwerpen van een goede basisarchitectuur tot codegeneratoren en dependency injection. Maar hoe het ook zij, los dit op.
Dit principe negeren is niet alleen tijdverspilling, het zorgt er ook voor dat de code lastiger te onderhouden is. Een bug in een gekopieerd blok doet zich immers waarschijnlijk ook voor in diverse geplakte blokken en de fix moet op meerdere plekken worden toegepast. Dat niet alleen, beveiligingsfouten worden herhaald op verschillende plekken in de software.
3. Doe het omdat het moet, niet omdat het kan
Implementeer een feature pas als je het nodig hebt, niet als je denkt het nodig te zullen hebben. Want de kans is groot dat je het uiteindelijk niet vereist. Als dat wel het geval blijkt te zijn, kun je het beter op dat moment toevoegen. Onthoud dat we het heden veel beter begrijpen dat de toekomst. Dat geldt voor het leven en dat geldt voor programmeren.
Als je een module ontwerpt en nadenkt over alles dat deze release zou moeten kunnen doen - nu en in de toekomst - en daar rekening mee probeert te houden, kan ik je op een briefje geven dat je met complexe software komt te zitten die dingen ondersteunt die je wellicht helemaal niet gaat gebruiken.
4. Minimum Viable Product
Gerelateerd aan de vorige les is die van het Minimum Viable Product (MVP). Het is beter om ervoor te zorgen dat de software een paar basisdingen heel goed aanpakt dan om iets te creëren met een hoop toeters en bellen die minder goed presteren dan dat basisconcept.
Het product dat voldoet aan de basiseisen om zijn hoofdtaak af te handelen is het MVP. Daarmee is het makkelijker om de toepassing te demonstreren aan gebruikers of klanten, er is minder om aan te pakken als er iets niet klopt en je hebt minder geïnvesteerd als het product faalt.
5. Op te veel paarden wedden
En dit volgt weer uit de MVP: je kunt niet alles zijn voor iedereen. Requirements zijn niet hetzelfde als wensen en hoe meer je product probeert te doen, hoe hoger de kosten zijn en de complexiteit van de software wordt.
Het komt allemaal neer op focus. Grote organisaties met software die zich al een tijdje heeft bewezen kunnen het zich veroorloven om resources te besteden aan 'platforms', maar kleine organisaties moeten vermijden te veel te willen. Zelfs in grote organisaties wordt er ingezet op te veel kleine verdiepingen die samen een diepe kloof vormen tussen een vatbaar product en te complexe code voor het beoogde doel.
6. Test het eerst
Dit zou een no-brainer moeten zijn: in een moderne IDE test je eerst voor je verdergaat. Schrijf eerst een unit-test en genereer daarna je classes en dergelijke. Dat maakt de kwaliteit van de software stukken hoger, omdat het steeds goed te testen is. Daarnaast ga je automatisch andere ontwerpprincipes volgen, zoals Design by Contract (DbC).
7. Design by Contract
Daarover gesproken, je moet van elke routine weten wat het hoort te doen en wat vereist is om dat te bereiken. Dat doe je met DbC, waarbij programmeurs specificaties ontwerpen voor diverse componenten van de software. Omdat onderdelen aan de eigen ontworpen standaard voldoen, weet je wat je van blokken code kunt verwachten en vermijd je problemen met global variabelen en andere issues van het moderne softwaretijdperk.
8. Let op: race-problemen
Een race-probleem is in zijn simpelste vorm als twee threads tegelijkertijd dezelfde variabele willen aanspreken. Als de tweede thread de variabele aanpast terwijl de eerste er gebruik van probeert te maken, krijg je een fout. Een race-rpbleem is daarom in principe een fout in het DbC-ontwerp van de software.
Het is niet altijd mogelijk om dit soort ontwerpfouten op te merken. Dat lukt niet met unit-tests, omdat ze zich meestal af en toe voordoen (als een Heisenbug) en pas onder load. Defensief programmeren en het vermijden van samenwerkende threads zijn goede manieren om deze problemen tegen te gaan.
Concurrency is nou eenmaal moeilijk, dus zelfs met de beste event-driven software, zijn er andere race-problemen die je zult tegenkomen. Blijf hiervoor op je hoede.
9. De wet van Conway
De wet van Conway stelt dat professionele programmeurs gedoemd zijn om software te ontwerpen die lijkt op de interne communicatiestructuur van je organisatie. Je ziet dit al terug in het webdesign van veel bedrijven, die publiceren wat het bedrijf bezighoudt in plaats van wat gebruikers nodig hebben.
Je ziet het bij ontwikkelaars die in gescheiden teams werken: in plaats van een holistisch product, levert dit modulaire software op. Met andere woorden, je kunt de basisstructuur van je software niet goed wijzigen zonder die van het team te wijzigen en dat is vaak veel moeilijker.
10. Fail fast
Dit startup-principe is geliefd in Silicon Valley, maar het is een goede filosofie voor elke branche. In ontwikkeling komt het erop neer dat je software bij fouten gruwelijk moet crashen. Beginners controleren elke variabele op null en vervangen die door een lege string, zelfs als er geen kans is op null. De code draait dus door, zelfs als een onmogelijke en ongeldige situatie zich voordoet.
De beste programmeurs laten de nullpionter-exception gewoon gaan of zorgen zelf voor de fout om het specifieke geval op te lossen.
In projectmanagement betekent 'fail fast' dat je zo snel mogelijk tegen politieke of technische barrières opbotst om te zien of het project in de praktijk haalbaar is. In business betekent 'fail fast' dat je snel begint met opzienbarende plannen om direct te zien of de strategie haalbaar is in plaats van langzaam investeren om tegen een mogelijk falen op termijn aan te lopen.
-
-
Er zijn nog geen reacties.Reageer
Preview