Pracuję nad ogromnym projektem (bardziej jak splątaną kombinację dziesiątek mini projektów, których nie można łatwo rozdzielić z powodu złego zarządzania zależnościami, ale to inna dyskusja) w Javie za pomocą eclipse. Wyłączyliśmy już wiele ostrzeżeń w ustawieniach kompilatora, a projekt nadal zawiera ponad 10 000 ostrzeżeń.
Jestem wielkim zwolennikiem próby rozwiązania wszystkich ostrzeżeń, naprawienia wszystkich, jeśli to możliwe, a dla tych, które są sprawdzane i uważane za bezpieczne, pomijaj je. (To samo dotyczy mojej religijnej obsesji na punkcie oznaczania wszystkich zaimplementowanych / zastąpionych metod jako @Override). Moim największym argumentem jest to, że generalnie ostrzeżenia pomagają znaleźć potencjalne błędy podczas kompilacji. Może na 99 na 100 ostrzeżeń ostrzeżenia są nieznaczące, ale myślę, że drapanie się w głowie, które oszczędza po raz pierwszy, że zapobiega poważnemu błędowi, wszystko jest tego warte. (Moim drugim powodem jest mój pozorny OCD z czystością kodu).
Jednak wielu moich kolegów z drużyny nie przejmuje się tym. Czasami naprawiam ostrzeżenia, gdy się na nie natknę (ale wiesz, że to trudne, kiedy dotykasz kodu napisanego przez współpracownika). Teraz, gdy dosłownie jest więcej ostrzeżeń niż klas, zalety ostrzeżeń są bardzo zminimalizowane, ponieważ gdy ostrzeżenia są tak powszechne, nikt nie będzie zawracał sobie głowy ich analizowaniem.
Jak mogę przekonać moich kolegów z drużyny (lub ich moce), że ostrzeżenia należy rozwiązać (lub je stłumić po pełnym zbadaniu)? Czy powinienem przekonać się, że jestem szalony?
Dzięki
(PS Zapomniałem wspomnieć o tym, co ostatecznie skłoniło mnie do opublikowania tego pytania, ponieważ z przykrością zauważyłem, że naprawiam ostrzeżenia wolniej niż się pojawiają)
javac
.-Wall -Wextra -Werror
(tj. aktywowanie większości dostępnych ostrzeżeń, traktowanie ich wszystkich jako błędów). Zaćmienie C ++ jest jednak prawie bezużyteczne: /Odpowiedzi:
Możesz zrobić dwie rzeczy.
Wskaż, że istnieją ostrzeżenia z jakiegoś powodu. Autorzy kompilatorów nie umieszczają ich, ponieważ są wredni. Ludzie z naszej branży są na ogół pomocni. Wiele ostrzeżeń jest pomocnych.
Zbierz historię spektakularnych awarii wynikających z ignorowania ostrzeżeń. Wyszukiwarka „Zwróć uwagę na ostrzeżenia kompilatora” zwraca pewne anegdoty.
Twoja obsesja
@Override
nie jest „obsesją”. To jest dobra rzecz. Czy kiedykolwiek źle napisałeś nazwę metody?źródło
if (error = 0)
zamiastif (error == 0)
. Ponadto wiele ostrzeżeń znacznie ułatwia znajdowanie błędów kompilatora bez konieczności przechodzenia przez szereg ostrzeżeń.Odpowiednie czytanie tutaj . C ++, ale nadal aktualne. Szczególnie podoba mi się ten przykład (komentarz do kodu jest mój):
Często ostrzeżenie będzie oznaczało różnicę między awarią aplikacji z błędem, która faktycznie pomoże wyśledzić wadę projektową i naprawić ją (np. Bezpieczne rzutowanie czcionek) lub aplikację przyjmującą założenia, a następnie zachowującą się nieprawidłowo lub błędny sposób (co miałoby miejsce w przypadku niebezpiecznego rzutowania). Podobnie wskazują również cruft lub martwy kod, który można usunąć (nieosiągalne bloki kodu, nieużywane zmienne), co można uznać za optymalizację kodu lub przypadki nieuwzględnione w testach, jak powyższy przykład dla C ++. Zauważ, że ten przykład powoduje błąd kompilacji w Javie.
Tak więc naprawianie ostrzeżeń ma (przynajmniej) kilka zalet dla zarządzania:
Zauważ, że wciąż jestem młodszym programistą, który niewiele wie o zarządzaniu projektami, więc jeśli powiedziałem coś nie tak, popraw moje myślenie i daj mi szansę na edycję, zanim zdążysz głosować za mną :)
źródło
W przeszłości pracowałem nad projektem o podobnych cechach. Ten w szczególności został pierwotnie napisany w Javie 1.4. Gdy pojawi się Java 5 z ogólnymi wersjami, można sobie wyobrazić liczbę ostrzeżeń generowanych przez kompilator przy każdym użyciu interfejsu API kolekcji.
Rozpoczęcie używania leków generycznych zajęłoby sporo czasu, aby pozbyć się wszystkich ostrzeżeń. Jest to czynnik, który należy wziąć pod uwagę, ale gdy musisz przekonać kogoś (szczególnie swojego kierownika), że wymaga on naprawy, będziesz potrzebować twardych danych, takich jak
Możesz nadal przedstawiać rachunek, który pokazuje, w jaki sposób tracisz czas i pieniądze, ignorując „pewne” ostrzeżenia, a ktoś wpadnie na ten pomysł. Najważniejsze jest to, że nie wszystkie ostrzeżenia są warte obejrzenia, przynajmniej nie od razu; mówiąc prościej, należy ustalić priorytet ostrzeżeń, które należy natychmiast rozwiązać. Na początek rozważ te związane z błędami, które widzisz w swoim projekcie.
Możesz również robić notatki w narzędziu do śledzenia błędów, kiedy naprawiasz błędy, że wspomnianego błędu można było uniknąć, nie ignorując ostrzeżenia (a może uruchamiając PMD lub FindBugs, jeśli masz CI lub system kompilacji). Dopóki istnieje wystarczająca liczba błędów, które można naprawić, słuchając ostrzeżeń kompilatora, twój punkt widzenia na temat ostrzeżeń kompilatora byłby ważny. W przeciwnym razie jest to decyzja biznesowa i zwykle nie warto poświęcać czasu na walkę.
źródło
Jeśli ci się powiedzie, a twój zespół postanowi przestrzegać ostrzeżeń, powinieneś podejść krok po kroku. Nikt nie może i nie będzie 10000 ostrzeżeń jednocześnie. Możesz więc wybrać te najważniejsze (te, które są błędami z dużym prawdopodobieństwem) i wyłączyć te mniej znaczące. Jeśli są naprawione, ponownie zwiększ poziom ostrzeżenia. Dodatkowo możesz zacząć od FindBugs, który ostrzega przed kodem, który prawie zawsze jest błędem.
źródło
Całkowicie się z tobą zgadzam, najlepszą praktyką jest jak najczystsze czyszczenie ostrzeżeń kompilacji. Wspomniałeś, że twój zespół używa Eclipse jako narzędzia programistycznego. Eclipse to bardzo dobre narzędzie, które pomaga oczyścić kod i zapewnić spójność stylu kodu.
Eclipse utworzy niektóre pliki właściwości dla tych preferencji w folderze .settings, możesz skopiować je do innych projektów Java i sprawdzić je w SCM jako część kodu źródłowego.
Możesz sprawdzić kod Eclipse, aby zobaczyć, jak robią to deweloperzy Eclipse.
źródło
Istnieją dwa sposoby na pozbycie się wszystkich ostrzeżeń (i zgadzam się, że może ukryć subtelny błąd):
Uważam, że 1 nie jest już w twoim przypadku wykonalny. Prawdopodobnie zajmie to tak dużo czasu ze względu na liczbę ostrzeżeń, które pojawią się na wydajności, więc kierownictwo i tak będzie musiało wiedzieć.
Tak więc proponuję: weź to z szefem, przekonaj go, że to tykająca bomba, i niech to oficjalna polityka.
źródło
Powiedziałbym im po prostu, że większość z nich to nieistotne ostrzeżenia i ważne jest, abyśmy usunęli je z listy. Aby nie przegapić prawdziwego znaczącego ostrzeżenia w tłumie, jak to się dzieje!
źródło
Będziesz potrzebował dużo cierpliwości, próbując ich przekonać, usunięcie ostrzeżeń podczas programowania w parach pomoże innym nabrać nawyku. Zaproponuj, aby przeczytali „Efektywna Java” pozycja 24: Wyeliminuj niesprawdzone ostrzeżenia (dla zbioru ogólnego). I prawdopodobnie zignoruj wiele przypadków, w których ludzie nie będą postępować zgodnie z twoją radą;)
źródło
Skutecznym podejściem byłoby tutaj skonfigurowanie serwera Continuous Integration , który automatycznie buduje projekt i uruchamia testy za każdym razem, gdy ktoś sprawdza kod. Jeśli jeszcze tego nie używasz, powinieneś i nie jest trudno przekonać innych o korzyściach płynących z tego.
Przekonaj kierownictwo / kierowników zespołów o korzyściach płynących z tego (zapobieganie wdrażaniu złych wersji, wczesne wykrywanie błędów, szczególnie tych, które przypadkowo wpływają na inne części oprogramowania, utrzymywanie testów regresji, wczesne i częste testowanie itp.)
Zainstaluj serwer CI z pozytywnym wynikiem wszystkich testów (jeśli nie masz testów, napisz szybki, który przejdzie, aby wszyscy widzieli, że jest zielony).
Skonfiguruj wiadomości e-mail lub inne powiadomienia o stanie każdej kompilacji. Ważne jest tutaj, aby podać, kto sprawdził w kodzie, jaka była zmiana (lub link do zatwierdzenia) oraz status + wyjście kompilacji. Jest to ważny krok, ponieważ powoduje widoczność w całym zespole zarówno pod względem sukcesów, jak i porażek.
Zaktualizuj serwer CI, aby testy zakończyły się niepowodzeniem, jeśli pojawią się jakieś ostrzeżenia. Kierownictwo i kierownicy zespołu postrzegają to jako systematyczne zwiększanie dyscypliny zespołu i nikt nie chce być odpowiedzialny za wszystkie wiadomości e-mail o niepowodzeniach.
(opcjonalnie) bądź miły i naukowy dzięki dodaniu widocznych pulpitów nawigacyjnych, lamp lawowych, migających świateł itp., aby wskazać status kompilacji i kto ją zepsuł / naprawił.
źródło