Jak nurkujesz w dużych bazach kodu?

Jakich narzędzi i technik używasz do odkrywania i uczenia się nieznanej bazy kodu?

Mam tu na myśli narzędzi, takich jak grep, ctags, unit-testów, test funkcjonalny, generatory klasy schemat, wykresy rozmowy, metryk kodu takich jak sloccount, i tak dalej. Byłbym zainteresowany twoimi doświadczeniami, pomocnikami, których sam użyłeś lub napisałeś, oraz wielkością bazy kodu, z którą pracowałeś.

Zdaję sobie sprawę, że zapoznanie się z bazą kodu jest procesem, który zachodzi z biegiem czasu, a znajomość może oznaczać wszystko, od „jestem w stanie streścić kod” do „mogę refaktoryzować i zmniejszać go do 30% wielkości”. Ale jak zacząć?

to, co zawsze robiłem, to:

Otwórz wiele kopii mojego edytora (Visual Studio / Eclipse / Cokolwiek), a następnie debuguj i przełamuj linie, przechodząc przez kod. Dowiedz się, jaki jest kod, prześledź stos, aby zobaczyć, gdzie znajdują się kluczowe punkty, i stamtąd.

Mogę patrzeć na metodę po metodzie - ale miło jest, jeśli mogę coś kliknąć, a następnie zobaczyć, gdzie w kodzie jest wykonywany i śledzić. Pozwól mi poczuć, jak programista chciał, aby rzeczy działały.

Jak jesz słonia?

Jeden kęs na raz :)

Poważnie, najpierw próbuję porozmawiać z autorami kodu.

Czy muszę siekać, dopóki nie skończę pracy

W dużej mierze tak (przepraszam).

Podejścia, które możesz rozważyć:

1. Spróbuj dowiedzieć się, co powinien zrobić kod, pod względem biznesowym.
2. Przeczytaj całą istniejącą dokumentację, bez względu na to, jak źle jest.
3. Porozmawiaj z każdym, kto może wiedzieć coś o kodzie.
4. Przejdź przez kod w debuggerze.
5. Wprowadź małe zmiany i zobacz, co się psuje.
6. Wprowadź niewielkie zmiany w kodzie, aby był bardziej przejrzysty.

Niektóre rzeczy, które robię, aby wyjaśnić kod, to:

1. Uruchom prettifier kodu, aby ładnie sformatować kod.
2. Dodaj komentarze, aby wyjaśnić, co według mnie może to zrobić
3. Zmień nazwy zmiennych, aby były bardziej przejrzyste (za pomocą narzędzia refaktoryzacji)
4. Korzystanie z narzędzia, które podkreśla wszystkie zastosowania danego symbolu
5. Ograniczanie bałaganu w kodzie - skomentował kod, bezsensowne komentarze, bezcelowe inicjowanie zmiennych i tak dalej.
6. Zmień kod, aby użyć bieżących konwencji kodu (ponownie za pomocą narzędzi do refaktoryzacji)
7. Zacznij wyodrębniać funkcjonalność w sensowne procedury
8. Zacznij dodawać testy tam, gdzie to możliwe (nie często możliwe)
9. Pozbądź się magicznych liczb
10. Ograniczanie powielania tam, gdzie to możliwe

... i wszelkie inne proste ulepszenia, które możesz wprowadzić.

Stopniowo znaczenie tego wszystkiego powinno stać się jaśniejsze.

Co do miejsca na początek? Zacznij od tego, co wiesz. Sugeruję wejścia i wyjścia. Często możesz dowiedzieć się, co to ma być i do czego służy. Śledź dane w aplikacji i zobacz, dokąd idzie i jak ją zmienić.

Jednym z problemów, które mam z tym wszystkim, jest motywacja - może to być prawdziwy slog. Pomaga mi myśleć o całym biznesie jako zagadce i świętować postęp, który robię, bez względu na to, jak mały.

Twoja sytuacja jest w rzeczywistości powszechna. Każdy, kto musi wejść do nowej pracy, w której istnieje kod do pracy, ma do czynienia z jakimś jego elementem. Jeśli system jest naprawdę paskudnym starszym systemem, jest bardzo podobny do tego, co opisałeś. Oczywiście nigdy nie ma aktualnej dokumentacji.

