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 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.
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.
W ostatnich latach architektury usługowe, a w szczególności mikrousługi, zdobyły ogromną popularność, tymczasem podejście do testów end-to-end (E2E) często pozostało bez zmian. Słyszymy, że testy sprawdzające działanie całego systemu są kluczowe w procesie tworzenia oprogramowania, zwłaszcza przy architekturach rozproszonych. Pojawiają się stwierdzenia w stylu „Musimy udowodnić, że system działa jako całość. Kiedyś mieliśmy monolit i testy E2E, teraz mamy niezależne mikrousługi, więc testy E2E są tym bardziej potrzebne”.
W swoim życiu zawodowym wielokrotnie spotkałem się z wytycznymi wedle których ,,każdy system musi posiadać dokumentację”. Zwykle na podstawie tak sformułowanych wymagań ktoś z zespołu przygotowywał dokument, który nazywano dokumentacją. Nierzadko był to wymuszony dokument, którego istnienie niczego nie zmieniało w kontekście użyteczności systemu i niczego nie ułatwiało.
W tym poście chciałbym przedstawić moje trzypunktowe podejście do zadań i problemów związanych z dokumentacją.
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 […]
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”.
Na tym blogu zdarza się, że są poruszane tematy tabu. Tym razem przyszedł czas na statyczne publiczne zmienne. Wiele już zostało powiedziane na temat zła, które wyrządziło światu ich stosowanie. W tym poście chciałbym przeanalizować szczególny przypadek ich użycia, a mianowicie metryki. Metryki, wszędzie metryki W poście Mierz logi na zamiary Bartek opisał jak istotne […]
W kłopoty wpędza cię nie to, czego nie wiesz, lecz to, co wiesz, a co nie jest prawdą. — Will Rogers Podstawy których nie znają seniorzy Wszyscy wiemy jak ważnym zagadnieniem jest dobre nazewnictwo zmiennych, funkcji, klas i wszystkiego czym operujemy. Jednym z popularniejszych technik refaktoryzacji jest zmiana nazwy. Programiści spędzają sporo czasu nad wymyślaniem […]
W ostatnim czasie praca zdalna stała się coraz bardziej rozpowszechniona. Sam pracowałem przez rok jako satelita, a wcześniej także przez rok w pełni rozproszonym zespole w różnych strefach czasowych. Aktualnie pracuję w Allegro, gdzie przez fakt posiadania biur w kilku miastach, elementy pracy zdalnej są na porządku dziennym. Zanim przejdziemy do wzorców, określmy kontekst zespołu […]