Jakiś czas temu wymieniałem implementację autoryzacji w systemie nad którym pracuje. Jednym z wymagań było zapewnienie poprzedniej funkcjonalności. Oczywiście mieliśmy testy na poprzednią funkcjonalność ale w jaki sposób użyć ich do testowania innej implementacji? W tym poście przedstawię tę historię. Spock podobnie jak inne frameworki do testowania wspiera parametryzowane testy. Zazwyczaj definiuje się je przez […]
Mandelbrotowska natura modularyzacji
W świecie oprogramowania, modularyzacja ma kluczowe znaczenie dla utrzymania elastyczności, skalowalności i czytelności kodu. Uczestniczyłem w wielu dyskusjach na temat tego, jaki rozmiar powinien mieć moduł. Padają w nich często skrajne opinie, począwszy od „lepszych jest kilka dużych modułów”, po „im mniejsze moduły, tym lepiej”. Prawda jak zawsze leży gdzieś pośrodku, a w tym wpisie wskażę, jak ją namierzyć.
Modularyzacja i testy architektury
Modularyzacja w projektach stanowi jedną z kluczowych technik, które pozwalają na zachowanie czytelności, skalowalności oraz łatwości w utrzymaniu kodu. Wraz z rozwojem projektów, zwłaszcza tych o większym zakresie, staje się ona ważnym elementem zapewniającym porządek i przejrzystośći w strukturze kodu. Jednakże, wraz z rozwojem projektu, gdy wprowadzane są kolejne zmiany, a programiści przychodzą i odchodzą, łatwo zapomnieć o początkowych założeniach architektury. Z pomocą przychodzą testy automatyczne. Tylko co testować i jak je zrobić? Bez solidnych testów nie jesteśmy w stanie upewnić się, że nasza struktura modułowa spełnia założenia, które sobie postawiliśmy.
Mroczne strony Open-Closed Principle
Zasada otwarte-zamknięte (Open-Closed Principle), opisana w SOLID, zapewnia elastyczność projektu, jednak czy zawsze prowadzi to do optymalnego, gotowego na przyszłe zmiany kodu? Brzmi ona obiecująco – otwarte na rozszerzenie, zamknięte na modyfikację. Przyjrzyjmy się jej bliżej.
Dodatkowe checki w checkstyle
Checkstyle to potężna biblioteka, która nie tylko pozwala ustandaryzować formatowanie kodu w projekcie, ale także wyłapać niektóre błędy w programie (np. czy implementując metodę equals zaimplementowano także metodę hashcode) oraz design kodu (np. maksymalny rozmiar metod lub złożoność cyklomatyczną). To, że narzędzia statycznej analizy kodu są niezwykle przydatne, traktuję jako pewnik. Warto ich używać, nawet […]
O tym jak wprowadzając clean code trzykrotnie zwiększyłem zużycie pamięci
Ten post to krótka historia tego jak dobre chęci mogą doprowadzić do katastrofy, gdy zapomina się o wewnętrznych mechanizmach JVM oraz o tym jak, po raz kolejny, zadziałało podejście Kenta Becka – “Make it work, Make it right, Make it fast”.
Optional jako pole i co mi zrobisz?
Od wprowadzenia klasy Optional w JDK 8 minęło już sporo czasu. Sporo też napisano o tym jaki i gdzie jej używać, co jest dobrą praktyką a co złą. Przykład tego można znaleźć w artykule Optional Anti-Patterns. Ale czy to wszystko ma sens? Zgadzam się z wieloma postawionymi tam tezami. Chciałem jednak wejść w polemikę z […]