Wat zijn softwareantipatronen?

Een softwareontwerppatroon is een effectieve, herbruikbare oplossing die kan worden gebruikt bij een veelvoorkomend probleem in de softwareprogrammering. Dus dan is een softwareantipatroon het tegenovergestelde, nietwaar?

Ongeveer.

Als antipatronen volledig het tegenovergestelde van ontwerppatronen waren, zouden ze gebruikt worden om te zorgen dat projecten mislukken. Het is niet heel waarschijnlijk dat een softwareontwikkelaar expres een antipatroon zou inzetten waarvan bekend is dat het problemen veroorzaakt.

Antipatronen kunnen in software terechtkomen omdat ze opties en keuzes bevatten die geschikt lijken voor het oplossen van een specifiek probleem. Een antipatroon is meestal een obscure of klungelige oplossing die wellicht op de korte termijn werkt, maar die op de lange termijn problemen en consequenties veroorzaakt die de kortetermijnvoordelen tenietdoen.

In dit artikel beschrijven we een aantal antipatronen, leggen we uit hoe ze worden veroorzaakt en beschrijven we stappen om ze te voorkomen.

Verschillende types softwareantipatronen

De volgende softwareantipatronen kunnen verantwoordelijk zijn voor technische schuld in je softwareontwikkelingsproject. Je team zal uiteindelijk op dit stuk code terug moeten komen om het te repareren, waardoor het project vertraging kan oplopen.

Dit zijn een aantal veelvoorkomende antipatronen die je moet vermijden:

Spaghetticode

Als iemand tegen je zegt dat je goede spaghetticode schrijft, is dat geen compliment. Wat de persoon in kwestie bedoelt, is dat je code dezelfde 'nette logische structuur heeft als een bord spaghetti' (Richard Conway, 1978).

Wanneer een ontwikkelaar begint te coderen zonder eerst goed na te denken over hoe het programma moet stromen, kan dit resulteren in spaghetticode. Het eindproduct werkt misschien zoals bedoeld, maar er kunnen zich later problemen voordoen doordat de structuur en het proces niet goed worden begrepen.

Als er nieuwe code wordt toegevoegd en de oudere code op nieuwe plaatsen wordt geplakt, ontpopt je voorheen functionerende programma zich tot een warboel van willekeurig geplaatste bestanden, mappen en functies. Het is bijna onmogelijk iets nieuws toe te voegen zonder dat er iets misgaat. Spaghetticode kan even onnavolgbaar zijn als de spaghettislierten op je bord. 

Het werkt een beetje als het toevoegen van een nieuwe kamer aan een bestaand gebouw. Je begint niet zomaar te bouwen met willekeurige materialen, zonder eerst na te denken over de architectuur, de materialen, de kleurschema's, het ontwerp en de logica van het bestaande gebouw. Een een-twee-hatseflats-benadering levert waarschijnlijk een kamer op die uit de toon valt bij het bestaande gebouw en eruitziet alsof hij er simpelweg niet bijhoort.

Gouden hamer

In de psychologie verwijst het begrip cognitieve bias of cognitieve fout naar hoe iemand de wereld om zich heen interpreteert op basis van eigen overtuigingen en ervaring. De gouden hamer is een cognitieve bias waarbij je gelooft dat een enkele tool al je programmeerproblemen kan oplossen. Je hebt een specifiek, goed ontworpen en architectonisch solide stuk code gebruikt om problemen in eerdere projecten op te lossen. Dus dan werkt het toch vast ook voor je huidige project?

Niet altijd.

Het idee is dat je niet te veel op een enkele oplossing moet vertrouwen, omdat één maat nooit echt iedereen past. In ons voorbeeld over het bouwen van een nieuwe kamer is een hamer heel nuttig gereedschap, maar zou je er een stuk hout mee zagen?

Je kunt je antipatroon van je gouden hamer in je code proppen op een plaats waar het niet goed past en misschien lukt het je zelfs het te laten werken. Maar als je later nieuwe functies wilt toevoegen, kan je programma onbetrouwbaar en onstabiel worden. En als je niet goed oppast, eindig je met een tweede bord spaghetticode.

Bootanker

Een bootanker-antipatroon doet zich voor als iemand een stuk code in de codebase laat staan, niet omdat het daar hoort maar omdat het later van nut kan zijn. De redenering is dat als de code later nodig is, die gemakkelijk ingeschakeld en ingezet kan worden. De code is niet ingeschakeld, dus dan kan het toch geen kwaad?

Net als een bootanker verzwaart dit type code je project en kan het je voortgang vertragen. Ontwikkelaars kunnen tijd verspillen aan het doorlezen en debuggen van code die in deze iteratie niet eens ingeschakeld wordt. Al die extra, onnodige code blaast de codebase op en verlengt je bouwtijd. En als je per ongeluk een of meer van deze bootanker-antipatronen inschakelt, kan dat problemen veroorzaken, zoals constructiefouten, extra technisch risico of technische schuld.  

