Broncode lezen
Laat me je enkele basisvragen stellen voordat we beginnen met een van de belangrijkste software Best Practices die je als ontwikkelaar onder de knie moet hebben.
Je antwoord zal vast ja zijn, maar als ik je nog een extra vraag in deze serie stel:
Slechts enkele softwareontwikkelaars zullen hier positief op antwoorden. Dat komt omdat het lezen en begrijpen van bestaande broncode ook voor professionele ontwikkelaars een inspannende en saaie bezigheid is. Als je iemand bent die vindt dat het lezen van software-broncode een saaie bezigheid is, dan mis je een van de belangrijkste Best Practices die een softwareontwikkelaar in zijn of haar loopbaan zou moeten uitoefenen.
Als je romanschrijver wilt worden, kun je dan zomaar beginnen met het schrijven van een roman? Je zou 100% nee moeten zeggen, je moet zeker honderden romans hebben gelezen voordat je zelf goede romans kunt schrijven. Als je filmscripts wil schrijven voor je beroep, kan je dan een goede filmscript schrijven zonder dat je eerst verschillende andere goede filmscripts hebt doorgenomen? Nogmaals, je antwoord moet nee zijn!!
Dus, als je professionele software-broncode wilt schrijven, hoe kan je deze goede broncode dan schrijven zonder eerst duizenden regels aan broncode te hebben gelezen? Hoe zou je anders kunnen weten wat de beste manier is om broncode te schrijven? Bedenk dat de broncode het daadwerkelijke intelectueel eigendom (copyright) is van de organisatie.
Het lezen van door anderen geschreven broncode geeft ook de gelegenheid om kritiek te leveren op de fouten die zijn gemaakt bij het schrijven van die code. In veel gevallen is het eveneens de enige manier om achter het daadwerkelijk algoritme van een programma te komen. Door te lezen leer je om fouten te herkennen. Fouten die andere softwareontwikkelaars in hun broncode hebben gemaakt. Deze fouten hoef je zelf niet te herhalen.
Er bestaan tegenwoordig heel veel hulpmiddelen voor het beoordelen van broncode van websites in de verschillende browsers. Denk bijvoorbeeld aan het inspecteren van elementen in Chrome. Of de ’toon broncode’ knop om de HTML broncode te achterhalen en weer te geven. Deze hulpmiddelen maken alleen het resultaat zichtbaar en dat is lang niet alle code. De daadwerkelijke broncode blijft verborgen en kan alleen door een programmeur ter beschikking worden gesteld.
Als gevolg van het automatisch genereren van broncode zijn er steeds minder organisaties die aan code-reading doen. Bij het code lezen, ofwel de Fagan inspectie, ofwel de statische programmatest kijken we meestal ook naar de software requirements. Daarom is het lezen van code van belang om vroegtijdig fouten te kunnen vinden. Probeer deze goede gewoonte in stand te houden en blijf broncode lezen.
Er zijn veel opvallende kenmerken van broncode die deze code leesbaar en toegankelijk maken. Denk aan inspringen, opmerkingen, verklarende teksten, de geschiedenis in de kop, het gebruik van variabele benamingen, algoritme, functiestructuur, enzovoort. Het toepassen van deze Best Practices wordt vaak door middel van een handleiding binnen ontwikkelorganisaties voorgeschreven. We kunnen het onszelf aanleren door binnen de organisatie bestaande code te lezen. Zo kunnen we deze Best Practice onszelf eigen maken. Vooral als deze code door ervaren ontwikkelaars is geschreven kan je er veel van leren. Besteed enige tijd aan het lezen van de broncode van anderen en ik weet zeker dat je in een paar dagen of weken mooie leesbare broncode kunt creëren. De fouten, die je tot nu toe maakte bij het schrijven van broncode, ga jenvoorkomen.
Een leuk experiment is om eens in het verleden te duiken en de code die je een paar jaar geleden hebt geschreven te bekijken. Je zult je goed vermaken want je bent inmiddels een betere ontwikkelaar omdat je je voortdurend verbeterd hebt door veel te schrijven en te lezen.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.