Konsist – rzut oka na nowe testy architektury dla Kotlina

Biblioteka Konsist to nowy gracz na rynku narzędzi dla Kotlina. Umożliwia tworzenie testów architektury, ale zarówno sposób pisania, jak i zasada działania różnią się mocno od najpopularniejszego dotychczas narzędzia w świecie JVM, czyli ArchUnita. W tym artykule pokażę krótko, jak wygląda używanie Konsista w praktyce.

Nie lubię nazwy „testy architektury”, bo kojarzy mi się z architektem-mądralą, który pilnuje, czy warstwy zgadzają się z jego podręcznikiem, albo czymś równie oderwanym od realnych problemów. Jednak innej nazwy nie mamy, więc zostaje mi tylko zapewnienie, że takie testy mogą mieć bardzo konkretne, życiowe użycie, a pisać może je każdy, nawet jeśli nie ma „principal senior lead architect” w tytule zawodowym. To taki linter z regułami, które sami piszemy. Warto umieć je pisać, nawet jeśli jest się juniorem.

Nie będę kopiował strony domowej Konsista. Moje przykłady pochodzą z prawdziwych, zawodowych projektów, jakie tworzę. Są tylko trochę uproszczone.

Ten artykuł ma zamiar być krótkim wprowadzeniem, żebyście lepiej zrozumieli, co bierzecie albo czego będziecie odtąd unikać. Nie będę porównywał Konsista z ArchUnitem. Taki tekst mam w przygotowaniu. Nie będę też omawiał każdej możliwości Konsista. Od tego macie oficjalną dokumentację.

Czytaj dalej „Konsist – rzut oka na nowe testy architektury dla Kotlina”

ArchUnit – praktyczne zastosowanie

W artykule o podstawach ArchUnita przedstawiłem, jak i po co pisać testy architektury. Być może znasz temat, ale wciąż nie jesteś do końca przekonany (-a). Lub takie testy masz, ale nie są rozwijane, a nikt nie wie, co i w jakim celu do nich dodawać.

Poniższy tekst dostarcza konkretne, życiowe przykłady użycia. Są to zastosowania z innej bajki niż to, co podaje jako „use cases” oficjalna strona ArchUnita albo clickbaitowe „tutoriale” w stylu tych na Baeldungu (nie linkuję, nic nowego nie wnoszą).

Pokażę, jak stosuję ArchUnita do wykrywania pomyłek w testach. Oraz do wykluczania kodu, który źle działa w Kotlinie: Optional.orElse oraz adnotacji z jakarta.annotation.

Mam nadzieję, że te przykłady pomogą ci lepiej zrozumieć potencjał testów architektury, oraz dostarczą nowych inspiracji do pisania własnych, dostosowanych do potrzeb twojego projektu. Możesz też podany tu kod po prostu skopiować do siebie (udostępniam go na licencji MIT).

Czytaj dalej „ArchUnit – praktyczne zastosowanie”

Sonar dla Kotlina nie ma sensu

Sonar reklamuje się obsługą Kotlina, ale co reklamy i dokumentacja przemilczają, to bardzo niska użyteczność sugestii, jakie oferuje dla tego języka.

Jeśli ktoś nie wie, o co chodzi: to popularne narzędzie do znajdowania problemów w kodzie. W marketingu pojawia się też jako SonarQube i SonarCloud. Ma opinię sprawdzonego „industry standard”. Jest duża szansa, że jeśli ktoś rzuci problem „potrzebujemy narzędzia do static analysis”, to od razu padnie sugestia „weźmy Sonara”. Czy słusznie? To zależy. Jeśli stawiamy na Kotlina, to nie.

W dalszej części artykułu skupię się na konkretnym zastosowaniu Sonara: do projektów napisanych w Kotlinie. Jeśli szukacie informacji jak odpalić SonarQube dla Javy – przykro mi, nie tu. Co jeszcze będzie? Podam linki, dzięki którym samodzielnie zweryfikujecie aktualną sytuację (nawet w wypadku, gdybym przestał aktualizować ten artykuł). Podzielę się też subiektywnymi wrażeniami o tym, jak deweloperzy i deweloperki Sonara radzą sobie z problemami w integracji z Gradle’em.

Czytaj dalej „Sonar dla Kotlina nie ma sensu”

Jak Kotlin wypada w codziennej pracy

Ponieważ od listopada zarabiam na chleb pisząc prawie wyłącznie w Kotlinie, czuję się wreszcie uprawniony do podzielenia się opiniami, jak ten język sprawdza się w poważnej pracy. Kotlina używam dłużej, ale wcześniej tworzyłem w nim kod dla moich prywatnych projektów – nie były to warunki, żeby wydać rzeczową ocenę. Codzienna zespołowa praca nad kodem pozwala rozpoznać rzeczy naprawdę usprawniające kodowanie, a nie tylko wyglądające fajnie na papierze. Z drugiej strony ujawnia niedoróbki.