Dode code

Dode code is de term voor delen van de broncode die kunnen worden uitgevoerd, maar waarvan de resultaten niet door het programma worden gebruikt. De code is onnodig en verspilt verwerkingsmiddelen.

Jaren geleden, bijvoorbeeld, werkte een technisch schrijver aan het documenteren van oplossingen voor foutcodes die door netwerksoftware werden gegenereerd. Hij was verbaasd toen hij ontdekte dat veel programmeurs niet wisten:

• Wat de foutcodes betekenden
• Waarom de server een foutmelding genereerde
• Welk stuk code deze fouten veroorzaakte

De code was min of meer dood en moest worden verwijderd. Maar de technici aarzelden om de code te verwijderen, omdat ze bang waren dat dit nieuwe bugs zou veroorzaken of dat de code niet meer zou werken. 

Dode code-antipatronen zijn zwaar, doen niets voor het programma, vertragen de ontwikkeling, verlengen de bouwtijd en zijn moeilijk te onderhouden.

Godobject 

Als een object of klasse te veel doet en verantwoordelijk is voor te veel dingen, kan het als een godobject gezien worden. Te veel verantwoordelijkheid toewijzen gaat in tegen het principe van enkele verantwoordelijkheid zoals gebruikt in objectgeoriënteerd ontwerp. Ieder object en iedere klasse in je code moet verantwoordelijk zijn voor een enkel deel van de functionaliteit van je software.

Bijvoorbeeld: een klant-ID-object dat verantwoordelijk is voor de gebruikersnaam, voornaam, achternaam, lijst van gekochte artikelen, totaal uitgegeven bedrag, transactiecode enzovoort kan een godobject zijn. Het is logisch dat een klant-ID-object verantwoordelijk is voor de gebruikersnaam, voornaam en achternaam, maar probeer de code op te splitsen en te modulariseren door een ander object aan te maken om de transactiegegevens te verwerken.

Programmeren door te kopiëren en te plakken

Soms kan het kopiëren en plakken van code uit andere bronnen in je nieuwe code onvoorziene problemen veroorzaken. Het feit dat deze stukken code werkten voor andere ontwikkelaars die met hetzelfde soort problemen als jij te maken hadden, betekent niet dat deze code simpelweg in je nieuwe code gestopt kan worden en daar probleemloos werkt.

Als je de code test en je ervan verzekert dat hij werkt, dat de code kan werken in de architectuur van je project, dan kun je misschien deze code in je project gebruiken. Maar als je de code niet test en hem toevoegt omdat het werkte voor anderen, loop je het risico bugs en andere problemen te introduceren. De enige manier waarop je dit kunt oplossen is door iedere instantie waar de code was geplakt op te sporen en de code daar te verwijderen. Of je keert terug naar een versie van de software van voor je de gekopieerde en geplakte antipatronen introduceerde.

Voorkom softwareantipatronen met beter systeembeheer

Je kunt voorkomen dat je antipatronen aan je codebase toevoegt door consistenter en waakzamer te zijn bij je systeembeheer. Concreet gezegd moet je:

• Code regelmatig controleren: zoals schrijvers redacteuren nodig hebben om hun werk na te kijken op spel- en grammaticafouten, zo hebben softwareontwikkelaars codecontroles nodig om syntaxisfouten en defecten te vinden en te repareren, de kwaliteit van de code te verbeteren en betere oplossingen te vinden voor veelvoorkomende problemen. Het is altijd belangrijk om iemand anders naar je werk te laten kijken, omdat die dingen zal zien die jou zelf niet zijn opgevallen. Zo kun je de code stroomlijnen.

 

• Code refactoren: dit proces wordt gebruikt om aanpassingen te maken die het kader en de structuur van je code zullen verstevigen, zonder dat dit invloed heeft op de manier waarop gebruikers verwachten dat de software functioneert. Refactoren kan je helpen om de constructie van je code te vereenvoudigen. Dat maakt het makkelijker voor een volgend persoon om te begrijpen hoe de code is samengesteld en om op efficiëntere wijze nieuwe functies aan de code toe te voegen.

 

• Visualiseren: veel mensen begrijpen en onthouden informatie beter als die visueel gepresenteerd wordt. Lucidchart bevat een verscheidenheid aan ingebouwde sjablonen waarmee je je hele systeem kunt visualiseren. Zo kun je gemakkelijker werkstromen in kaart brengen, processen analyseren, brainstormen over ideeën voor verbetering en samenwerken met verschillende afdelingen op verschillende geografische locaties.