Wytwarzanie softu w ujęciu jakości - dobre praktyki

Hej,
mam do was pytanie odnośnie procesu developerskiego, zwłaszcza jak w nim zapewniacie jakość, może opisze jak to u nas wygląda i ciekawi mnie jak to jest u was z jakich narzędzi korzystacie, jakie standardy macie ?

Status:
System w Java (Spring,Hiiberante,Swing) około 3 mln linii kody, modułowy monolit (około 500 modułów mavena zależnych od siebie), rozwijany przez 20 osób od 15 lat, aktualnie aplikacja jest wdrożona na wielu serwerach (100) u wielu klientów w wielu wersjach (5), najstarsza wersja ma rok, system jest customizowany na produkcji stąd proces aktualizacji niezawsze jest prosty (nawet przy nastawieniu kontatybilności wstecznej)

Proces:

1. Klient zgłasza błąd do programu w wersji X, HelpDesk /JIRA
2. Błąd jest klasyfikowany priorytet + moduł
3. Błąd trafia do backloga skąd kierownik modułu przypisuje błąd do programisty, jak planować prace rozwojowe skoro nie wiadomo ile błędów wpadnie :-/
4. Programista rozwiązuje błąd i zrzuca do SVN do master (rozwój) + do wersji (branche'a) którego błąd dotyczy
   4.1) W trakcie pracy programista może pisać testy jednostkowe lub integracyjne ale nikt tego nie sprawdza, brak wytycznych jak je robić
   4.2) Nikt nie przegląda kodu który zrzuca programista, kto to u was robi, przypadkowa osoba czy osoba która ma pojęcie o zadaniu robionym przez programiste
   4.3) Ewentualne błędy może wychwycic CI jako Jenkins czyli błędy kompilacji + testów, kto tropi ewentualne problemy, że cześć testów przestała chodzić po ostatnim buildzie na jenkins w sytuacji kiedy do tego samego code base zrzuca 20 osób, kto jest winny?
   4.4) Brak narzędzi i kultry pracy z narzędziami typu Sonar, kiedyś był Sonar ale wygenerował on 10 tys ostrzeżeń i nie wiadomo co było z tym robić - w sensie zatrzymać prace rozwojowe na 6 miesięcy czy jak
5. Z brancha wychodzi wersja z poprawka -> tag
   5.1) Brak CD, wersje wypuszcza sie narzędziem manualnie
6. Nowa wersja jest wgrywana na środowisko testowe klienta i tam weryfikowana przez klienta

W jakis sposób wy wytwarzacie i zapewniacie jakość na każdym z tych etapów, ilu osób jest w to zaangażowane, kiedyś pracowałem w firmie gdzie na 4 programistów jeden tylko robił przeglądy kodu

Jeśli chodzi o Sonara to działa mi (czasem lepiej, czasem gorzej) jedna zasada i to od dawna: nie pogarszać.
Czyli nawet jak jest tam 10000 problemów to zmianie ma być max 10000, oczywiście fajnie jak jest mniej.
W dość syfnym kodzie bywa tak, że naprawiamy 4 sonaroww problemy... ale dokładamy 2 nowe (i tak jest na plus).
Zasada mocniejsza - nie dokładamy żadnych nowych issues.

Sonar prawie od zawsze ma możliwośc pokazywania delty, ma też możliwośc pokazywania "my issues"

Poza sonarem to dokładam checkstyle, a od czasu kotlinowania - detekt, dzięki temu sprawdzanie jest w buildzie - zrobisz syf to się paczka nie zbuduje.
Detekt ma tą zaletę, że można ustawić ile punktów spie...nia przepuszczamy - czyli można wstawić do już mocno popsutego projektu, żeby pilnować coby nie zepsół się bardziej.

Ważne, żeby móc zmieniać reguły sonara (jak jest konsensus)- nie ma nic gorszego niż sonar wymuszający styl, którym wszyscy w zespole gardzą, albo raportujący totalnie bzdetne problemy (nagłówki plików :-)).

4.3) wszyscy są winni. Wolne CI jest winne, osoby które commitowały do projektu z wywalonymi testami są winne.
Jeśli nikt nie zgłasza sie do naprawania, (ewentualnie tylko ty) lub są nienaprawialne to:
a) zmień firmę lub zespół,
b) skasuj te testy (i tak są niepotrzebne) (ale żadnego @Ignore, kasuj na twardo - to potrafi przemówić do ludzi, potrafi też nie przemówić :-( )

4.2) przeglądy - prawie nie pamiętam sytuacji, żeby tu nie było jakiejś farsy
najczęściej działa zasada: wrzuć commit na 5 linii dostaniesz 10 uwag, zrób commit na 10000 linii i nie będzie żadnej
teoria jest taka, żeby commity były małe - praktyka jest taka, że nie umiem nad tym zapanować, sam wrzucam potwory