Po pierwsze, wielu poleciło Efektywną pracę ze Starszym Kodem autorstwa Michaela Feathersa. To naprawdę dobra książka, zawierająca przydatne rozdziały, takie jak: „Nie mogę wprowadzić tej klasy do uprzęży testowej” lub „Moja aplikacja nie ma struktury”, chociaż czasem Pióra mogą zaoferować więcej sympatii niż rozwiązania. W szczególności książka i jej przykłady są w dużej mierze dostosowane do języków nawiasów klamrowych. Jeśli pracujesz z sękatymi procedurami SQL, może to nie być tak przydatne. Myślę, że rozdział „Nie rozumiem tego kodu wystarczająco dobrze, aby go zmienić” mówi o twoim problemie. Feathers wspomina tutaj o oczywistych rzeczach, takich jak robienie notatek i oznaczanie list, ale dobrze też, że możesz usunąć nieużywany kod, jeśli masz kontrolę źródła. Wiele osób pozostawia na miejscu skomentowane sekcje kodu,

Następnie myślę, że twoje sugerowane podejście jest z pewnością dobrym krokiem. Musisz najpierw zrozumieć na wysokim poziomie, jaki jest cel kodu.

Zdecydowanie współpracuj z mentorem lub kimś z zespołu, jeśli musisz uzyskać odpowiedzi na pytania.

Skorzystaj także z okazji, aby wesprzeć kod, jeśli defekty zostaną ujawnione (chociaż czasami nie musisz się do tego zgłaszać ... defekt cię znajdzie!). Użytkownicy mogą wyjaśnić, do czego używają oprogramowania i jak wpływa na nich wada. Często może to być bardzo przydatna wiedza przy próbie zrozumienia znaczenia oprogramowania. Ponadto wejście do kodu z celowym celem ataku może czasem pomóc w skupieniu się na „bestii”.

Chciałbym wykonać następujące czynności, gdy mam naprawdę duży plik źródłowy:

• Skopiuj cały bałagan do schowka
• Wklej do Word / Textmate cokolwiek
• Zmniejsz rozmiar czcionki do minimum.
• Przewiń w dół, patrząc na wzory w kodzie

Zdziwiłbyś się, jak dziwnie znajomy jest ten kod, gdy wrócisz do normalnego edytora.

To wymaga czasu

Nie czuj się zbyt pochopny, próbując zrozumieć starszą bazę kodu, szczególnie jeśli używasz technologii / języków / ram, których nie znasz. To tylko nieunikniona krzywa uczenia się, która zajmuje trochę czasu.

Jednym z podejść jest przechodzenie między kodem a samouczkami na temat powiązanych technologii. Czytasz / oglądasz samouczek, a następnie przeglądasz kod, aby zobaczyć, jak to zrobili Twoi poprzednicy, zauważając podobieństwa i różnice, robiąc notatki i zadając pytania wszystkim istniejącym programistom.

„Dlaczego zrobiłeś tę część w ten sposób”

„Zauważyłem, że większość ludzi robi to w ten sposób i wszyscy zrobili to w inny sposób. Dlaczego tak jest?”

„Co sprawiło, że wszyscy wybraliście technologię X zamiast technologii Y?”

Odpowiedzi na te pytania pomogą Ci zrozumieć historię projektu oraz uzasadnienie decyzji dotyczących projektu i wdrożenia.

W końcu poczujesz się na tyle dobrze, że możesz zacząć dodawać / naprawiać rzeczy. Jeśli wszystko wydaje się mylące lub wydaje się, że dzieje się za dużo „magii”, nie spędziłeś wystarczająco dużo czasu na przeglądaniu, trawieniu i schematowaniu. Tworzenie diagramów (diagramy sekwencji, diagramy przebiegu procesu itp.) To świetny sposób na zrozumienie złożonego procesu, a także pomoże „następnemu facetowi”.

cscope może zrobić wszystko, co ctags może zrobić dla C, a ponadto może również wyświetlić listę wywołań wszystkich bieżących funkcji. Plus jest bardzo szybki. Łatwo skaluje się do milionów LOC. Starannie integruje się z emacsem i vimem.

Licznik kodów C i C ++ - cccc może generować metryki kodu w formacie HTML. Użyłem wc również do uzyskania LOC.