To nie będzie artykuł z gatunku „kompletne porównanie Kotlina z Javą w 10 częściach” ani „jak mam zacząć programować w Kotlinie”. Łatwo takie znaleźć w wyszukiwarce, plus dokumentacja Kotlina jest świetna i czytając ją można znaleźć odpowiedzi na powyższe dwie kwestie. Napiszę tu o wybranych rzeczach, które subiektywnie dla mnie są najbardziej wyraźne i ciekawe. Nie będzie nic o programowaniu na Androida, bo się na tym nie znam – skupię się na tym, w czym mam doświadczenie, czyli pisaniu back-endu.

Czytaj dalej „Jak Kotlin wypada w codziennej pracy”

Funkcyjna obsługa błędów w Kotlinie i Javie

Czasem obsługa błędów jest prosta, „zerojedynkowa”: albo operacja się powiedzie, albo rzuci wyjątkiem. Mamy jednak też sytuacje, gdy od strony biznesowej podejście „wszystko albo nic” nie ma sensu i oczekiwane jest działanie w trybie „best effort”. Na wejściu jest zestaw danych, wykonujemy na nich operacje, jeśli w trakcie pojawiają się błędy, to po prostu idziemy dalej i próbujemy doprowadzić do końca tak wiele, jak się da, nie wycofując się z niczego. Nie mówimy o beztroskim ignorowaniu błędów: nawet jeśli zgadzamy się na częściowe niepowodzenie, dobrze jest wiedzieć, które z danych były przetworzone pomyślnie, a które z błędem. Jak zaprogramować takie podejście w sposób czytelny i jasno przekazujący intencję?

Imperatywne podejście (try-catch) w naturalny sposób modeluje sytuację zerojedynkową. Żeby zamodelować wersję „best effort” musimy myśleć w sposób bardziej funkcyjny, potraktować zarówno operację do wykonania jak i błąd jako byty na równi z danymi. Będziemy „kolekcjonować” błędy, żeby móc później zanalizować, ile ich było.

Języki nastawione na programowanie funkcyjne ułatwiają tu sprawę, ponieważ mają sprawdzone i dobrze opisane rozwiązania. Przykładowo Scala ma w bibliotece standardowej typ Try. Kotlin i Java nie są językami tradycyjnie wykorzystywanymi w sposób funkcyjny — nie oznacza to, że nie da się działać w nich w analogiczny sposób, jedynie to, że może być trudno znaleźć odpowiedź, jak do tego podejść.

Czytaj dalej „Funkcyjna obsługa błędów w Kotlinie i Javie”

Importy nieprzerywające pracy w IntelliJ

Do niedawna nienawidziłem przeklejania kodu do IDE. Nie dlatego, żebym uważał, że prawdziwemu programiście nie wypada robić copy-paste ze Stack Overflow (to bzdura). Cierpiałem na samą myśl, że będę musiał dodać importy do wszystkich użytych w tym fragmencie klas, ponieważ normalnie w IntelliJ jest to niewygodne. Dobra wiadomość: istnieje wbudowana opcja, która pozwala ułatwić sobie życie — ale domyślnie jest wyłączona. W dalszej części pokażę, jak ustawić swoje IDE do wydajnej pracy z importami. Na samym końcu będzie krótka dygresja o modelach mentalnych dla programistów.

Czytaj dalej „Importy nieprzerywające pracy w IntelliJ”

Niebezpieczny isEmpty() z utili Springa

Wyobraźmy sobie, że znajdujemy w projekcie taki kod w Javie (lub prawie identyczny — w Kotlinie):

public void assertNoViolations(Collection<ConstraintViolation> violations) {
    if (!isEmpty(violations)) {
        throw new IllegalStateException("violates constraints: " + violations);
    }
}

Na oko — kod jak kod, robi co trzeba, nuda. Co może pójść nie tak?

Metoda zgodnie z oczekiwaniami bezproblemowo akceptuje nulla. Rzuca wyjątkiem, gdy przekażemy jej listę zawierającą contraint violations. Jest jeden szkopuł:

assertNoViolations(emptyList());
java.lang.IllegalStateException: violates constraints: []

Jak to jest możliwe?

Czytaj dalej „Niebezpieczny isEmpty() z utili Springa”
Creative Commons License
Except where otherwise noted, the content by Piotr Kubowicz is licensed under a Creative Commons Attribution 4.0 International License.