Co możesz zrobić ze starszą bazą kodową, która będzie miała największy wpływ na poprawę jakości?

Pracuję ze starszą aplikacją 1M LOC napisaną i zmodyfikowaną przez około 50 programistów.

* Remove unused code

* Remove duplicated code

Właściwie, kiedy coś naprawiam, zawsze szukam duplikatu. Jeśli znalazłem jakieś, to wstawiam funkcję generyczną lub komentuję cały kod do powielania (czasem wysiłek na umieszczenie funkcji generycznej nie jest tego wart). Główną ideą jest to, że nienawidzę robić tego samego. akcja więcej niż raz. Innym powodem jest to, że zawsze jest ktoś (może być ja), który zapomina sprawdzić inne zdarzenie...

* Add unit tests to improve test coverage where coverage is low

* Create consistent formatting across files

IMO różnica w formatowaniu jest częścią dziedzictwa. Daje podpowiedź o tym, kto lub kiedy Kod został napisany. To może dać ci jakąś wskazówkę o tym, jak zachowywać się w tej części kodu. Wykonywanie zadania sformatowania nie jest zabawne i nie daje żadnej wartości dla klienta.

* Update 3rd party software

Zrób to tylko wtedy, gdy jest nowa naprawdę fajna funkcja lub wersja, którą masz, nie jest obsługiwana przez nowy system operacyjny.

* Reduce warnings generated by static analysis tools

Dodaj testy jednostkowe, aby poprawić zasięg testu. Posiadanie dobrego pokrycia testowego pozwoli Ci bez obaw na refaktoring i poprawę funkcjonalności.

Jest na ten temat dobra książka napisana przez autora CPPUnit, Działa skutecznie z kodem dziedziczonym .

Dodawanie testów do kodu starszego jest z pewnością trudniejsze niż tworzenie ich od zera. Najbardziej użytecznym pojęciem, które usunąłem z książki, jest pojęcie "szwów", które Feathers definiuje jako

"a miejsce, gdzie można zmieniać zachowanie w programie bez edycji w tym miejscu."

Czasami warto refaktoryzować, aby stworzyć szwy, które ułatwią przyszłe testy (lub będą w pierwszej kolejności możliwe).) Blog google testing ma kilka ciekawych postów na ten temat, głównie obracających się wokół procesu Dependency Injection.

Powiedziałbym ,że 'Usuń zduplikowany kod' oznacza, że musisz wyciągnąć kod i streszczenie go, aby mógł być używany w wielu miejscach - to teoretycznie ułatwia naprawianie błędów, ponieważ musisz naprawić tylko jeden kawałek kodu, w przeciwieństwie do wielu fragmentów kodu, aby naprawić w nim błąd.

Mogę odnieść się do tego pytania, ponieważ obecnie mam na kolanach jeden z' tych ' kodów starej szkoły. Jego dziedzictwo nie jest tak naprawdę, ale na pewno nie podąża za trendem lat.

Powiem ci, co chciałbym w nim naprawić, ponieważ wkurzają mnie codziennie:

• dokumentowanie zmiennych wejściowych i wyjściowych
• Refaktor nazwy zmiennych tak, że rzeczywiście oznacza coś innego i jakiś Węgierski prefiks notacji, a następnie akronim trzech liter z niektórych niejasne to znaczy. CammelCase to najlepszy sposób.
• boję się na śmierć zmiany dowolnego kodu, ponieważ wpłynie to na setki klientów korzystających z oprogramowania i ktoś zauważy nawet najbardziej niejasny efekt uboczny. Wszelkie powtarzalne testy regresji byłyby błogosławieństwem, ponieważ teraz jest zero.

Reszta to naprawdę orzeszki ziemne. Są to główne problemy ze starszą bazą kodową, naprawdę pochłaniają mnóstwo czasu.

Powiedziałbym, że w dużej mierze zależy to od tego, co chcesz zrobić z kodem starszym...

Jeśli pozostanie w trybie konserwacji i będzie działać bez zarzutu, najlepiej nie robić nic. "Jeśli nie jest zepsuty, nie naprawiaj go."

Jeśli nie działa poprawnie, usunięcie nieużywanego kodu i refaktoryzacja zduplikowanego kodu znacznie ułatwi debugowanie. Jednak te zmiany wprowadziłbym tylko na błędnym kodzie.

Jeśli planujesz wersję 2.0, Dodaj testy jednostkowe i Wyczyść kod, który przedstawisz

