W pogoni za szybkością nie wpadnijmy w nowe błędy.
Szybciej znaczy mniej stabilnie
Jeśli ładowanie strony jest trochę wolne a spinner obraca się przez kilka sekund, ludzie zapomną o tym gdy w końcu ktoś siądzie specjalnie nad problemem wydajności i to poprawi. Ale nie zapomną błędów. Stabilny kod jest lepszy niż szybki kod i nie ma się co oszukiwać: praca na „łapu capu” nad szybkością i gorączkowa optymalizacja kodu wprowadza niestabilność.
Priorytety na rozmowach o pracę chyba powinny ulec zmianie
Niezależnie od tego, czy jesteśmy samoukami, czy też ukończyliśmy techniczny kierunek na politechnice, wszyscy spotykamy się z taką dość typową sytuacją podczas rozmowy rekrutacyjnej. Otóż jesteśmy proszeni o wykonanie zadania (np. odwrócenia kolejności elementów w liście) a po prezentacji rozwiązania słyszymy a czy nie dałoby się tego zrobić szybciej?.
Podejmujemy rękawicę. Nasz rozmówca w tym czasie węszy i wierci się, podsuwając mylące sugestie i ukradkiem podglądając swój monitor, na którym jego kod mówi ci wszystko, co musisz wiedzieć o jego umiejętnościach. Ale nic to, z bólem łamiemy zasady czystego kodu i wyciskamy jeszcze mikrosekundę lub dwie żeby dostać tą robotę.
I to jest taki nawyk, niekoniecznie dobry: optymalizacja wydajności staje się najważniejszą rzeczą, jaką robimy. Więc staramy się to robić wszędzie, nawet w kodzie, w którym nie zrobi to żadnej różnicy dla jego praktycznej doniosłości.
Zoptymalizowany kod to potencjalnie niestabilny kod
Kiedy robimy z kodem sprytne rzeczy, żeby przyśpieszyć jego działanie, nierzadko musimy iść na kompromisy. Najczęściej oznacza to, że wprowadzamy niestabilność. Kod może działać szybciej, ale jest bardziej prawdopodobne, że nie będzie działał tak jak tego oczekujemy dla wszystkich testowych przypadków. Dobry kod to stabilny kod, a stabilny kod jest ciężki, nudny i rutynowy. Dobry kod ma środki obronne, takie jak:
- nawiasy klamrowe lub ich odpowiedniki wokół ciągów znaków stosowane nawet wtedy gdy tak naprawdę nie są potrzebne;
- dodatkowe nawiasy, nawet jeśli na pamięć znamy kolejność operacji;
- sprawdzanie nulli gdzie się da.
Kiedy stwierdzamy, że dla szybkości pomijamy takie praktyki to opuszczamy bezpieczną strefę; a kiedy optymalizujemy kod, który nie jest krytyczny dla wydajności, opuściliśmy tę strefę już dawno.
Optymalizację kodu należy przeprowadzać tylko w rzadkich przypadkach, w których ma to znaczenie. I nigdy nie jest to kod implementujący interfejs użytkownika.
To nie znaczy rzecz jasna żebyśmy nigdy nie optymalizowali
Właściwym sposobem postępowania jest optymalizacja na poziomie projektu. O wiele bardziej owocne jest spojrzenie przez programistę na operacje z wysokiego poziomu.
Prawdopodobnie będziesz miał całkiem niezły pomysł na optymalizację jeszcze przed rozpoczęciem pisania kodu. Większość z dobrych praktyk optymalizacyjnych pojawi się w Twojej głowie właśnie wtedy. Natomiast przypadki, w których będziesz musiał przeprojektować kod w trakcie jego pisania mogą pojawić się podczas testowania ale optymalizacja na tym poziomie powinna być już bardzo rzadka. Mówiąc wprost: o ile nie piszesz sterownika urządzenia, sytuacje wymagające optymalizacji na poziomie kodu praktycznie nie powinny wystąpić. Obecnie większość programów opiera się na sieci WWW a większość wąskich gardeł w wydajności występuje w komunikacji między przeglądarką a serwerem. Można w takim przypadku osiągnąć znacznie większą wydajność w optymalizacji zapytań niż w optymalizacji samego kodu.