doxygen może generować podświetlony kod i odsyłacz do kodu w HTML. Przydatny w przeglądaniu dużej bazy kodu.

Sposób, który polecam w Drupal i nie jest on tak naprawdę specyficzny dla Drupala: zacznij od narzędzia do śledzenia problemów. Na pewno będą stare, niezamknięte raporty o błędach. Czy potrafisz je odtworzyć? Jeśli tak, zaktualizuj bilet, aby to potwierdzić. Jeśli nie, zamknij go. W ten sposób znajdziesz mnóstwo sposobów korzystania z oprogramowania i możesz zacząć zaglądać do bazy kodu, w której ulega awarii. Lub możesz zacząć przechodzić przez kod i zobaczyć, jak dociera do miejsca, w którym ulega awarii. W ten sposób nie tylko zaczniesz rozumieć bazę kodów, ale także zgromadzisz masę karmy, a twoje pytania zostaną ciepło przyjęte przez społeczność.

Jedną z ważnych rzeczy jest użycie oprzyrządowania do generowania wykresów zależności do odgórnej eksploracji architektury kodu. Najpierw wizualizuj wykres między zestawami lub słoikami .NET, da to wyobrażenie o sposobie organizacji funkcji i warstw, a następnie zagłębisz się w zależności między przestrzeniami nazw (wewnątrz jednego lub kilku względnych zestawów lub słoików .NET), aby uzyskać bardziej szczegółowe pojęcie kodu struktury i wreszcie możesz spojrzeć na zależności klas, aby zrozumieć, w jaki sposób zestaw klas współpracuje przy implementacji funkcji. Istnieje kilka narzędzi do generowania wykresu zależności, na przykład NDepend dla .NET , które wygenerowały poniższy wykres.

Kiedyś miałem dość fantastycznego inżyniera oprogramowania, który powiedział mi, że najdroższą formą analizy i konserwacji kodu było przechodzenie przez kod po linii; oczywiście jesteśmy programistami i to w zasadzie wiąże się z pracą. Myślę, że szczęśliwym medium jest (w tej kolejności): 1. Pobierz zeszyt do tworzenia notatek na temat tego, jak rozumiesz kod, aby działał, i dodawaj go z czasem 2. Zapoznaj się z dokumentacją dotyczącą kodu 3. Porozmawiaj z autorami lub innymi osobami, które wsparły bazę kodu. Poproś ich o „zrzut mózgu” 4. Jeśli doszedłeś do punktu, w którym rozumiesz niektóre relacje klas na poziomie szczegółów, wykonaj debugowanie kodu krok po kroku, aby dokonać syntezy między tym, jak myślisz, że kod działa, a jak faktycznie działa kod.

Najpierw zrozum, co to ma robić - bez tego prawdopodobnie będzie to bełkot. Porozmawiaj z użytkownikami, przeczytaj instrukcję, cokolwiek.

Następnie naciśnij bieg i zacznij chodzić po kodzie, co wydaje się być kluczowymi funkcjami.

Dziel i rządź. Patrzę na każdą funkcjonalność i związany z nią kod, przechodzę przez nią i przechodzę do następnej, powoli budując obraz całości.

Jeśli projekt miał testy jednostkowe, lubię też je przeprowadzać, zawsze są bardzo odkrywcze i pouczające.

1. Uruchom wszystkie testy, jeśli masz, i sprawdź, który kod jest objęty, a który nie.
2. Jeśli kod, który musisz zmienić, nie jest objęty, spróbuj napisać testy, aby go zakryć.
3. Zmień kod. Nie przełamuj testów.

Zobacz, jak Michael Feathers skutecznie współpracuje ze starszym kodem

Oto moja krótka lista:

1. Jeśli to możliwe, poproś kogoś, aby przedstawił widok kodu na wysokim poziomie. Jakie wzorce zostały wzięte pod uwagę, jakie konwencje mogę się spodziewać itp. Może to mieć kilka rund, ponieważ na początku dostałbym jedną historię, że w miarę poznawania kodu mogę mieć nowe pytania zapytać, gdy pracuję nad cebulą wcześniej istniejącego projektu.

2. Uruchom kod i zobacz, jak wygląda system (y). To prawda, że ​​może mieć więcej niż kilka błędów, ale może to być przydatne, aby dowiedzieć się, co robi. Nie chodzi o zmianę kodu, ale po prostu o sprawdzenie, jak to działa. Jak różne elementy pasują do siebie, tworząc całość?

