Fajnie, że jesteś
Mam nadzieję, że poniższy artykuł przypadnie Ci do gustu. Nie przywiązuj zbyt dużej wagi do daty powstania tego wpisu. Nawet jeśli napisałem go na początku istnienia bloga, to staram się przynajmniej raz w roku przeglądać stare treści i je aktualizować. Jeżeli mimo wszystko zauważysz jakąś nieścisłość w tekście, to daj mi proszę znać w komentarzu poniżej.
Pamiętaj także, że wartość tego bloga podbijają pozostawione tu komentarze. Jeżeli temat poruszany we wpisie Cię interesuje, to polecam doczytać także komentarze do niego. Znajdziesz w nich chociażby punkt widzenia innych osób, czy dodatkowe informacje, o których ja zapomniałem lub nie wiedziałem.
Jeden konkurs nadal trwa, a tu niespodzianka! Kolejne pięć książek do zgarnięcia!
Tym razem dzięki współpracy z wydawnictwem Helion mam do rozdysponowania 5 sztuk książki Kierunek jakość. Jak unikać błędów w projekcie autorstwa Oli Kunysz.
Żeby zdobyć jedną z nich należy wziąć udział w konkursie.
Zasady są proste. Wystarczy (w komentarzu poniżej) wymienić (co najmniej) jedno ulubione (szeroko pojęte) narzędzie, które pomaga zapewnić lepszą jakość Twojego projektu.
Odpowiedź uzasadnij.
Na komentarze czekam do 15 sierpnia 2021 roku włącznie.
Książki otrzymają autorzy najciekawszych odpowiedzi.
Zwycięzca wybiera format książki (drukowaną lub ebook), który chciałby otrzymać.
Picture Credits
Przeczytaj także
16 sierpnia 2021 at 12:57
Blogowa komisja ds. konkursów wybrała zwycięzców. Oto oni:
Konrad
Arek
Jacek
Ernest
Staszek
Z każdym skontaktuję się osobiście mailowo, w celu dogadania szczegółów przekazania nagrody. Sprawdźcie swoje skrzynki mailowe!
16 sierpnia 2021 at 19:26
Jestem w szoku pierwszy raz w życiu coś wygrałem, jej strasznie mi miło.
12 sierpnia 2021 at 18:30
Testy jednostkowe oraz integracyjne – zabezpieczają przed nieumyślnym popsuciem działania kodu, testują napisany kod, pozwalają na etapie implementacji uporządkować sobie wiedzę na temat tego co właściwie jest do zrobienia i dodatkowo mogą stanowić pewien rodzaj dokumentacji projektu 😉
14 lipca 2021 at 15:03
po prostu: JIRA
jest super, wrzucam koledze zadania do wykonania i obserwuję jak cała lista z miesiąca na miesiąc rośnie 😛
13 lipca 2021 at 23:17
Podstawowa linia to statyczne analizy kodu – staram się nie popełniać kodu bez SonarLinta czy tam innego Spotbuga w tle. Zdarzają się też „poważniejsze” narzędzia np. od bezpieczeństwa, jednak nie wymienię (NDA) i niekoniecznie polecę (zależy do czego, czasem reguły bywają kontrowersyjne).
Druga linia to białkowe, również statyczne analizy kodu – czyli słynne code review i żebranie o approve’y.
Dochodzą do tego różne rzeczy z infry – firewalle, jakieś Grafany, jakieś ELK, DLP, no zależy – generalnie co Pan(i) sobie życzy.
Gatling. Po prostu – nie używasz? Zacznij!
No i jakiś audycik bezpieczeństwa warto zrobić, polecam (oczywiście zależnie od kontekstu).
Jeszcze koniecznie Mockito. I londyńska szkoła testowania, bardzo proszę. Widziałem tak świetne testy narzędzia do mockowania w różnych projektach, że od razu człowiekowi się humor poprawia na samo wspomnienie 🙂
Zawsze ceniłem sobie krótki czas wycofania wersji z produkcji. I zadbanie o taką możliwość w ogóle.
No i najważniejsze – zgrany zespół i współpraca z klientem, zrozumienie go. W niektórych przypadkach nie ma o co walczyć nawet, jednak jak się da tutaj coś poprawić to zawsze warto!
13 lipca 2021 at 22:42
Moim zdaniem jednym z ciekawszych narzędzi jest PMD lub podobne rozwiązania służące do statycznej analizy kodu. Dzięki takim narzędziom możemy automatycznie dbać o utrzymanie standardów struktury kodu co pomaga w utrzymaniu czytelności. A przy czytelnym kodzie łatwiej zrozumieć co się dzieje i łatwiej możemy implementować nowe funkcjonalności i szybciej zdobywać niezbędne informacje z kodu, które mogą posłużyć do rozmów z użytkownikami.
13 lipca 2021 at 12:32
Rozmowa z userami i być blisko człowieka który używa danych funkcjonalności. Komunikacja jest najważniejszym narzędziem na każdym poziomie produkcji, na każdym czeblu i na każdym stanowisku. Ola zawsze to powtarza.
13 lipca 2021 at 11:44
Moim zdaniem jedną z najważniejszych rzeczy podczas prowadzenia projektu to zadbanie o jakość kodu. Dzięki Linterom
(SonarLint) do VS Code jesteśmy wstanie pisać przejrzysty i spójny kod bez zbędnych śmieci w commitach. To znowu poprawia jakość i szybkość code review. Każdy projekt powinien na początku być uspójniony bo inaczej nie będzie zadawalającej jakości.
12 lipca 2021 at 20:57
Code review – ale takie solidne, które uczy konwencji nowe osoby i służy do wymiany doświadczeń, wiedzy i wypracowywania nowych podejść/standardów w ramach zespołu.
11 lipca 2021 at 21:14
Code Quality jako job w CI Gitlaba, oparte na narzędziu CodeClimat. W łatwy sposób można zablokować mergowanie zmian, które nie spełniają wymogów. Jednak co automat to automat, bo człowiek zawsze może mieć gorszy dzień.
10 lipca 2021 at 12:41
Dla mnie najważniejszy narzędzie zapewniającym dobrą jest szeroko pojęta komunikacja 🙂
Można używać najbardziej zaawansowanych metodyk i narzędzi ale jeśli działy nie umieją się między sobą najzwyczajniej po ludzku dogadać, to projekt bedzie szedł jak krew z nosa.
A z bardziej technicznych rzeczy to przede wszystkim kultura „Code review”. I nie chodzi tutaj oto aby się biczować wzajemnie i pokazywać kto ma „większego” tylko aby więcej osób miało wiedzę co leci do kodu
i ewentualnie pomogło w wyłapaniu jakiś oczywistych błedów.
Trzecią rzeczą są tak zwane „testy krytyczne” odpalane przy każdym commicie. Testujemy najważnijsze obszary naszego systemu które po prostu muszą działać (moga to być testy e2e bądź integracyjne).
Ostatnią rzecz to wszelkie narzędzia do statycznej analizy kodu, nie jest to niezbędne ale potrafi wyłapać jakieś oczywiste oczywistości zławszcze jeśli mamy dużo świeżych osób w zespole.
9 lipca 2021 at 17:23
1. Lintery poza tymi dostępnymi wszędzie mamy również swoje własne, które pilnują, żeby – kod z konkretnych pakietów nie było wołany przez inne (helpery nie powinny mieć zależności do kodu produkcyjnego)
– używać jednej biblioteki do implementacji interfejsu (np generowanie UUID, logger itp)
2. Sourcegraph bardzo ułatwia czytanie ale przede wszystkim wyszukiwanie kodu (np dobrych przykładów użycia). A jak już się nam zdarzy znaleźć błąd to pozwala na wyszukanie go we wszystkich repozytoriach. Co więcej jeśli mamy zmianę którą trzeba wprowadzić w kilkunastu repozytoriach to wspomaga cały proces (batch changes).
9 lipca 2021 at 15:20
Kawa. Uniwersalne narzędzie które zapewnia nie tylko o lepszej jakości kodu. Ale również że ten kod w ogóle jest. Oczywiście z wielką mocą wiąże się wielka odpowiedzialność, i nie należy nadużywać tego jakże cudownego narzędzia.
9 lipca 2021 at 09:38
Wspólny, wśród członków zespołu, formatter kodu… Nic tak nie denerwuje jak niesformatowany kod i niezamierzone zmiany w kodzie poprzez automatyczne formatowanie u któregoś z członków zespołu. 🙂
9 lipca 2021 at 07:44
Jako, że jakiś czas temu mocniej zainteresowałem się tematem Clean Architecture to zwróciłem uwagę na bibliotekę Arch Unit (https://www.archunit.org/) do testowania architektury. Imho nic tak dobrze nie wpływa na jakość systemu jak jego architektura 😉
A Oli książki jeszcze nie mam 😉
9 lipca 2021 at 07:20
Według mnie gamechangerem ostatnich lat jest testcontainers. To, że w łatwy i powtarzalny sposób da się postawić do testów większośc baz danych, kafkę czy np awsa (localstack – chociaż tego nie używałem) pozwala pokryć testami o wiele więcej obszarów. Nie ma problemu ze stworzeniem swojego obrazu z np sambą – jeśli umiesz coś wrzucić w kontener dockera to już prosta droga do testowania w połączeniu z tym komponentem. I to po prostu działa jak w tutorialu 🙂
9 lipca 2021 at 06:58
Jeśli chodzi o pomoc w utrzymaniu jakości kodu to dobrze zorganizowane IDE to podstawa. Podczas pisania dzięki zwracaniu uwagi na „rzeczy zakreślane na żółto” można uczynić swój kod o wiele bardziej czytelnym, choćby definiując zmienne jako stałe, albo zamieniając zmienną w lambdzie na referencję do metody. Warto jednak pamiętać, że podpowiedzi IDE mogą być przydatne, ale nie stanowią ostatecznego wyznacznika, czasem uproszczone w ten sposób warunki są mniej czytelne niż kod bardziej opisowy.
8 lipca 2021 at 22:26
Na pewno jednym z ciekawszych narzędzi jest SonarQube, czyli narzędzie do statycznej analizy kodu. Dzięki temu można pisać kod mniej złożony, prostszy w utrzymaniu i mniej podatny na błędy