Jak sprzeciwić się obniżeniu standardów jakości dla starej bazy kodów? [Zamknięte]

28

Mamy tutaj dużą bazę kodu ze złym kodem, którego nie można sobie wyobrazić.

Zdefiniowaliśmy teraz niektóre standardy jakości i chcemy je spełnić w zupełnie nowej bazie kodu, ale także, jeśli dotkniesz starszego kodu.

I egzekwujemy te za pomocą Sonar (narzędzie do analizy kodu), które ma już kilka tysięcy naruszeń.

Teraz zaczęła się dyskusja, aby zmniejszyć te naruszenia dziedzictwa. Ponieważ to dziedzictwo.

Dyskusja dotyczy zasad czytelności. Na przykład ile zagnieżdżonych ifs / for .. może mieć.

Jak mogę się teraz sprzeciwić obniżeniu jakości kodowania starszego kodu?

keiki
źródło
2
jest dyskusja na temat obniżenia progów narzędzia? ... lub źle to zrozumiałem. Jest napisane w mylący sposób.
Dagnelies,
4
Pytanie ma bardzo niejasne części. „obniż te naruszenia” - czy masz na myśli obniżenie faktycznej liczby naruszeń (poprzez przepisanie starego kodu), liczby reguł przetestowanych przez Sonar w bazie kodu starszego lub liczby reguł standardu kodowania, których chcesz przestrzegać podczas zmiany czegoś w starszym kodzie?
Doc Brown
4
Mamy też starszą wersję o okropnej jakości kodu. Ponieważ zostanie zastąpiony przez nowy produkt, czyszczenie starego kodu prawie nie ma żadnej wartości. Oznacza to: akceptujemy niższy standard w bazie kodu starszego typu.
Bernhard Hiller
4
@keiki: wciąż niejasne: czy nowa baza kodu jest wystarczająco oddzielona, ​​aby mieć różne reguły sprawdzania poprawności dla starego i nowego kodu? Co z częściami, które zmieniasz w bazie kodu starszego typu? Czy masz problem z tym, że podniesienie zmienionych części do wyższych standardów powoduje zbyt duży wysiłek, czy też nie możesz oddzielić tych części w walidacji Sonaru, aby umożliwić walidację tylko tych zmienionych części w całości?
Doc Brown

Odpowiedzi:

73

Kod jest tylko środkiem do celu. Jaki może być ten koniec, jest różny, ale zazwyczaj jest to zysk.

Jeśli to zysk; następnie skutecznie argumentować wszystko, co chcesz wykazać, że poprawi to zysk - np. poprzez zwiększenie sprzedaży, zmniejszenie kosztów utrzymania, zmniejszenie kosztów prac rozwojowych, zmniejszenie wynagrodzeń, zmniejszenie kosztów przekwalifikowania itp. Jeśli nie możesz / nie pokażesz, że to będzie poprawić zysk; wtedy mówisz po prostu, że fajnie byłoby spłukać pieniądze w toalecie.

Brendan
źródło
15
Wierzę, że w tej dyskusji jest inny wymiar, którym jest profesjonalizm, w wielu zawodach, jeśli twój szef poprosi cię o skrócenie narożników, możesz odmówić zrobienia tego na podstawie moralnej (czasami nawet prawo cię wspiera), ja nie zrozumieć, dlaczego programiści powinni zachowywać się inaczej.
Alessandro Teruzzi
21
@AlessandroTeruzzi Możesz odmówić robienia czegokolwiek na (osobistych) podstawach moralnych, niezależnie od profesjonalizmu. Nie gwarantuje jednak, że nadal będziesz pracować w tym miejscu.
Kromster mówi o wsparciu Moniki
Ponadto, gdy bazy kodowe są często bardzo skomplikowane, trudno byłoby udowodnić którąkolwiek z wymienionych rzeczy, nawet jeśli doświadczony programista może z doświadczenia wiedzieć, że cięcie na rogach będzie kosztowne w dłuższej perspektywie.
mkataja
17
Nic złego w tej odpowiedzi, ale mimo to nie jest przydatne w większości rzeczywistych sytuacji. Poprawa jakości bazy kodu często obniża koszty utrzymania, szczególnie w dłuższej perspektywie, ale efekty te rzadko są kwantyfikowalne. Dlatego często jest to decyzja strategiczna.
Doc Brown
2
@DocBrown Wstępnie się zgadzam, ale myślę, że rozwój oparty na liczbie zagnieżdżonych, jeśli, a la OP, nie jest skutecznym podejściem do poprawy starszej bazy kodu.
brian_o
44