Dobra dokumentacja. Jako ktoś, kto musi utrzymywać i rozszerzać kod legacy, jest to problem numer jeden. Zmiana kodu, którego nie rozumiesz, jest trudna, jeśli nie wręcz niebezpieczna. Nawet jeśli masz szczęście, aby otrzymać udokumentowany Kod, jak jesteś pewien, że dokumentacja jest prawidłowa? Że obejmuje całą ukrytą wiedzę oryginalnego autora? Że to przemawia do wszystkich "sztuczek" i przypadków krawędziowych?

Dobra dokumentacja jest tym, co pozwala innym niż oryginalny autor, aby zrozumieć, naprawić i rozszerzyć nawet zły kod. Przyjmę zhakowany, ale dobrze udokumentowany kod, który mogę zrozumieć nad doskonałym, ale nieodkrytym kodem każdego dnia tygodnia.

Największą rzeczą, jaką zrobiłem dla kodu starszego, z którym muszę pracować, jest zbudowanie wokół niego prawdziwego API. Jest to interfejs API COBOL w stylu z Lat 70-tych, wokół którego zbudowałem model obiektowy. NET, dzięki czemu cały niebezpieczny kod jest w jednym miejscu, wszystkie tłumaczenia między natywnymi typami danych API i typami danych.NET są w jednym miejscu, podstawowe metody zwracają i akceptują zestawy danych i tak dalej.

To było niezmiernie trudne do zrobienia dobrze, a nadal są w nim pewne wady, które wiem o tym. To też nie jest zbyt wydajne, przy tym całym zamieszaniu, które się dzieje. Ale z drugiej strony, mogę zbudować DataGridView, że round-trips danych do 15-letniej aplikacji, która utrzymuje swoje dane w Btrieve (!) za jakieś pół godziny i działa. Kiedy klienci przychodzą do mnie z projektami, moje szacunki są w dniach i tygodniach, a nie miesiącach i latach.

Jako paralelę do tego, co powiedział Josh Segall, powiedziałbym, że skomentuj to do cholery. Pracowałem nad kilkoma bardzo dużymi starszymi systemami, które wpadły mi w ręce i odkryłem, że największym problemem było śledzenie tego, co już dowiedziałem się o konkretnej sekcji kodu. Kiedy zacząłem umieszczać notatki, w tym notatki "do zrobienia", przestałem ponownie zastanawiać się, co już odkryłem. Wtedy mógłbym skupić się na tym, jak te segmenty kodu przepływają i współdziałają.

Powiedziałbym, że po prostu zostaw to w spokoju przez większość czasu. Jeśli nie jest zepsuty, nie naprawiaj go. Jeśli jest uszkodzony, to śmiało i naprawić i poprawić część kodu, który jest uszkodzony i jego natychmiast otaczający kod. Możesz użyć bólu błędu lub bolesnej brakującej funkcji, aby uzasadnić wysiłek i koszt poprawy tej części.

Nie polecam jakiejkolwiek hurtowni przeróbki, refakturowania, formatowania, ani wprowadzania testów jednostkowych, które nie są kierowane przez rzeczywistą działalność lub potrzeby użytkowników końcowych.

Jeśli masz okazję coś naprawić, zrób to dobrze (szansa na zrobienie tego dobrze za pierwszym razem mogła już minąć, ale ponieważ dotykasz tej części ponownie, równie dobrze możesz to zrobić w odpowiednim czasie) i obejmuje to wszystkie elementy, o których wspomniałeś.

Podsumowując, nie ma ani jednej, ani tylko kilku rzeczy, które powinieneś zrobić. Powinieneś zrobić to wszystko, ale w małych porcjach i w sposób oportunistyczny.

Późno dla strony, ale warto zrobić, gdy funkcja / metoda jest używana lub często się do niej odwołuje:

• zmienne lokalne często są źle nazwane w kodzie starszym (często ze względu na ich rozszerzenie zakresu, gdy metoda jest modyfikowana i nie jest aktualizowana, aby to odzwierciedlić). Zmiana ich nazw zgodnie z ich rzeczywistym przeznaczeniem może pomóc w wyjaśnieniu starszego kodu.
• nawet samo ułożenie metody nieco inaczej może zdziałać cuda - na przykład umieszczenie wszystkich klauzul z if w jednej linii.
• mogą być już przestarzałe / mylące komentarze do kodu. Usuń je, jeśli nie są potrzebne, lub zmień je, jeśli absolutnie musisz. (oczywiście, nie jestem za usunięciem przydatnych komentarzy, tylko te, które są przeszkodą.)

Mogą one nie mieć tak dużego wpływu na nagłówki, których szukasz, ale są niskie ryzyko, szczególnie jeśli kod nie może być testowany jednostkowo.