Pewność, że działa

Jeżeli już musisz pisać kod, to pisz go tak, żeby mieć jak największą pewność, że działa.

Wiadomo, 100% pewności nie istnieje z przyczyn niezależnych od nas.

Moim zdaniem całym sensem programowania jest przekładanie znaczenia biznesowego na kod. Ten kod musi działać, bo inaczej cały proces nie ma sensu.

Oprócz samego działania trzeba przewidzieć też bezpieczeństwo, wydajność, skalowalność i łatwość utrzymania. To wszystko jest częścią tego samego procesu.

Celem napisania funkcji jest mieć pewność, że osiągnie to, do czego została napisana. Nie da się programować w stylu “może coś się wydarzy” — trzeba z góry myśleć o edge case’ach, zamiast odkrywać je przypadkiem na produkcji.

To zaczyna się jeszcze przed pierwszą linijką kodu. Trzeba przewidzieć, gdzie i w jakim celu ten kod będzie działał. Ilu użytkowników realnie obsłuży, żeby nie tracić czasu na optymalizację, której nikt nie potrzebuje, ale też nie stworzyć rozwiązania, które sypie się przy pierwszym większym obciążeniu.

I jedna rzecz, którą musiałem sobie poukładać: zabezpieczenia przed psuciem rzeczy są ważniejsze niż strach przed zepsuciem czegoś. Strach przed zmianą jest naturalny, ale nie może być powodem, żeby nie pisać kodu. Ten styl myślenia ma jeszcze większy sens, jeżeli pracujesz w zespole. Nawet jeśli bardzo świadomie wdrażasz zmiany, to zawsze jest ryzyko, że ktoś inny zrobi coś, co popsuje proda.

Pewność nie bierze się z nadziei, że kod zadziała. Bierze się z tego, że przemyślałeś, jak może nie zadziałać.