Modularyzacja i testy architektury

Obrazek techniczny ilustrujący kilka prostopadłościanów z zaznaczeniem miar

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.

Monolit mentalny: Testy E2E

Głowa z monolitem w środku

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”.

Dokumentacja nie jest wymaganiem

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ą.

Przepis na Word Clock po polsku

Biuro mojej poprzedniej firmy znajdowało się w Hamburgu. Od czasu do czasu wpadałem tam w delegację. Ponieważ siedziba mieściła się w dość ekskluzywnej dzielnicy HafenCity po drodze do biura mijałem różne galerie i sklepy. W jednym na witrynie postawiony był taki zegar. Od razu zwrócił moją uwagę (tym bardziej że wcześniej czytałem o tym na […]

Dodatkowe checki w checkstyle

Code Formatting

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 […]

Metryki jako zmienne publiczne, czy to złe?

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 […]

Przydatne flagi: Bash

bash logo

W poprzednim wpisie pokazałem kilka przydatnych flag do curla. Jednak jeżeli chcemy uruchamiać go w powłoce warto i do niej dodać kilka opcji, aby zachowanie było zgodne z intuicją. -u Domyślnie jeśli jakaś zmienna nie jest zdefiniowana próba odwołania się do niej zwraca pustą wartość. Nie zawsze jest to działanie zamierzone gdyż zwykła literówka może […]

Adresy sieciowe w testach i dokumentacji

golang wait group doc issue

Ostatnio w języku Go zgłoszono ciekawy błąd. Mianowicie URL użyty w przykładach prowadził do Chińskiej strony pornograficznej. W tym artykule opiszę jak się przed tym obronić. Domeny Jeżeli koniecznie potrzebujesz użyć domeny to najlepszym rozwiązaniem jest  example.com example.org example.net Te trzy domeny są stworzone do właśnie do tego celu o czym można przeczytać w RFC […]