3. Poszukaj testów i innych wskaźników podstawowej dokumentacji, które mogą pomóc w budowaniu wewnętrznego modelu mentalnego kodu. Tutaj prawdopodobnie sugerowałbym co najmniej kilka dni, chyba że jest bardzo mało dokumentacji i testów.

4. Jak dobrze znam języki i struktury użyte w tym projekcie? Ważna jest tutaj różnica między patrzeniem na niektóre rzeczy a mówieniem: „Tak, widziałem to już kilkanaście razy i dość dobrze o tym wiesz” i „Co tu, u licha, próbuje się tutaj? Kto uważał, że to dobry pomysł?” tego rodzaju pytania, które chociaż nie powiedziałbym ich na głos, myślałem o nich, szczególnie jeśli patrzę na starszy kod, który może być dość delikatny, a ludzie, którzy go napisali, są niedostępni lub po prostu nie pamiętają, dlaczego rzeczy zostały wykonane tak, jak były. W przypadku nowych obszarów warto poświęcić trochę czasu na poznanie struktury i wzorców, które mogę znaleźć w tym kodzie.

Na koniec: Poznaj oczekiwania osób prowadzących projekt w zakresie tego, co powinieneś zrobić w każdym momencie, biorąc pod uwagę kilka pomysłów na to, czego można się spodziewać:

• Czy wprowadzasz nowe funkcje?
• Naprawiasz błędy?
• Czy refaktoryzujesz kod? Czy standardy są dla Ciebie nowe, czy są bardzo znane?
• Czy powinieneś po prostu zapoznać się z bazą kodu?

Zawsze próbuję zacząć od punktu wejścia do programu, ponieważ wszystkie programy mają jeden (np. Metoda główna, klasa główna, init itp.). To wskaże mi, co się zaczyna, a czasem, jak rzeczy się łączą.

Potem drążę w dół. Baza danych i DAO są gdzieś skonfigurowane, więc mam pojęcie o tym, jak rzeczy są przechowywane. Być może uruchomiono też jakąś globalną klasę instancji i tam mogę dowiedzieć się, co jest przechowywane. Dzięki dobrym narzędziom do refrakcji mogę dowiedzieć się, kto do czego dzwoni.

Następnie próbuję ustalić, gdzie interfejs jest skonfigurowany i obsługiwany, ponieważ jest to kolejny punkt wejścia informacji. Narzędzia do refrakcji, wyszukiwania i debugowania pomagają w wyszukiwaniu. Następnie mogę dowiedzieć się, gdzie zaczyna się i kończy przetwarzanie informacji, przeglądając wszystkie pliki klas.

Następnie próbuję zapisać przepływ na jakimś papierze, aby początkowo owinąć głowę wokół rzeczy. Przycisk Prześlij przechodzi do ogólnej weryfikacji, która następnie jest przekazywana do DAO lub bazy danych, a następnie zapisywana w bazie danych. Jest to rażące uproszczenie większości aplikacji, ale jest to ogólna idea. Długopis i papier są tutaj niezwykle pomocne, ponieważ możesz szybko zapisać wszystko i nie musisz się martwić formatowaniem w programie, który miał ci pomóc.

Powiedziałbym, że zacznę od dokumentacji itp., Ale z mojego doświadczenia wynika, że ​​głębokość dokumentacji i wiedza lokalna są często odwrotnie proporcjonalne do wieku, wielkości i złożoności systemu.

To powiedziawszy, zwykle staram się zidentyfikować kilka funkcjonalnych wątków. Pod pojęciem funkcjonalnym rozumiem takie rzeczy jak logowanie, ściąganie listy klientów itp. Jeśli wzorce są w ogóle spójne, jeden wątek powinien dać niezły, niekoniecznie kompletny przekrój systemu. Najlepszym sposobem ustalenia, czy wzorce są spójne, jest przeanalizowanie kilku wątków.

Myślę, że jest to oczywiste, ale moim zdaniem lepiej zrozumieć system z perspektywy funkcjonalnej niż technicznej. Zasadniczo nie przejmuję się zbytnio używanymi narzędziami (ORM, logiowanie bibliotek itp.) I skupiam się bardziej na wzorcach (MVP itp.), Które są używane. Z mojego doświadczenia wynika, że ​​narzędzia są na ogół bardziej płynne niż wzory.

