Skrypt wykonuje tę samą operację na tysiącu obiektów w kilka sekund — również wtedy, gdy operacja jest błędna. Zabezpieczenia są tu ważniejsze niż elegancja kodu.
Tryb próbny jako domyślny
Uruchomienie bez dodatkowego parametru powinno wypisywać, co zostałoby zrobione, i nie zmieniać niczego. Zapis dopiero po świadomym potwierdzeniu. To jedno zabezpieczenie zapobiega większości poważnych pomyłek.
Wydruk z trybu próbnego warto zachować i porównać z tym, co skrypt zrobił naprawdę. Rozbieżność oznacza, że stan zmienił się między jednym uruchomieniem a drugim — a to sygnał, żeby zatrzymać się i sprawdzić dlaczego, zanim operacja pójdzie dalej.
Kontrole zaporowe
Skrypt powinien przerywać pracę, gdy liczba obiektów do zmiany znacznie odbiega od spodziewanej albo gdy dane wejściowe wyglądają na niekompletne. Lepiej zatrzymać się niepotrzebnie niż zmienić wszystko.
Typowe pułapki są zawsze te same: pusty plik wejściowy zinterpretowany jako „brak wyjątków”, zapytanie zwracające wszystko zamiast niczego, zmienna, która nie została ustawiona i podstawiła się jako pusty tekst w ścieżce. Każda z nich zamienia ostrożną operację w masową. Sprawdzenie warunków wejściowych na początku kosztuje kilka linii.
Dziennik działania
Zapis, co i kiedy zostało zmienione, jest jedyną drogą do odtworzenia stanu po nieudanej operacji. Skrypt bez dziennika zostawia po sobie zagadkę.
Najbardziej użyteczny jest dziennik zawierający stan przed zmianą, nie tylko po niej. Wtedy da się z niego wprost odtworzyć poprzednie wartości. Przy operacjach na danych warto pójść dalej i wykonać kopię bazy jako pierwszy krok samego skryptu, a nie jako czynność do zapamiętania przed uruchomieniem.
Mierzyć skutek, nie zamiar
Komunikat „gotowe” oznacza, że kod doszedł do końca, a nie że efekt jest właściwy. Sprawdzenie stanu po wykonaniu powinno być częścią skryptu.
Ma to szczególne znaczenie przy operacjach, które kończą się powodzeniem niezależnie od wyniku — usunięcie czegoś, czego nie ma, albo zapis do miejsca, którego nikt nie czyta. Skrypt uruchamiany jako zadanie cykliczne powinien dodatkowo potwierdzać wykonanie w miejscu, które ktoś obserwuje, bo inaczej jego zatrzymanie pozostanie niezauważone.
Bez haseł w kodzie
Dane dostępowe w osobnym pliku poza katalogiem publicznym, z ograniczonymi uprawnieniami. Hasło wpisane w skrypt trafia potem do kopii, notatek i wiadomości.
Konto techniczne używane przez skrypt powinno mieć wyłącznie te uprawnienia, których skrypt potrzebuje. Uruchamianie wszystkiego na koncie administratora jest wygodne i sprawia, że pomyłka w jednej linii sięga dalej, niż powinna.
Czytelność ważniejsza od zwięzłości
Skrypt będzie czytany przez kogoś innego, w pośpiechu, przy awarii. Nazwy mówiące wprost i komentarz wyjaśniający cel są wtedy warte więcej niż oszczędność linii.
Najważniejszy komentarz to ten na górze pliku: po co skrypt powstał, co zmienia, kiedy się uruchamia i kto go utrzymuje. Bez tego po dwóch latach nikt nie odważy się go wyłączyć ani poprawić.
Kiedy nie pisać skryptu
Operacja wykonywana raz, na kilku obiektach, zwykle nie jest warta kodu, który trzeba przetestować i utrzymać. Skrypt zaczyna się opłacać przy powtarzalności albo przy skali, w której ręczna praca sama zaczyna generować błędy.
