Nie optymalizuj kodu w ciemno

Optymalizacja daje satysfakcję, bo wynik łatwo pokazać: mniej milisekund, mniej zapytań, mniejszy plik. Problem w tym, że można poprawić fragment, który nie ma znaczenia dla całego systemu.

Najpierw pomiar

Zanim zmienisz kod, zapisz stan wyjściowy. Dla strony może to być czas renderowania i wielkość zasobów. Dla API: percentyl p95, liczba zapytań do bazy i użycie pamięci. Dla procesu biznesowego: czas od zdarzenia do gotowego wyniku.

Bez punktu odniesienia zostaje przeczucie.

Szukaj wąskiego gardła

W aplikacjach internetowych winny często nie jest algorytm. Czas znika w sieci, bazie danych, zewnętrznym API albo zbyt dużych obrazach. Profilowanie pokazuje, gdzie naprawdę czeka program.

zmierz → znajdź wąskie gardło → zmień jedną rzecz → zmierz ponownie

Ta pętla jest mniej efektowna niż duży refaktor, ale daje wiarygodny wynik.

Czytelność też ma koszt

Mikrooptymalizacja, która oszczędza ułamek milisekundy i komplikuje kod, może być stratą. Ktoś będzie musiał ten kod debugować, rozbudować i przetestować. Jeśli zysk nie jest widoczny w pomiarach albo doświadczeniu użytkownika, prostsza wersja zwykle wygrywa.

Optymalizuj to, co czuje człowiek

Użytkownik nie analizuje wykresu CPU. Widzi pusty ekran, zablokowany przycisk albo formularz, który nie mówi, czy dane zostały zapisane. Czasem najlepszą optymalizacją jest wcześniejsze pokazanie części treści, dobry stan ładowania lub usunięcie jednego kroku z procesu.

Szybkość jest cechą produktu, nie konkursem programistycznym.