Zrobiłem tyle ...

Oto moje obecne podejście do sytuacji, gdy „coś działa” i musisz sprawić, by „działało w inny sposób”.

1. Zdobądź cele, które system powinien rozwiązać (jeśli nie zostały napisane) - napisz. Zapytaj kierownika, innych pracowników, nawet byłych, jeśli są dostępni. Zapytaj klienta lub wyszukaj dowolną dokumentację.
2. Uzyskaj szczegółowe informacje. Jeśli nie istnieje - napisz. Nie warto prosić kogoś o to, jakby nie istniał, to jesteś w sytuacji, gdy inni nie przejmują się tym zbytnio. Więc jedyny sposób na napisanie własnego (później będzie o wiele łatwiej się do niego odwoływać).
3. Uzyskaj projekt. Nie istnieje - napisz to. Spróbuj odwołać się do wszelkich dokumentów i kodu źródłowego w jak największym stopniu.
4. Napisz szczegółowy projekt części, którą musisz zmienić.
5. Zdefiniuj sposób jego testowania. Możesz być pewien, że stary i nowy kod działają w ten sam sposób.
6. spraw, aby system mógł być zbudowany w jednym kroku. I przetestuj ze starym kodem. Przekaż to do SVC, jeśli jeszcze nie jest.
7. Wprowadź zmiany. Nie wcześniej.
8. sprawdź po około miesiącu, czy nic nie jest zepsute.

Jeszcze jedno opcjonalne todo, które może wymagać między każdym krokiem: od kierownika (właściciela projektu), który mówi, że „zmiany te należy wprowadzić już wczoraj”. Po kilku projektach może nawet zacząć z wyprzedzeniem uzyskiwać specyfikacje i dokumenty.

Ale zwykle (szczególnie w przypadku skryptów) po prostu nie jest to możliwe w zakresie biznesowym (koszt będzie zbyt wysoki, a wartość zbyt niska). Jedną z opcji jest nie wprowadzanie żadnych zmian, dopóki nie zostanie osiągnięta masa krytyczna, a system nie wyjdzie z produkcji (np. Nadejdzie nowy system) lub zarząd nie zdecyduje, że wszystko to warto zrobić.

PS: Pamiętam jeden kod, który był używany dla 5 klientów z różnymi ustawieniami. Każda zmiana (nowa funkcja) wymagała myślenia „jakie części są używane” i „jakie klienty konfiguracji”, aby niczego nie hamować i nie kopiować kodu. Wprowadzenie ustawień do projektu CV i napisanie specyfikacji skraca ten czas myślenia prawie do 0.

Wydrukuj kod źródłowy i zacznij go czytać. Jeśli jest szczególnie duży, wydrukuj tylko wybrane jego części, aby lepiej go zrozumieć i zrobić tyle notatek / komentarzy, ile potrzebujesz.

Śledź program od początku jego wykonywania. Jeśli jesteś przypisany do określonej części podstawy kodu, prześledź wykonanie w tej części i dowiedz się, jakie struktury danych są używane.

Jeśli używasz języka obiektowego, spróbuj stworzyć ogólny diagram klas. Zapewni to dobry przegląd na wysokim poziomie.

Niestety, w końcu będziesz musiał przeczytać jak najwięcej kodu. Jeśli masz szczęście, poprzedni programiści napisali jak najwięcej dokumentacji, aby pomóc ci zrozumieć, co się dzieje.

Pierwszą rzeczą, którą musisz zrobić, ucząc się nowej bazy kodu, jest dowiedz się, co ma robić, jak jest używany i jak go używać. Następnie zacznij przeglądać dokumentację architektoniczną, aby dowiedzieć się, jak jest ułożony kod, a także spójrz w jaki sposób baza danych w tym momencie. Jednocześnie uczysz się architektury, że jest to dobry moment, aby przejrzeć wszelkie przepływy procesów lub wykorzystać dokumenty przypadków. następnie zacznij zanurzać się i czytać kod po zrozumieniu dużego obrazu, ale tylko kod związany z pracą, którą wykonujesz na tym kodzie, nie próbuj po prostu czytać całego kodu. Ważniejsze jest, aby wiedzieć, gdzie kod ma wykonać X, niż dokładnie jak X jest zrobiony, kod jest zawsze tam, aby powiedzieć ci, jak go znaleźć.