SVN i dalej można nie czytać. Nie da się dobrze pracować na branchach w SVNie. Bo SVN nie umożliwia w łatwy sposób merdzowania zmian. A jak nie da się w łatwy sposób pracować na branchach to robienie review i na CI testów osobno po każdej zmianie jest w zasadzie niemożliwe albo bardzo trudne.

Co do Sonara to jak ostatnio konfigurowałem z architektem Sonara to okazało się że domyślnie posiada on sprzeczne reguły. I dla wielu par sprzecznych reguł trzeba było wybrać tą którą chcemy. Poza tym sonar posiada priorytety ostrzeżeń. Zwykle na 100 tylko 5 jest krytyczne i to je trzeba poprawić w pierwszej kolejności

U mnie code review czynione jest przez wszystkich pozostałych członków zepsołu (oczywiście backend developer robi tylko review backendowe). Nie korzystamy z Sonara.

jarekr000000 napisał(a):

najczęściej działa zasada: wrzuć commit na 5 linii dostaniesz 10 uwag, zrób commit na 10000 linii i nie będzie żadnej

Zależy też, na jakim poziomie te uwagi z code review. Faktycznie jest tak, że pull request z 10000 linii kodu ciężko analizować, bo trzeba by naprawdę długo nad tym siedzieć i wnikliwie czytać. Natomiast wydaje mi się, że oprócz samych "poprawek estetycznych", można wówczas ocenić trochę na wyższym poziomie abstrakcji - styl architektoniczny, jakie wzorce projektowe zostały zastosowane, jak klasy i ich powiązania zostały zaprojektowane. Czy testy obejmują żądane przez nas flow. Skorzystam z chwili uwagi i wkleję artykuł w którym pisałem właśnie o różnych rodzajach uwag w code review: https://www.sages.pl/blog/code-review-czyli-merytoryczna-krytyka-siebie-i-innych

Nikt nie przegląda kodu który zrzuca programista

Bo i jak to ma robić skoro nie macie do tego narzędzi? Jakbyście mieli jakiegoś gitlaba to robisz merge request i ktoś go może wygodnie reviewować i potem mergować.

kto to u was robi, przypadkowa osoba czy osoba która ma pojęcie o zadaniu robionym przez programiste

Ktoś kto ma pojęcie o projekcie, a o konkretny task może ewentualnie spytać, ale też powinno być dość jasne co ten merge request robi.

W trakcie pracy programista może pisać testy jednostkowe lub integracyjne ale nikt tego nie sprawdza, brak wytycznych jak je robić

To jest problem wśród zespolu programistów, bo to wy ustalacie "wytyczne" oraz co jest konieczne do "zakończenia" taska.

No właśnie takie odebrałem wrażenie widząc wytyczne i weryfikacje xD Dorośli ludzie a zachowują sie jak dzieci

Może odniosę się do komentarza @Shalom, zgadza się, jesteśmy dorośli tylko od dłuższego czasu do IT przyszło sporo osób skuszonych $$$, to już nie są pasjonaci, a robotnicy, którzy mają ogólnie gdzieś standardy, testy, pokrycie kodu itp, ogólnie o tym nie słyszeli (nie mówie, że wszyscy) i w sytuacji kiedy tacy ludzie stanowią 50% zespołu to robi się problem, dlatego zastanawiamy się jak wy sobie radzicie z zapewnianiem jakość pracując z takimi ludzmi. Umówmy się, że odpowiedz "nie no robimy dobrze bo tak trzeba" tutaj nie działa.

P.S Przypomnijcie sobie projekty w których pracowaliście i były "spierniczone", przecież to nie jest tak, że kiedyś Ci pierwsi programisci tego systemu powiedzieli sobie "ale to teraz specjalnie spierdo....", pewnie też chcieli dobrze a coś nie wyszło...

w sytuacji kiedy tacy ludzie stanowią 50% zespołu

Jak sobie takich ludzi pozatrudnialiście do zespołu, to jest wasz problem.

jak wy sobie radzicie z zapewnianiem jakość pracując z takimi ludzmi

Zatrudniasz A-playerów i problem w ogóle nie występuje.

przecież to nie jest tak, że kiedyś Ci pierwsi programisci tego systemu powiedzieli sobie "ale to teraz specjalnie spierdo....", pewnie też chcieli dobrze a coś nie wyszło...

Generalnie każdy system z czasem się "psuje", niewiele da się z tym zrobić, trzeba co jakis czas orać i przepisywać. Ale im więcej masz w teamie słabych ludzi, tym szybciej to będzie przebiegać.