Ja, ja i ja, byliśmy zarówno producentem, jak i opiekunem starszego kodu. Jeśli Twoje narzędzie generuje „tysiące naruszeń” (a nawet setki w tym przypadku), zapomnij o narzędziu, nie ma to zastosowania do sytuacji ...

Zakładam, że pierwotni programiści już dawno minęli i są niedostępni do dyskusji. Więc nikogo nie ma w pobliżu, kto rozumie, dlaczego i dlaczego styl projektowania i kodowania. Korekta setek lub tysięcy naruszeń nie będzie polegać na przepisywaniu kilku wierszy kodu tu i tam. Zamiast tego niewątpliwie wymaga to refaktoryzacji / ponownego rozkładu funkcjonalnego. Próbujesz zrobić to z dowolną dużą istniejącą bazą kodu, bez dogłębnego zrozumienia jej obecnego projektu, i na pewno wprowadzisz nowy zestaw błędów / problemów / itp. Nowa puszka robaków jeszcze gorsza niż ta, którą teraz masz (lub gorsza niż twoje narzędzie >> uważa << teraz masz).

Jedynym rozsądnym podejściem do rozwiązania problemu „tysięcy naruszeń” byłoby przepisanie od zera. Długi i kosztowny wysiłek, a sprzedaż prawie niemożliwa do sprzedania kierownictwu. I w tym przypadku prawdopodobnie mają rację ...

Starszy kod zwykle wymaga tylko poprawek. Jak dla y2k lub kiedy zapasy wzrosły z 256. na dziesiętne. Zrobiłem mnóstwo tego cr * p. I wiele innych podobnych rzeczy. Zazwyczaj jest to dość „precyzyjne”, ponieważ można „odczytać” czasami zły styl, zły rozkład funkcjonalny, zły itp. I zlokalizować zbiór miejsc, które należy zmodyfikować. A zatem to, co dzieje się „między tymi miejscami”, tj. Jaki jest przepływ na wyższym poziomie, może pozostać dla Ciebie tajemnicą. Upewnij się tylko, że rozumiesz zlokalizowaną funkcjonalność, którą zmieniasz, a następnie przetestuj, przetestuj, przetestuj pod kątem skutków ubocznych itp., Twoja zlokalizowana wiedza nie będzie w stanie przewidzieć.

Jeśli nie możesz przejść przez taki kod, być może nie jesteś najlepszą osobą do utrzymania starszego kodu. Niektórzy ludzie mogą zacząć od pustego ekranu i pisać piękne programy, ale nie mogą zacząć od dużej bazy kodu kodu innych ludzi i utrzymywać go. Inne osoby mogą utrzymywać kod, ale nie mogą zaczynać od zera. Niektórzy mogą zrobić jedno i drugie. Upewnij się, że odpowiednie osoby zachowują Twój starszy kod.

Od czasu do czasu możesz chcieć przeprojektować i przepisać starszą bazę kodu od zera, gdy wymagania biznesowe (lub inne) zmieniają się do tego stopnia, że ​​„usprawnienia” siedzących spodni po prostu nie są już w stanie sprostać zmienionym wymaganiom . W tym momencie równie dobrze możesz zacząć od napisania nowego dokumentu wymagań funkcjonalnych, upewniając się, że wszyscy interesariusze są na pokładzie. Zasadniczo jest to zupełnie nowa gra w piłkę.

Jedyną >> niewłaściwą << rzeczą do zrobienia jest próba zachowania starszej wersji kodu w taki sam sposób, jak w przypadku nowego programowania. I ta jedna zła rzecz wydaje się być dokładnie ścieżką, którą chciałbyś pójść w dół :) Uwierz mi na słowo, to nie jest to, co chcesz zrobić.