Uważam, że sama próba wskoczenia i odczytania kodu bez celu wykraczającego poza naukę kodu jest generalnie bezproduktywna, próba samodzielnego wprowadzenia niewielkich zmian lub przejrzenie kodu zmian innej osoby to o wiele bardziej produktywne wykorzystanie twojego czasu.

Jeśli podstawa kodu jest duża, skoncentruj się na częściach, nad którymi obecnie pracujesz. W przeciwnym razie poczujesz się przytłoczony i być może twoja głowa wybuchnie. Myślę, że przegląd ogólny jest pomocny (jeśli jest dostępny), ale są szanse, że będziesz spędzał dużo czasu w debuggerze na śledzenie przebiegu programu. Dobrze jest uzyskać przegląd aplikacji i zobaczyć, jak jest używana, abyś mógł zrozumieć, w jaki sposób / do czego / dlaczego kod jest używany.

Zazwyczaj uruchamiam na kodzie jakieś narzędzie do zarządzania złożonością kodu, aby powiedzieć mi, gdzie są obszary problemowe. Obszary o wysokim wyniku są prawdopodobnie bardzo trudne do aktualizacji. Na przykład wpadłem na funkcję, która uzyskała 450 w skali cyklicznej. Rzeczywiście, setki IF. Bardzo trudno to utrzymać lub zmienić. Więc bądź przygotowany na najgorsze.

Nie obawiaj się też zadawać pytań istniejącym programistom, zwłaszcza jeśli pracowali w systemie. Zachowaj swoje wewnętrzne myśli dla siebie i skup się na rozwiązywaniu problemów. Unikaj komentarzy, które mogą spowodować, że inni programiści będą się denerwować. W końcu może to być ich dziecko i nikt nie lubi, gdy mówi się, że ich dziecko jest brzydkie.

Rób małe kroki, nawet najmniejsza zmiana kodu może mieć duży wpływ.

Uważam, że pomocne jest wymyślanie przepływów kodu programu, więc jeśli wprowadzam zmiany, mogę wyszukiwać zależności, aby zobaczyć, które metody / funkcje wywołują co. Załóżmy, że zmieniam metodę C.

Jeśli tylko 1 metoda / funkcja wywołuje C, to jest to całkiem bezpieczna zmiana. Gdyby setki metod / funkcji wywoływały C, miałoby to większy wpływ.

Mamy nadzieję, że twoja baza kodu jest dobrze zaprojektowana, napisana i utrzymana. Jeśli tak, zrozumienie go zajmie trochę czasu, ale ostatecznie fala się odwróci.

Jeśli jest to duża kula błota, możesz nigdy nie zrozumieć (lub chcieć zrozumieć) jej wewnętrznego działania.

Niektóre rzeczy, które robię ...

1) Użyj narzędzia analizy źródła, takiego jak Monitor źródła, aby określić różne rozmiary modułów, wskaźniki złożoności itp., Aby poznać projekt i pomóc w identyfikacji obszarów, które nie są trywialne.

2) Drążenie kodu od góry do dołu w Eclipse (dobrze mieć edytor, który może przeglądać referencje itp.), Dopóki nie dowiem się, co się dzieje i gdzie w bazie kodu.

3) Czasami rysuję diagramy w Visio, aby uzyskać lepszy obraz architektury. Może to być pomocne również dla innych osób biorących udział w projekcie.

To się często zdarza. Dopóki nie zacząłem pracować na platformie open source, nie sądzę, żebym kiedykolwiek zaczął pracę, która nie zaczęła się od przyznania, że ​​kod miał pewne „dziwactwa”.

Możesz uzyskać długą drogę z debuggerem krokowym i dużą wytrwałością. Niestety często potrzeba czasu i doświadczenia, aby nauczyć się konkretnej dużej kuli błota, a nawet po latach wciąż może istnieć podsystem, który się pojawia, o którym nikt nie ma żadnej wiedzy.

