Czy serwer ciągłej integracji powinien egzekwować standardy kodowania?

Czy standardy / styl kodowania powinny być egzekwowane przez serwer ciągłej integracji z uruchomionymi narzędziami do analizy statycznej (np. PMD, StyleCop / FxCop) i niepowodzeniem kompilacji, jeśli standardy nie są przestrzegane? Jakiego rodzaju reguł nie należy używać do niepowodzenia kompilacji?

Standardy kodowania powinny istnieć z jakiegoś powodu ... i należy sprawdzić niezgodność.

Jednak nie wszystkie naruszenia należy traktować jako błędy - podobnie jak nie wszystkie naruszenia kompilacji. Tam, gdzie narysujesz linię, musi być firma i decyzja narzędzia.

Na przykład, MISRA definiuje swoje reguły jako Wymagane i Doradcze ... Sugerowałbym, że Doradztwo pozwoliłoby na kontynuację kompilacji.

Nie jest to zupełnie niespotykane i będziesz wiedział, czy to zadziała tylko po wypróbowaniu. Istnieje kilka kroków, które możesz podjąć wcześniej.

Najpierw zespół powinien wspólnie zdecydować o standardach. Następnie należy użyć narzędzi takich jak ReSharper, aby poinformować programistów, że nie przestrzegają standardów. Robienie wzajemnych ocen każdego zadania może dodatkowo pomóc.

Po wykonaniu tych kroków można rozważyć wprowadzenie standardowych kontroli kodowania na serwerze CI. Należy jednak wziąć pod uwagę, czy rozsądnie jest mieć przerwę kompilacyjną, aby nie stosować się do standardów kodowania. Ryzyko polega na tym, że będziesz mieć wiele zepsutych wersji, które mogą osłabić znaczenie zepsutej wersji.

Zamiast przerywać kompilację, możesz uruchomić narzędzia i zlecić im tworzenie raportów. Jeśli kodowanie standardowych naruszeń wydaje się rosnąć, możesz zebrać zespół i dowiedzieć się, dlaczego tak się dzieje.

Czy standardy / styl kodowania powinny być egzekwowane przez serwer ciągłej integracji z uruchomionymi narzędziami do analizy statycznej (np. PMD, StyleCop / FxCop) i niepowodzeniem kompilacji, jeśli standardy nie są przestrzegane?

Te ciągłe kontrole integracji muszą być bardzo, bardzo szybkie. Wszelkie znaczące opóźnienia będą oznaczać, że programiści popełniają i tracą kontrolę nad procesem myślowym, czekając na wyniki. Wydłużyć czas, a oni popełniają i napiją się kawy lub pogadają z kolegami z biura na temat najnowszego występu jakiejś drużyny sportowej. Opóźnienia te przynoszą efekt przeciwny do zamierzonego. Niektóre rzeczy najlepiej pozostawić nocnej kompilacji lub przeglądowi kodu.

Jakiego rodzaju reguł nie należy używać do niepowodzenia kompilacji?

Na początek subiektywne. W jaki sposób egzekwujesz zasadę „Kodeks powinien być samo dokumentujący się lub dobrze komentowany”? Zasada „brak magicznych liczb”? Te rzeczy najlepiej pozostawić do przeglądu kodu.

Kolejną kategorią są naruszenia przepisów, które uzyskały już zwolnienie. Biorąc pod uwagę sporą bazę kodu, nieuchronnie pojawi się fragment kodu, w którym naruszenie standardu jest właściwym rozwiązaniem.

W ramach Planu poprawy jakości oprogramowania niedawno zakodowaliśmy serię wąchania kodu w celu zintegrowania go z naszym procesem kompilacji.

Dużo budujemy, będąc aplikacją PHP, nie ma prawdziwej kompilacji, więc kompilacja jest tak naprawdę testem jednostkowym / analizą statyczną / programem uruchamiającym, i możemy sobie pozwolić na poświęcenie na to kilku cykli.

Mieliśmy pewne problemy z jakością kodu i trochę starszego kodu z wieloma problemami.

Zaczynając od tego, że jeśli nie powiedzie się zatwierdzenie, zostanie ono zignorowane, zaczęliśmy potwierdzać zatwierdzenia względem naszego „pożądanego” standardu kodowania, a niepowodzenie zatwierdza z błędami, które nie spełniają tego standardu.

Konserwacja została zatrzymana, nawet najprostsza poprawka do starszego komponentu wymagała od programisty sformatowania ogromnych ilości źródeł, a kompilacja była przerywana częściej niż nie. Nie trzeba dodawać, że zmieniliśmy błędy na ostrzeżenia, a teraz są one ignorowane i „w większości” bezcelowe.

Powiedziałbym to (wyciągnięte z trudnego doświadczenia).

Upewnij się, że standard bazy kodu jest wystarczająco zbliżony do standardu, który wymuszasz, aby nie wymagało od programisty natychmiastowego formatowania woluminów kodu. Lub .. Jesteś przygotowany i oczekujesz wzrostu wysiłku.

Będąc małym zespołem z ogromnymi wymaganiami dotyczącymi dostawy, nie było nas stać na zmianę zespołu na ogromną operację ponownego uwzględnienia czynników. Nasze standardy kodowania są obecnie obsługiwane głównie przez przegląd ręczny, a spuścizna jest przepisywana jako część planu ciągłego doskonalenia.

Kiedy powiedziałem, że ostrzeżenia są „przeważnie” bezcelowe, teraz używamy ich do rejestrowania statystyk, które pozwalają nam mierzyć KPI, które powinny wykazywać poprawę.

Kiedy ponownie wymuszymy wąchanie kodu, zaczniemy lekko i wprowadzamy kilka wąchań na raz, dopóki nie wprowadzimy standardu.

Będzie to zależeć od twojego ostatecznego celu i strategii .

Wymuszanie wszystkich wymienionych wyżej dobrych standardów na serwerze CI może wydawać się bardzo intratne. Jednak może być niepraktyczne dla dużego (ponad 6 programistów) zespołu programistów, jeśli jest to wykonywane przy każdym zatwierdzeniu do serwera. Oczekiwanie na odpowiedź serwera po zatwierdzeniu NIE powinno być długim opóźnieniem. Może to spowodować pewne przestoje.

Jednak jest całkowicie uzasadnione, aby zablokować zatwierdzenie, jeśli kod (faktycznie zestaw zmian) ma problemy z zależnością lub się nie kompiluje. Jednak błąd kodu z powodu układu kodu i niektórych konwencji nazewnictwa może być zbyt poważny i nie jest istotnym ograniczeniem dla reguł zatwierdzania serwera CI.

Ale jest bardzo prawdopodobne, że będzie pomocna zasada, jeśli zostanie zastosowana podczas kompilacji wieczorem.

Ponadto narzędzia do przefakturowania mogą pomóc we wdrażaniu i poznawaniu standardów - takich jak użycie Resharper lub JustCode przez programistów.