John Forkosh
źródło
2
Odpowiada to na pytanie „Czy dziedzictwo powinno zostać przepisane”. Ale OP nie pyta, jak naprawić ostrzeżenia lub czy przepisanie powinno nastąpić. Pytanie dotyczyło standardu jakości - w zasadzie wymaganie, aby każda zmiana nie zwiększała liczby ostrzeżeń walidacyjnych.
Basilevs,
9
Odnosi się to bezpośrednio do pytania, które nie dotyczy przepisywania. OP chce argumentować za „troską o utrzymanie starszego kodu w taki sam sposób, jak w przypadku nowego rozwoju”. Ta odpowiedź mówi „WOAH! Nie powinieneś tego robić!” Może nie być odpowiedzią OP lub chciałeś usłyszeć, ale całkowicie reaguje na pytanie.
Jonathan Eunice,
1
@Basilevs (i @ JonathanEunice). Co powiedział Jonathan. Zauważ, że zacząłem od bezpośredniego powiedzenia „zapomnij o narzędziu, nie ma zastosowania do sytuacji”, co bezpośrednio odnosi się do pytania, choć negatywnie. Ale jak mówi przysłowie, jeśli zamierzasz krytykować, proponuj konstruktywną krytykę. Nie mogłem więc po prostu powiedzieć „nie rób tego”. Musiałem też zasugerować, co robić zamiast tego (i stało się to trochę bardziej skomplikowane niż się spodziewałem, kiedy zacząłem pisać).
John Forkosh
1
Podczas pracy ze starszymi projektami kodu czasami lubię projektować warstwę interfejsu, która znajduje się pomiędzy starym a nowym kodem. Pozwala to na czysty podział między starymi i nowymi częściami i ułatwia rozwiązywanie problemów z nowymi częściami, niż gdyby zostały one wklejone z pakietem kodu, którego nie rozumiem.
supercat
@supercat Jeśli można to zrobić, z pewnością jest to miłe podejście. Ale przywołując różne moje projekty naprawcze w stylu y2k, musiałeś po prostu „zanurzyć się” w środku istniejącego kodu i go zepsuć. Niemożliwe (ponowne) faktoring w stare / nowe możliwe (bez >> masywnego << przepisania). Na przykład zamiast dodawać dwa bajty do pól daty na czterobajtowy rok w formacie ccyy, wymagający hurtowych aktualizacji ogromnych baz danych, wystarczy interpretować yy> 50 jako 19yy, a yy <= 50 jako 20yy. Ale jedyną sensowną implementacją tego jest wiele drobnych zmian w każdym miejscu, w którym używa się yy.
John Forkosh,
13

Pytanie nie brzmi, jak dobry lub zły jest ten kod. Pytanie brzmi: ile zyskujesz z tego, ile inwestycji.

Masz więc narzędzie, które znajduje tysiące rzeczy, których nie lubi. Możesz zignorować wyniki narzędzia lub zainwestować pracę, aby zmienić tysiące rzeczy. To dużo rzeczy. Ludzie nie będą skupieni, nie podczas dokonywania zmian, ani podczas ich przeglądu, a to nie zostanie odpowiednio przetestowane, ponieważ wymyślenie, jak przetestować (lub po prostu wypróbować) każdą zmianę, zajmie wieki, więc pojawią się błędy. Więc dopóki nie znajdziesz i nie naprawisz tych błędów, zainwestowałeś dużo czasu i pieniędzy z ogólnym negatywnym wynikiem.

Z drugiej strony narzędzia mogą znajdować rzeczy, których nie tylko „nie lubią”, ale które są błędami lub potencjalnymi błędami. Jeśli starszy kod jest nadal w powszechnym użyciu, odpowiednie narzędzie może faktycznie znaleźć błędy. Dlatego przełączanie ostrzeżeń kompilatora jeden po drugim, sprawdzanie, czy są one użyteczne (nie wszystkie są przydatne) i naprawianie tych ostrzeżeń może być opłacalne.

gnasher729
źródło
2
Kiedyś przyszedłem do projektu, który został wykonany szybko (zignorowałem ostrzeżenia kompilatora itp.). Projekt był bałaganem, wystąpił błąd. Liczba się przepełniała. Zespół szukał przez 2 tygodnie. Skonfigurowałem środowisko kompilatora z włączonymi wszystkimi flagami ostrzegawczymi (liczba wzrosła z 500 do wielu tysięcy ostrzeżeń). Przeszedłem przez wszystkie ostrzeżenia. Po zaledwie 3 godzinach miałem 0 ostrzeżeń. Z jakiegoś powodu kod działał. Ale nie wiedzieliśmy dlaczego. Przy każdej zmianie przypisałem kod do mojego oddziału. Po kilku poszukiwaniach znalazłem to. Funkcja niejawnie zadeklarowana, która spowodowała, że ​​C zmienił wartość zwracaną.
CodeMonkey,
7