Zachęcam do napisania testów jednostkowych, zanim cokolwiek zmienisz w kulę błota. I zmieniaj tylko tyle kodu w tym czasie, aby testy przebiegły pomyślnie. W trakcie refaktoryzacji dodaj testy jednostkowe, aby mieć pewność, że funkcja biznesowa nie została uszkodzona przez refaktoryzację.

Czy programowanie w parach jest opcją? Posiadanie innej osoby do odrzucenia pomysłów to świetny pomysł, aby poradzić sobie z taką ilością paskudnych.

Oto procedura, której używamy do eliminacji duplikatów.

• wybierz standardowy prefiks komentarza dla duplikatów (używamy [dupe]zaraz po znaczniku komentarza;
• napisz specyfikacje ze swoimi zespołami na temat nazw, które będą używane w procedurze duplikowania;
• pierwsza runda: wszyscy biorą jakieś pliki i dodają [dupe][procedure_arbitrary_name]przed zduplikowaną procedurą;
• druga runda: każdy bierze procedurę lub podzbiór procedury i przypisuje wartość wskazującą kolejność podobieństwa różnych implementacji tego samego celu (ciąg będzie wtedy:) [dupe][procedure_arbitrary_name][n];
• trzecia runda: odpowiedzialny za każdą procedurę przepisuje ją w odpowiedniej klasie;
• czwarta runda: grepszczęśliwa!

Myślę, że jedną z najważniejszych rzeczy jest skorzystanie z prostej funkcji, wybranie najprostszej z nich i wdrożenie jej. Jeśli istnieje zachowana lista życzeń, skorzystaj z niej lub porozmawiaj z kimś znającym bazę kodu i poproś ją o zasugerowanie funkcji. Zwykle spodziewałbym się, że będzie to zmiana z 5 ~ 20 LOC. Ważną kwestią nie jest to, że dodajesz bardzo wymyślną funkcję, ale że pracujesz (a raczej zmagasz :)) z bazą kodu i przechodzisz przez cały przepływ pracy. Powinieneś

1. Przeczytaj kod, aby zrozumieć modyfikowany komponent
2. Zmień kod i zrozum, jak wpływa to na otaczający system.
3. Przetestuj zmianę, a tym samym określ, w jaki sposób komponenty współdziałają ze sobą
4. Napisz przypadek testowy i miejmy nadzieję, że złamiesz jeden lub dwa przypadki testowe, abyś mógł je naprawić i zrozumieć niezmienniki systemu.
5. Zbuduj coś lub zobacz, jak CI go zbuduje, a następnie wyślij

Lista jest długa, ale chodzi o to, że mini projekt taki jak ten prowadzi przez wszystkie elementy na liście kontrolnej do zapoznania się z systemem, a także powoduje dokonanie produktywnej zmiany.

Mała rzecz, którą chciałem dodać:

Jednym z narzędzi, które ostatnio zacząłem używać do tego rodzaju problemu, który ogromnie pomógł, jest mapowanie myśli. Zamiast próbować wcisnąć wszystkie szczegóły, jak coś jest implementowane w mojej głowie, zbuduję mapę myśli opisującą, jak działa system, przez który przechodzę. Naprawdę pomaga mi to głębiej zrozumieć, co się dzieje i co muszę jeszcze ustalić. Pomaga mi również śledzić, co muszę zmienić w bardzo dokładnej skali.

Polecam korzystanie z darmowego samolotu wśród wielu możliwości mapowania myśli.

Nie będzie dokumentacji, skąpej dokumentacji lub będzie nieaktualna. Znajdź całą dokumentację, która istnieje. Jeśli znajduje się w repozytorium zespołu, nie rób kopii. Jeśli nie, umieść go tam i poproś kierownika o pozwolenie na zorganizowanie go, być może z pewnym nadzorem.

Pobierz wszystko do repozytorium dla zespołu i dodaj glosariusz. Wszystkie zasady mają żargon; udokumentuj to w glosariuszu. Twórz sekcje dotyczące narzędzi, produktów, specyficznych dla klienta itp.

Utwórz / zaktualizuj dokument tworzenia środowiska oprogramowania. Tutaj znajdziesz wszystkie narzędzia, dziwactwa, opcje instalacji itp.

