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

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?

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.

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ć.

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.

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 ...”

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.

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…

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.

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.