Jeśli to nie jest zepsute, nie naprawiaj tego

To praktycznie powinno być wytatuowane na każdym twórcy oprogramowania i menedżerze, aby nigdy nie zapomnieli.

Tak, łamie wszystkie współczesne konwencje kodowania. Tak, jest napisany w FORTRAN-77 z opakowaniem w C, dzięki czemu można go wywoływać z Pythona. Tak, są to nieustrukturyzowane GOTO. Tak, jest jeden podprogram o długości trzech tysięcy linii. Tak, nazwy zmiennych mają sens tylko dla Chorwatów. itd itd.

Ale jeśli został przetestowany w gniewie przez dekadę lub dłużej i minął, zostaw to w spokoju! Jeśli wymagana modyfikacja jest niewielka, zachowaj ją tak małą i możliwie jak lokalną. Wszystko inne wiąże się z większym ryzykiem zepsucia czegoś, co nie wymagało naprawy.

Oczywiście czasami okazuje się, że to naprawdę nie do utrzymania kluge i że jedynym sposobem na dostosowanie się do „małej” modyfikacji jest przepisanie od zera. W takim przypadku musisz wrócić do tego, kto prosi o zmianę i powiedzieć mu, ile to będzie kosztowało (zarówno w dolarach, jak i roboczogodzinach za przepisanie, a także w pocie krwi i łzach z powodu nieuniknionych nowych błędów).

Dawno temu wybuchła awaria jednego z napędów dysków Digital. W końcu przypomnieli sobie i zastąpili ich wszystkich w gord, wiedząc, ile kosztują. Najwyraźniej w filmie HDA znajdowała się kropla kleju. Manifestacja techniczna mówi o kleju „Nieparametrycznie określony, ŻADNYCH SUBSTYTUTÓW NIE DOPUSZCZALNYCH”. Licznik fasoli „zapisał” mniej niż cent na dysk, pozyskując inny klej. Wydzielał parę wewnątrz HDA, która zabiła napęd po kilku latach eksploatacji. Nie było zepsute, dopóki go nie naprawił. Bez wątpienia „to była tylko drobna zmiana ...”

nigel222
źródło
2
Masz na myśli Western Digital ? Czy to było przypomnienie ? Czy możesz podać jakieś źródła kopii zapasowej swojej historii?
Lekkość ściga się z Moniką
3
Dość pewny, że ma na myśli Digital Equipment Corp, którego lekki blask może wciąż żyć głęboko w czarnym sercu Hewlett Packard.
John Hascall
1
Tak - Cyfrowy znany również jako DEC.
nigel222
5

Zdecydowanie nie ma sensu obniżanie poziomu jakości starszego kodu. Nie ma też potrzeby natychmiastowego naprawiania ostrzeżeń. Tylko upewnij się, że wszystkie „nowe” zmiany w każdym elemencie projektu są zgodne z wysokim standardem jakości. Tzn. Brak zatwierdzenia nie powinien nigdy zwiększać liczby ostrzeżeń.

Jest to jednolite i martwe proste podejście.

Pozwala to działać starszemu starszemu kodowi tak, jak jest (ponieważ nie są robione niepotrzebne modyfikacje) Zapewnia wysoką jakość nowego kodu. Nie wiąże się to z żadnymi dodatkowymi kosztami.

Basilevs
źródło
Mogę wziąć wyjątek ze słowem zawsze na końcu pierwszego akapitu. Jeśli powiedzmy, że potrzebnych jest kilkadziesiąt linii zmian w środku funkcji kilkuset-liniowej, której styl wywołuje ostrzeżenia, nadal będę próbować podążać za istniejącym stylem, o ile nie jest on wadliwy zakres nieczytelności. Chcę, aby życie było jak najłatwiejsze dla następnego biednego faceta, który przyjdzie i będzie musiał przebrnąć przez to wszystko. Mieszanie stylów tylko w celu spełnienia standardów niektórych narzędzi samo w sobie jest złym stylem. Zamiast tego przestrzegaj oryginalnych standardów / stylu tak bardzo, jak to możliwe.
John Forkosh,
Powiedziałem commit, a nie linię lub funkcję. Podobno posprzątasz wystarczająco dużo bałaganu podczas edycji, aby mieć budżet na problematyczne miejsce.
Basilevs,
3

