Nie obfuskuj kodu… nigdy
Po raz kolejny na 4p pojawił się temat „jaki obfuskator”. I po raz kolejny odpowiedź brzmi „najlepiej żaden”.
Generalnie współczesne obfuskatory potrafią robić kilka rzeczy poza samym zaciemnianiem nazw. Te są przydatne:
- Usuwanie nieużywanego kodu.
- Usuwanie informacji dla debuggera.
- Upraszczanie niektórych wyrażeń (shriking).
- Optymalizacja kodu m.n. wykorzystania zmiennych lokalnych.
W efekcie możemy dostać kod mniejszy i trochę wydajniejszy, ale będziemy musieli za to zapłacić bardzo wysoką cenę. Jest nią możliwość utrzymania kodu. Skoro kod wyjściowy zostanie potraktowany refaktoryzacją Zmiana nazwy to w efekcie gdy otrzymany od klienta stacktrace stanie się ciekawą łamigłówką pt. „Co to za klasa się wyjebała”.
Kolejną wadą jest utrata możliwości powtórnego użycia kodu. Obfuskowany jar, który zawiera zestaw metod narzędziowych… a ty siedzisz i piszesz wszytko od nowa 😀
Na koniec należy też dodać utratę powiązania pomiędzy kodem, a dokumentacją. Wdrożenie nowego człowieka w projekt będzie bolesne… szczególnie jak mu się trafi obfuskowany stacktrace.
Zalety? Tak są. Obfuskatorów należy używać jeżeli piszemy na platformę JME albo Java Card i mamy ograniczenia co do ilości wyprodukowanego kodu. W takim wypadku warto użyć obfuskatora. Kolejną jest użycie obfuskatora z wyłączonym modułem zmiany nazw w celu optymalizacji kodu. Zazwyczaj jest to upraszczanie wyrażeń (np. dodawania Stringów) lepsze wykorzystanie zmiennych lokalnych, usuwanie informacji dla debuggera czy martwego kodu. Czasami niewielkie zyski w tym zakresie są jak najbardziej pożądane. Przykładowo jeżeli uda nam się zmniejszyć wielkość paczki pobieranej przez klienta o 10% to dla 100MB jara wynik 10MB mniej na pobranie jest już znaczący zarówno dla naszych dysków jak i łączy.
Ale najważniejsze. Nie używajcie obfiskatorów. Najlepiej nigdy.