Następnie prześlij dokument „Pierwsze kroki z nazwą produktu” lub podobny. Niech będzie to tylko przepływ umysłu i samoorganizacja w czasie. Następnie przejrzyj nieaktualne dokumenty i przywróć je do aktualności. Pozostali programiści docenią to, będziesz przyczyniał się w unikalny sposób podczas nauki kodu. Zwłaszcza dokumentuj wszystkie takie rzeczy, które Cię zaskakują, są źle nazwane lub są sprzeczne z intuicją.

Gdy krzywa pochylenia dobiegnie końca, nie martw się o aktualizację dokumentacji. Niech następny nowy facet to zrobi. Kiedy przyjedzie, wskaż mu swoją pracę. Kiedy nieustannie cię denerwuje za odpowiedzi, nie odpowiadaj mu. Dodaj pytanie do swojej dokumentacji, a następnie podaj mu adres URL. Wędka.

Jednym z efektów ubocznych jest to, że stworzysz narzędzie, z którego będziesz mógł korzystać za kilka miesięcy, kiedy zapomnisz.

I chociaż nie jest to dokumentacja, pokrewnym zagadnieniem są wszystkie dziwaczne, intensywnie wykonywane ręcznie procedury, które wykonują członkowie twojego zespołu. Automatyzuj je za pomocą partii, skryptów SQL i tym podobnych, a także udostępniaj je. W końcu wiedza proceduralna jest prawdopodobnie tak duża jak wiedza deklaratywna pod względem uzyskania produktywności w nowym środowisku. Cokolwiek to jest, nie rób tego; raczej skrypt i uruchom skrypt. Wędka uderza ponownie.

Napisałem dość długi post na ten temat. Oto fragment

Długo myślałem o tym problemie. Postanowiłem napisać własne rozwiązanie jako ogólny proces. Kroki, które udokumentowałem, są następujące:

1. Utwórz arkusz słownictwa
2. Poznaj aplikację
3. Przeglądaj dostępną dokumentację
4. Rób założenia
5. Zlokalizuj biblioteki stron trzecich
6. Analizuj kod

Ten proces jest napisany w kontekście dużej aplikacji komputerowej, ale ogólne techniki nadal mają zastosowanie do aplikacji internetowych i mniejszych modułów.

zaczerpnięte z: Proces uczenia się nowej bazy kodów

Jest kilka małych wskazówek, którymi mogę się podzielić.

W przypadku istniejącego produktu zaczynam je intensywnie testować. Jeśli wybierzesz / otrzymasz zadanie, skupię się bardziej na konkretnej funkcji.

• Następnym krokiem byłoby znalezienie kodu, w którym mogę się włamać i zacząć odkrywać. Po drodze znajdę zależne moduły, biblioteki, frameworki itp.

• Następnym krokiem byłoby stworzenie prostego diagramu klas z jego obowiązkami (jak karty CRC)

• Rozpocznij wprowadzanie drobnych zmian lub podejmuj drobne błędy, aby je naprawić i zatwierdzić. Możemy więc nauczyć się przebiegu pracy w projekcie; nie tylko kod. Często duże produkty będą miały pewien rodzaj prowadzenia ksiąg rachunkowych w celu uzyskania zezwoleń i audytów (np. Projekty opieki zdrowotnej)

• Porozmawiaj z ludźmi, którzy już pracują nad projektem. Wyraź swoje pomysły, przemyślenia, aw zamian zdobądź ich doświadczenie i poglądy na temat pracy z tym projektem przez długi czas. Jest to bardzo ważne, ponieważ pomaga również dobrze dogadać się z zespołem.

Minęło sporo czasu, odkąd sam musiałem zagłębić się w dużą bazę kodu. Ale w ciągu ostatnich kilku lat wiele razy próbowałem zaangażować nowych programistów w zespoły, w których mieliśmy istniejącą, dość dużą bazę kodu.

Metodą, którą z powodzeniem zastosowaliśmy i powiedziałbym, że jest najskuteczniejszym sposobem bez pytania IMHO, jest programowanie parami.

W ciągu ostatnich 12 miesięcy mieliśmy 4 nowych członków zespołu i za każdym razem nowy członek sparował się z innym członkiem dobrze znającym bazę kodu. Na początku starszy członek zespołu miał klawiaturę. Po około 30 minutach przekazaliśmy klawiaturę nowemu członkowi, który pracował pod kierunkiem starszego członka zespołu.

Ten proces okazał się całkiem udany.