Het leed van de programmeur: andere programmeurs
Auteur: Piipol
Geplaatst op: 15/06/17
Onze frontend developer Jiro kwam in september 2016 bij Piipol. Zijn webcoding skills waren up to date door een nieuwe opleiding en hij kon prachtige websites maken. Dat was super. Maar niets had hem erop voorbereid dat je in de praktijk eigenlijk nooit iets 'from scratch' bouwt maar vooral aan de code van anderen moet sleutelen. Hier wat mijmeringen (om er toch je voordeel mee te doen) :
Is er een manier om goed om te gaan met de code die anderen hebben geschreven?
Ik heb er flink naar gezocht en kwam op de volgende tips uit, maar meer zijn altijd welkom:
referentie 1
http://www.skorks.com/2010/05/why-i-love-reading-o...
https://selftaughtcoders.com/how-to-quickly-and-ef...
Zoek 1 onderdeeltje waarvan je weet wat de code precies doet en traceer die resultaten omgekeerd achteruit, vanaf het einde.
Stel bijvoorbeeld dat je weet dat de code die je bekijkt uiteindelijk een bestand maakt met een lijst met bedrijfsnamen. Bepaal waar in de code - de specifieke, weinig regels - het genereert dat bestand.
Vervolgens beweeg je een stap achteruit en vind je hoe het de informatie in het bestand plaatst.
Enzovoort…
Laten we die gekoppelde stukjes code een "ketting van acties" noemen.
Het gebruik van deze aanpak zal onvermijdelijk u door een aantal verschillende gebieden van de code leiden. En dat geeft je heel wat inzicht in dingen zoals:
Hoe de structuur van de code is georganiseerd (waar variabelen zijn gedefinieerd, waar verschillende soorten functies zijn gevestigd, enz.)
"
Programmeren is leuk. Programmeercode lezen, aan de andere kant, is hard werken. Niet alleen is het hard werken, het is vermoeiend, want je ontdekt dan dat alle code, die je niet zelf hebt geschreven, 'slecht' lijkt.
"
De persoon's stijl van codering
Hoe de persoon die de code schreef denkt en probleem oplossen (dit is moeilijker om te beschrijven, maar het komt intuïtief in hoe meer voorbeelden je ziet)
En daardoor begint u geleidelijk meer en meer van dat volledige 'lichaamscode' te begrijpen. Dus waar ben je begonnen met:
[Een groot bestand van code)
Nu kijkt u naar:
[Nog steeds een groot bestand van code, maar waar u nu een paar specifieke secties begrijpt]
Het is bijna alsof je oorspronkelijk in een kamer was die zwart was, en er waren tegelijkertijd verschillende lichten in de kamer aangestuurd om de details van de kamer te laten zien.
Met behulp van 'kettingen van acties' om een nooit eerder gezien stuk code te begrijpen
Altijd commentaren plaatsen.
Zet in je code altijd een commentaar waarbij je uitlegt wat iets doet. Dit is niet alle handig voor anderen maar ook voor jezelf, want als je een jaar later terug kijkt naar je eigen browsen, ben je door andere projecten allang weer vergeten hoe alles ook alweer precies in elkaar zat.
2. Afspoelen en opnieuw wassen.
Herhaal dat proces meerdere malen, en u verhoogt snel uw begrip van meer en meer stukken van de algemene codebase.
Net als delen van de toonhoogte-kamer geleidelijk verlicht worden, worden delen van de code geleidelijk "opgestoken" voor u, zoals u begrijpt hoe ze functioneren.
De reden dat goed werkt is dat in elk geval een code code is ontworpen om één of meer complexe problemen aan te pakken. Dus je hebt altijd die "acties van acties" doorheen.
En hoe meer je begrijpt hoe verschillende delen van de code verbonden zijn, hoe meer je een begrip krijgt van de gehele codebase als geheel.
En mettertijd, hoe meer (goede) code je ziet, hoe makkelijker het wordt om alle code te lezen en te begrijpen en hoe sneller je dat kan doen.
.. dat leidt direct naar de tweede reden waarom ik van deze vraag hou: het benadrukt het belang van blootstelling aan hoogwaardige, hoogwaardige voorbeelden van expertise.
In de programmering, "hoogwaardige voorbeelden van expertise" = goede code die andere programmeurs schreven.
Het belang om jezelf bloot te stellen aan hoogwaardige, hoogwaardige voorbeelden van expertise