Als bedrijf dat software levert wil je graag dat de software datgene doet wat de klant gevraagd heeft en het liefst zonder bugs. Helaas leven we niet in een wereld waarin alles in een keer wordt opgeleverd zoals de klant dat nodig heeft en is nazorg nodig. Toch is het mogelijk om door middel van een aantal voorzorgsmaatregelen de benodigde nazorg te beperken.
Dit artikel gaat in op een aantal zaken: gewoonten van ontwikkelaars en tools die persoonlijk gebruikt of toegepast kunnen worden, maar ook wat een bedrijf daarin kan betekenen. Aangezien GDK Software veel gebruik maakt van Delphi zullen Delphi ontwikkelaars ook de voornaamste doelgroep zijn. Maar ik denk dat er voor ontwikkelaars die van een andere ontwikkeltaal gebruik maken wel het een en ander uit te halen valt.
Persoonlijk
Allereerst iets over gewoonten! Ik heb het hierbij niet over een goede nachtrust (alhoewel dat zeker aan te raden is), maar over gewoonten tijdens het coderen. Ik heb een lijst samengesteld van ideeën die ik op het Internet heb gevonden, met mijn eigen ervaringen.
Weet wat mogelijk is met de taal waarin je werkt. Ken de standaard libraries. Ik zal eerlijk zeggen dat ik zelfs nu nog (na 6 jaar ervaring in Delphi) functies tegenkom waarvan ik zeggen moet: “Oh?”. Wees op de hoogte hoe je de datum bepaalt dat een maand voor vandaag ligt bijvoorbeeld (IncMonth(now, -1)), of hoe je een string omzet in een getal (StrToInt of StrToIntDef). Als je niet weet wat er allemaal mogelijk is zul je meer op StackOverflow zitten dan daadwerkelijk code schrijven. Overigens: StackOverflow gebruik ik ook. Iedere programmeur zal er zijn weg wel naar vinden, maar gebruik dat meer voor vragen over hoe je bepaalde dingen op zou lossen, dan of er een functie bestaat om een string om te zetten naar een getal.
Probeer van een project alle hints en warnings weg te werken. Als je dit doet zal elke wijziging die een nieuwe hint of warning oplevert direct opvallen. Ik heb gewerkt aan zowel projecten waar het compileren honderden hints opleverde en projecten waar geen enkele hint zichtbaar was. In het laatste geval werkte het veel fijner en geeft ook een wat positiever gevoel aan het einde van de werkdag. Uiteraard wel als de code ook doet wat je wilt
Maak er een gewoonte van om bij elke keer dat je een object aanmaakt direct de code schrijft die het geheugen van dat object weer vrijgeeft! Dus voor elke Create constructor een Destroy destructor! Dit voorkomt echt een hoop zoekwerk wanneer bij het afsluiten van de applicatie ineens een zeer onduidelijke foutmelding naar voren komt.
Voor zover het mogelijk is: schrijf defensive code. Dat wil zeggen dat je er niet bij voorbaat van uitgaat dat een variabele gevuld is, of dat deze een bepaalde waarde heeft. Controleer of deze Nil is voordat je er iets mee gaat doen. Dit voorkomt in veel gevallen foutmeldingen die in productie optreden, omdat jij getest hebt met een testset waar bepaalde aannames in zaten. Door dit te doen ga je ook meer nadenken over de code zelf: zou een gebruiker iets kunnen doen waardoor dit crasht?
Denk goed na over variabelen- en functienamen. Bedenk namelijk dat er een grote kans is dat jij ook eventuele nazorg moet doen op die code. Dat houdt in dat je over een paar weken (of maanden zelfs) die code weer in moet. In de tussentijd heb je al zoveel andere code geschreven dat de oudere code wat op de achtergrond komt. Het zou jammer zijn als je die code opnieuw moet ‘leren’.
Wees niet bang om code aan te passen. Dit kun je doen door regelmatig kleine stukjes code te refactoren en in te checken. Want als je kleine dingen al niet goed durft aan te passen worden grote aanpassingen zeker een probleem. Plus: je krijgt ‘feeling’ voor de code. Bij mij is het sowieso al dat als ik code van een maand oud zie ik vaak al denk: “Heb ik dat echt geschreven? Foei toch” Durf dat te herstellen.
Voordat je een stuk software oplevert doe een programmer test. Daar bedoel ik niet mee: draai de software, stop er een waarde in en krijg de verwachte waarde terug. Maar: ga stap voor stap (debuggen!) door de software zodat je nog een keer kunt controleren of de code die je hebt geschreven correct is. Het geeft meer zekerheid dan een snelle testrun.
Ook een leuke, die lang niet elke programmeur doet: doe elke morgen, voordat je begint te werken een programmeeruitdaging. Er zijn diverse sites waar je dit kunt doen, zoals codewars.com of codecademy.com. Ik heb het zelf een tijdje gedaan en in mijn geval zorgde het ervoor dat ik de dag begon met het gevoel dat ik alles aan kon.
Wat ik zelf gedaan heb en doe: probeer een andere programmeertaal uit. Dit zal wel in je eigen tijd moeten. De werkgever zal niet zo in zijn nopjes zijn als je onder werktijd in COBOL gaat zitten werken, terwijl je geacht wordt schitterende Delphi code te schrijven Maar het voordeel hiervan is wel dat je denkwijze over hoe je programmeeruitdagingen oppakt wordt verrijkt. Zou die reduce functies in functionele programmeertalen ook mooi geschreven kunnen worden in Delphi? En heeft dat een impact op de performance? En vergeet vooral de leesbaarheid van de code niet.
En als laatste in dit (incomplete) lijstje met persoonlijke gewoonten: wees op de hoogte! Krijg een beetje feeling met de SOLID principes. Ken een paar design patterns. Dit geeft zeker een voorsprong in hoe je tegen code en oplossingsrichtingen aankijkt. En als het goed is hebben je collega’s daar ook kennis van en is het veel eenvoudiger om over die code te praten!
Tools en frameworks
Gelukkig hoeven we niet elke applicatie te bouwen met alleen maar de basis libraries. Als dit zo was zou elke project, ondanks dat we Agile werken (toch?), een behoorlijk lange opstarttijd hebben. Er zijn een aantal frameworks, tools en libraries beschikbaar waar voor elk project wat wils bij zit. Ik ga hier niet beschrijven voor wat voor type project welk framework optimaal is. Wel zal ik een lijstje geven van frameworks die ik zelf gebruik in mijn dagelijkse werkzaamheden. Dit zijn dus wel tools gericht op de Delphi ontwikkelaars.
IDE Fix Pack (https://www.idefixpack.de/blog/ide-tools/ide-fix-pack/). Eigenlijk heb ik nog nooit in een Delphi XE IDE gewerkt zonder de IDE Fix pack. Dus echte referenties heb ik niet, maar het doel van deze IDE plugin is het oplossen van performance issues bij compileren en debuggen van je applicatie.
GExperts (http://www.gexperts.org/). Dit is een verzameling tools die voor een Delphi ontwikkelaar enorm veel waarde toevoegt. Er zit zoveel in, dat het een artikel op zichzelf nodig heeft om duidelijk te maken wat je er mee kan. De tools die ik het meest gebruik zijn de grep en component replace tools. Echt een aanrader deze!
DDevExtensions (https://www.idefixpack.de/blog/ide-tools/ddevextensions/). Een plugin die een aantal handige instellingen toevoegt. Waar ik deze in het bijzonder voor gebruik is de Form Designer setting: Sla de Explicit* properties NIET op in de dfm.
MadExcept (http://madshi.net/). Dit is een tool, waarmee informatie over crashes en excepties die op produktie optreden opgeslagen en verzonden kunnen worden naar de ontwikkelaars. Een andere tool die hier uitstekend voor geschikt is is Eurekalog (https://www.eurekalog.com/). Met beiden heb ik gewerkt en ik heb persoonlijk geen voorkeur. Maar 1 van de 2 is zeker handig!
Spring4D (https://bitbucket.org/sglienke/spring4d/wiki/Home). Dit is een Delphi framework dat classes bevat voor verschillende doeleinden: Collections, Dependency Injection, encryptie en nog veel meer! Vaak wordt alleen het Dependency Injection gedeelte belicht, maar zeker de Collections classes zijn zeer handig (denk aan lists met interfaces!)
Database frameworks in combinatie met componenten, zoals de TMS producten (tmssoftware.com) of Devart (devart.com). Ik heb beiden geprobeerd en in beide gevallen werken de componenten zeer goed. In het geval van de TMS producten heb ik ook met het ORM component (Aurelius) gewerkt. Het is een fijne manier van werken: in plaats van SQL queries te moeten schrijven en onderhouden kunnen de queries in code worden samengesteld door het aanroepen van diverse functies. Dit is uiteraard een persoonlijke voorkeur en het hangt uiteraard ook af van het project!
Daarnaast zijn er nog frameworks die losse componenten leveren. Commercieel, zoals DevExpress (devexpress.com) of Open Source zoals de JEDI componenten (https://github.com/project-jedi/jvcl). Beiden zijn een welkome toevoeging tot elk project waar veel GUI componenten in gebruikt worden. Wel is het goed om op te merken dat de componenten het beste samenwerken met componenten uit dezelfde set, dus houdt daar wel rekening mee.
Het grotere geheel
Wat ik nu beschreven heb zijn een aantal mogelijkheden die ontwikkelaars zelf kunnen doen en gebruiken. Natuurlijk profiteert iedereen ervan als dit gedeeld wordt. Daarom ook dit artikel. Maar bedrijven kunnen natuurlijk veel meer betekenen voor hun medewerkers!
Denk aan de diverse events die regelmatig plaatsvinden. En “dankzij” Corona tegenwoordig zelfs online, zodat de mensen niet meer hoeven te reizen. Alhoewel het fysiek bij zulke events aanwezig zijn zoveel toegevoegde waarde heeft. Denk aan de vele gesprekken die je kunt hebben tussen de sessies door met medeprogrammeurs!
Voor bedrijven met een wat krapper budget zijn uiteraard ook mogelijkheden. Wat ik zelf heb meegemaakt in het verleden is we een ochtend per week of per 2 weken met elkaar een hoofdstuk uit een boek behandelden en bespraken. Zo behandelden we het boek “Clean Code” van Robert C Martin. Daarbij spraken we dan ook af welke zaken we daaruit wilden toepassen. Dit houdt je met elkaar ook zeker scherp!
Ook heb ik gewerkt in een bedrijf waar in plaats van het behandelen van een boek een video van Youtube werd gespeeld. De popcorn kwam er nog net niet aan te pas, maar als je daar met z’n allen zit te kijken steek je er echt wat van op! Zeker als het video’s van Uncle Bob zijn. Bekijk hiervoor de website http://cleancoder.com/products maar eens met links naar video’s waarin hij onderwerpen behandelt uit het al eerder genoemde boek “Clean code”.
Maar om niet helemaal over te komen als een Uncle Bob fanboy wil ik toch ook verwijzen naar video’s van Martin Fowler (vaak wat minder Delphi georiënteerd) of gewoon zoeken op een onderwerp. Tegenwoordig staan er een behoorlijk aantal sessies van meer dan een uur op Youtube waar menig programmeur best zijn tijd aan wil spenderen!
Uiteraard zijn ook online cursussen via Udemy (https://www.udemy.com/) of Coursera (https://www.coursera.org/) of Pluralsight (https://www.pluralsight.com/) altijd een goede start. Het voordeel bij deze cursussen is dat er meer technisch op het onderwerp zelf wordt ingegaan dan tijdens sessies van een event. En je krijgt geen vervelende reclames tussendoor!
Belangrijk is denk ik wel dat er ook wat gedaan wordt met de cursussen met de collega’s onderling. Het blijft zoveel beter bij als er over gediscussieerd wordt, dan dat er een aantal filmpjes wordt bekeken en er op de oude vertrouwde manier verder wordt gewerkt. Daarom: houdt elkaar scherp. Dat kan vanuit het management zijn, maar ook collega’s onderling. Met name de codereviews zijn hier heel geschikt voor. Dit zijn de momenten waarop programmeurs die de code niet zelf hebben geschreven naar de code kijken. Misschien heb je wel een ander idee. Houdt die dan niet voor je! Want het gaat wel naar een productie omgeving.
Tot slot
In dit artikel heb ik geprobeerd een aantal zaken onder de aandacht te brengen die een programmeur zelf kan doen om zijn productiviteit te vergroten en daarmee ook de lol in het werk. Maar ook een aantal zaken die een bedrijf kan doen. Ik ga niet zeggen dat ik de wijsheid in pacht heb en er zullen zeker zaken zijn waar sommigen zich niet in kunnen vinden! Maar als er iets is wat jij in je eigen werkroutine kunt opnemen van wat ik heb genoemd dan is dat de moeite die ik in dit artikel heb gestoken al meer dan waard!
