Inhoudsopgave
Een script schrijven duurt tien minuten. Een script schrijven dat ook over zes maanden nog werkt, op een andere machine draait en begrijpelijk is voor een collega die er nooit naar heeft gekeken, dat is een ander verhaal. De meeste automatiseringsscripts beginnen als een snelle oplossing voor een concreet probleem en groeien daarna organisch aan totdat niemand meer precies weet wat ze doen of waarom. Wie vanaf het begin een paar goede gewoontes toepast, voorkomt die situatie en bouwt automatisering die echt vertrouwen verdient.
Foutafhandeling als eerste prioriteit
Een script zonder foutafhandeling is een tijdbom. Zolang alles goed gaat werkt hij prima, maar zodra er iets onverwachts gebeurt (een bestand dat niet bestaat, een API die niet reageert, een schijf die vol is) gaat hij stilletjes door of crasht hij op een onbegrijpelijke manier. In bash zet je set -euo pipefail bovenaan je script zodat hij stopt bij de eerste fout en ongedefinieerde variabelen als fouten behandelt. In Python gebruik je expliciete try-except blokken met betekenisvolle foutmeldingen. Een script die luid faalt is altijd beter dan één die stilletjes doet alsof alles goed gaat.
Variabelen en configuratie bovenaan
Hardcoded waarden verspreid door een script zijn een onderhoudsnachtmerrie. Paden, URLs, timeouts en andere instelbare waarden horen bovenaan het script als duidelijk benoemde variabelen, of beter nog als omgevingsvariabelen die je van buitenaf meegeeft. Zo hoeft iemand die het script wil aanpassen niet door honderd regels code te zoeken naar de ene waarde die hij wil wijzigen. Behandel je script als een mini-applicatie: configuratie gescheiden van logica, en logica gescheiden van output.
Idempotentie als ontwerpdoel
Een idempotent script produceert hetzelfde resultaat ongeacht hoe vaak je het uitvoert. Als het script een map aanmaakt, controleert het eerst of die map al bestaat. Als het een rij in een database invoegt, controleert het eerst of die rij er al is. Dit klinkt als extra werk, maar het voorkomt fouten bij herhaalde uitvoering en maakt het veilig om een script opnieuw te draaien na een onderbreking. Idempotentie is vooral waardevol bij scripts die automatisch worden uitgevoerd via een cronjob of CI-pipeline, waar je niet altijd ziet wat er al eerder is gebeurd.
Logging die vertelt wat er gebeurt
Een script dat in stilte werkt geeft geen feedback over wat het doet of heeft gedaan. Voeg logging toe die de voortgang bijhoudt: welke stap wordt uitgevoerd, hoeveel items zijn verwerkt, wat er is overgeslagen en waarom. Schrijf logs naar stdout voor normale output en naar stderr voor fouten, zodat ze apart te redirecten zijn. Voor scripts die regelmatig draaien is een logbestand met timestamps waardevol, zodat je achteraf kunt reconstrueren wat er wanneer is gebeurd. Goede logging maakt debuggen een stuk minder pijnlijk.
Documentatie in het script zelf
Een script zonder uitleg is een zwarte doos voor iedereen die er niet bij was toen het geschreven werd, inclusief jezelf over drie maanden. Voeg bovenaan een korte beschrijving toe van wat het script doet, welke argumenten het accepteert en welke omgevingsvariabelen het verwacht. In bash doe je dat met een comment-block, in Python met een docstring. Voeg ook --help functionaliteit toe als het script argumenten accepteert (argparse in Python maakt dat eenvoudig). Die paar minuten documentatie schrijven besparen uren aan verwarring later.