Jest wiele informacji o narzędziach i technikach ulepszania starszych baz kodów, ale nie spotkałem żadnych udanych studiów przypadku w świecie rzeczywistym. Większość porad jest na poziomie mikro i chociaż jest pomocna, nie przekonuje wielu ludzi z powodu braku dowodów, może pomóc na poziomie makro.
Poszukuję w szczególności stopniowych ulepszeń, które okazały się sukcesem w prawdziwym świecie podczas aktualizacji dużej bazy kodu starszego typu, aby spełniały dzisiejsze standardy jakości, a nie całkowite przepisanie.
Przed:
- Duży: większy niż 1 MLOC
- Starsza wersja: brak automatycznych testów
- Niska jakość: wysoka złożoność, wysokie sprzężenie, wysokie wady, których można uniknąć
Po
- Zautomatyzowane testy
- Łatwiejsze aktualizacje / konserwacja
- Wysoka jakość: zmniejszona złożoność, oddzielony kod, kilka unikniętych wad
Jakiego rodzaju kroki przyrostowe zostały udowodnione w prawdziwym świecie w celu udanej aktualizacji dużej bazy kodów starszego typu, tak aby spełniała standardy jakościowe, bez konieczności całkowitego przepisywania?
Jeśli to możliwe, dołącz do swojej odpowiedzi przykładową firmę lub studium przypadku dużego projektu, który przeszedł przez „udany” proces poprawy jakości.
źródło
Odpowiedzi:
Książki takie jak http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 powinny być wystarczającym świadectwem tego, jak duże, starsze bazy kodu niskiej jakości są powszechne w branży.
Domyślam się, dlaczego nie słyszałeś ani nie widziałeś, a co ważniejsze, prawdopodobnie nigdy o nich nie usłyszysz, dopóki sam nie popracujesz nad jednym z nich. Nikt nie wydaje się być zdolny z różnych powodów, by wyjść na czysto i powiedzieć, że ich kod podstawa była wszystkim powyższym, bez stawiania czoła niebanalnym konsekwencjom.
To może wyjaśnić brak badań, o których mówisz. Jeśli przeczytasz wystarczającą liczbę książek, na przykład Deep C Secrets Petera van der Lindena, przeczytasz około miliona błędów, w których brakuje części dotyczącej projektu.
UWAGA: Chciałem zamienić ten komentarz, ale to było za długie. Rozumiem, że to nie odpowiada w pełni na pytanie.
EDYCJA: C ++ 11 & Długoterminowa żywotność GCC jest kwestionowana - jeśli programiści dokonają refaktoryzacji GCC i uczynią ją bardziej narzędziową jako LLVM / clang, może to stanowić dobry przykład. W dyskusji zauważono, że w niektórych miejscach dokumentacja jest niska, co powoduje wzrost barier wejścia dla nowych programistów.
źródło
3 lutego 2013 r. Michael Meeks, jeden z programistów LibreOffice, wygłasza w ciągu kilku dni przemówienie zatytułowane „LibreOffice: czyszczenie i przefaktoryzowanie gigantycznej bazy kodu lub dlaczego ponowne napisanie byłoby jeszcze gorsze . ” Brzmi jak dokładnie to, o co prosisz: dyskusja o tym, co zrobili, by „źle zrozumieć, gigantyczną bazę kodu szeroko komentowaną w języku niemieckim, bez testów jednostkowych, infrastruktury splątanej kompilacji i dwudziestu pięciu lata niespłaconego długu technicznego ”i zmodernizuj go.
Prezentację można przesyłać strumieniowo online , a (jak sądzę) nagrania będą dostępne w przyszłości.
źródło
W mojej karierze trzy razy przeszedłem dość znaczną refaktoryzację. Kod ma tendencję do gnicia, więc jeśli baza kodu jest wystarczająco długa, dużego refaktora praktycznie nie da się uniknąć. Wszystkie moje przykłady były oparte na kodach prywatnych, co może wyjaśniać, dlaczego trudno jest znaleźć przykłady publiczne.
Pierwszy raz była to aplikacja, która - wierzcie lub nie - miała fundamentalną architekturę, dzięki której działała tylko z drukarkami igłowymi. Kiedy moja firma nie mogła już znaleźć dostawcy, który dostarczyłby taśmy, przydzielili mnie do pracy z drukarką laserową.
Drugi raz to migracja kilkuset automatycznych skryptów testowych z C do Javy, częściowo dlatego, że potrzebowaliśmy lepszych możliwości międzyplatformowych, a częściowo dlatego, że trudno było zatrudnić nowych programistów C.
Za trzecim razem jestem jeszcze w środku, co polega na modularyzacji ogromnej monolitycznej aplikacji, aby umożliwić testowanie jednostkowe poprzez redukcję sprzężenia i do celów międzyplatformowych.
Porównuję wysiłek wspinaczki na górę. Masz przed sobą ten ogromny cel, ale nie rozwiązujesz go na poziomie makro. Bierzesz go po jednym uchwycie, zawsze mając bliskie położenie awaryjne, nigdy nie odłączając poprzedniego zabezpieczenia, dopóki nie znajdzie się następne. Zaczynasz po prostu od drobnych przyrostowych ulepszeń, a po chwili odwracasz się i nagle pojawia się ten piękny widok.
Powiedzmy, że masz na przykład 60 000 plików silnie sprzężonego kodu. Chcesz rozpocząć testowanie jednostki, ale zależności uniemożliwiają to. Jak to naprawić? Odłączasz jeden plik. Dodajesz testy automatyczne. Zanim przejdziesz dalej, wrócisz na stabilny teren. Powtórz 59 999 razy.
Jeśli to brzmi prosto, to dlatego, że jest proste. To nie jest łatwe, ale jest proste. Na początku trudno zauważyć jakiekolwiek postępy. Jesteśmy za dwa lata, co wydawało się niemożliwym refaktorem, i prawdopodobnie mamy przed sobą lata, zanim skończymy, ale patrząc wstecz, nagle uświadamiamy sobie, o ile lepszy jest już kod, i byliśmy w stanie nadal dostarczać nową funkcjonalność tymczasem naszym klientom.
Pozostałe dwa razy działały w ten sam sposób. Znajdujesz najmniejszy bezpieczny krok, jaki możesz podjąć, i podejmujesz go, zawsze utrzymując aplikację w stanie roboczym. Martwisz się tylko dużym obrazem, aby upewnić się, że zmierzasz we właściwym kierunku. Wszystkie twoje działania są małe, stabilne i przyrostowe.
źródło
Na podstawie własnego doświadczenia w pracy na wielomilionowej bazie kodu linii znalazłem kilka strategii, które wydają się działać.
Spójrz na wszystkie błędy (nawet te zamknięte) i spróbuj podzielić je na kategorie. W szczególności, aby spróbować podzielić je według składnika, do którego należą. Jeśli należą do więcej niż jednego elementu, zauważ, że tak. Po wykonaniu tego spojrzenia, który segment jest największy i użyj go, aby określić, od czego zacząć. Dodatkowo możesz spojrzeć na historię zmian plików, aby określić, które zmiany najbardziej się zmieniają i użyć ich jako przewodnika od czego zacząć. Zasadniczo to, co próbujesz zrobić, to znaleźć to, co jest najbardziej uszkodzone, naprawić i powtórzyć. Dodatkowo odkryłem, że próba naprawy wszystkiego w tym samym czasie nigdy nie działa, tylko powoduje więcej problemów.
Jeśli okaże się, że istnieje wiele rzeczy, które należą do wielu komponentów, co wskazuje na problemy z „systemem” i może wskazywać na zbyt ściśle powiązany kod lub interfejs API, który wymaga odświeżenia.
Innym obszarem, w którym spędziłem dużo czasu, jest testowanie istniejącej bazy kodu. Istnieje tutaj wiele strategii i wszystkie mają swoje zalety, ale nikt nie jest kompletnym rozwiązaniem problemu.
źródło