Kontrola ryzyka….

  • Kod w dużej bazie kodu starszego typu został przetestowany przynajmniej przez rzeczywiste użycie oprogramowania.
  • Jest mało prawdopodobne, że kod w dużej bazie kodu jest objęty automatycznymi testami jednostkowymi.
  • Stąd wszelkie zmiany w przeziębieniu w dużej bazie kodu źródłowego wiążą się z wysokim ryzykiem.

Koszt….

  • Sprawienie, by kod przechodził sprawdzanie kodu podczas pisania kodu, jest tani
  • Zrobienie tego w późniejszym stanie jest znacznie bardziej kosztowne

Zasiłek

  • Masz nadzieję, że przestrzeganie standardów kodowania prowadzi do lepszego projektowania kodu.

  • Ale jest bardzo mało prawdopodobne, aby ktoś spędził wiele tygodni na zmianie kodu tylko po to, aby usunąć ostrzeżenia ze standardowego narzędzia do sprawdzania kodowania, spowoduje ulepszenie projektu kodu.

  • Prosty kod jest bardziej przejrzysty i łatwiejszy do zrozumienia, chyba że złożony kod zostanie podzielony na krótkie metody przez osobę, która go nie rozumie…

Zalecenie….

  • Jeśli sekcja kodu zawiera wiele błędów lub potrzebuje wielu zmian, aby dodać dodatkowe funkcje, poświęć czas w 100% na zrozumienie tego, co robi.
  • Poświęć również czas na dodanie dobrego testu jednostkowego do tej sekcji kodu, ponieważ masz na to sprawdzoną potrzebę.
  • Następnie możesz rozważyć ponowne kodowanie kodu (teraz rozumiesz), więc przeszedł on także sprawdzenie nowego kodu.

Osobiście doświadcz ...

  • Przez pozostałe 20 lat pracy jako programista nigdy nie widziałem przypadku, w którym ślepa zmiana starego w celu usunięcia wszystkich danych wyjściowych z nowego kontrolera standardu kodowania miałaby jakiekolwiek korzyści oprócz zwiększenia dochodów wykonawców, którzy zostali do tego poinstruowani.
  • Podobnie, gdy trzeba wprowadzić stary kod, aby przekazać recenzje kodu (źle zrobiono TickIt / ISO 9001), które wymagały, aby stary kod wyglądał jak nowy standard kodowania.
  • Widziałem wiele przypadków, w których stosowanie standardowych narzędzi sprawdzających kodowanie nowego kodu przyniosło ogromne korzyści dzięki zmniejszeniu bieżących kosztów.
  • Nigdy nie widziałem, aby firma poniosła koszty utrzymania starego kodu używanego w produkcie z dużą liczbą klientów.
  • Widziałem upadek firmy z powodu nieotrzymywania dochodów od klientów, ponieważ zbyt wolno działali na rynku…
Ian
źródło
0

Czy dyskusja na temat obniżenia progów narzędzia? ... lub źle to zrozumiałem. Jest napisane w mylący sposób. Jeśli nie, proszę odrzucić moją odpowiedź.

IMHO dobrym pomysłem byłoby zmniejszenie wrażliwości narzędzia. Czemu? Ponieważ podkreślałby najbardziej włochate fragmenty kodu. Alternatywą jest tworzenie raportów z tysiącami naruszeń, które stają się bezużyteczne ze względu na rozmiar.

... poza tym, po prostu porozmawiaj o tym z zaangażowanymi osobami i dowiedz się też o ich powodach.

Dagnele
źródło
0

Spróbowałbym oddzielić starszy kod od nowego czystego kodu. Na przykład w Eclipse można to zrobić, umieszczając je w różnych projektach, które wykorzystują się nawzajem. „czysty” projekt i „starszy projekt” .

W ten sposób możesz analizować oba projekty za pomocą sonaru o różnych standardach jakości. Standardy powinny różnić się jedynie znaczeniem reguł. Same zasady powinny być takie same. W ten sposób możesz zobaczyć w projekcie „starszym”, co należy „naprawić”, aby spełnić standardy projektu „czystego” .

Ilekroć udało ci się podnieść nieco starszego kodu do wyższych standardów, możesz przenieść go do projektu „czystego”.

W codziennej pracy nie można podnieść każdej klasy, którą dotykasz, do standardów „czystego” projektu z powodu opóźnienia. Ale powinieneś spróbować dotrzeć do tego w kilku krokach, starając się nieco poprawić starszy kod za każdym razem, gdy go dotkniesz.

MrSmith42
źródło