Hoe schrijf je “goede legacy code”
Hier volgen enkele snelle uitgangspunten voor het schrijven van goede legacy code. Code is veel gemakkelijker te schrijven dan te lezen, en de beste manier om problemen op te lossen is ze niet te creëren.
Schrijf minder code
Minder code = minder potentieel voor bugs = minder te onderhouden = minder “slechte legacy”.
Het schrijven van minder code zou kunnen worden gezien als de belangrijkste manier om code in het algemeen te verbeteren. Het DRY-principe kan worden gezien als een natuurlijk uitvloeisel en primair middel om minder te schrijven en meer te bereiken.
Vermijd // TODO en // FIXME
Het schrijven van // TODO of // FIXME moet worden gezien als een rode vlag en een codegeur.
Als we deze opmerkingen vertalen naar hun werkelijke betekenis dan vertaalt “TODO” zich als “creëer technische schuld” en “FIXME” vertaalt zich als “ik schrijf opzettelijk een bug”.
Er kunnen zeldzame uitzonderingen zijn waarbij het uitstellen van een oplossing opweegt tegen de voordelen van het nu oplossen, maar in het algemeen moeten TODO en FIXME tot een minimum worden beperkt.
Voorkeur gevestigde idiomen boven de nieuwste
Dit lijkt misschien tegenstrijdig… het gebruik van bleding-edge technologieën maakt code meer “nieuw”, toch? Nou, ja, maar het creëert ook de mogelijkheid om sneller verouderd te raken.
Het maakt het ook moeilijker voor nieuwe programmeurs om dingen uit te vogelen. Als de code is geschreven met behulp van gevestigde idiomen en raamwerken, is het waarschijnlijk gemakkelijker te lezen en heeft het een betere kans om langer te werken in de toekomst.
Laat de code altijd achter in een betere staat dan je hem vond
Dit lijkt misschien in tegenspraak met het “niet herschrijven” dat aan het begin werd genoemd, maar continue verbetering en refactoring is anders dan het doen van een significante herschrijving.
Probeer de gewoonte te krijgen om dingen geleidelijk en incrementeel te verbeteren. Soms is een grote refactor of herschrijving echt nodig, maar de zakelijke waarde hiervan moet zorgvuldig worden afgewogen tegen andere prioriteiten.
Beter blijven als programmeur
Lees boeken, lees blogposts, lees code van anderen, denk goed na over ontwerp- en programmeerpraktijken. Denk bewust na over je code en bedenk manieren om te verbeteren.
In plaats van de vorige programmeur de schuld te geven van het achterlaten van een slechte erfenis, moet je ervoor zorgen dat je niet de programmeur wordt die een nieuwe erfenis creëert.