Najlepsze praktyki przekazywania legalnego kodu

Za kilka miesięcy kolega przejdzie do nowego projektu, a ja odziedziczę jeden z jego projektów. Aby się przygotować, zamówiłem już Efektywne działanie Michaela Feathersa przy użyciu starszego kodu .

Ale te książki, jak również większość pytań na temat dotychczasowego kodu, dotyczą dotychczasowego dziedziczenia kodu. Ale w tym przypadku mam dostęp do oryginalnego programisty i mamy trochę czasu na uporządkowane przekazanie.

Niektóre tło fragmentu kodu, który będę dziedziczył:

• Działa: nie są znane żadne błędy, ale wraz ze wzrostem wymagań dotyczących wydajności konieczne będą pewne optymalizacje w niezbyt odległej przyszłości.
• Nieudokumentowane: Istnieje prawie zerowa dokumentacja na poziomie metody i klasy. To, co powinien robić kod na wyższym poziomie, jest jednak zrozumiałe, ponieważ od lat piszę przeciwko jego interfejsowi API (jako czarnej skrzynce).
• Tylko testy integracyjne wyższego poziomu: istnieją tylko testy integracyjne testujące poprawną interakcję z innymi komponentami za pośrednictwem interfejsu API (znowu czarna skrzynka).
• Bardzo niski poziom, zoptymalizowany pod kątem szybkości: Ponieważ ten kod jest kluczowy dla całego systemu aplikacji, wiele z niego zostało zoptymalizowanych kilka razy w ciągu lat i jest bardzo niski poziom (jedna część ma własnego menedżera pamięci dla niektórych struktur /dokumentacja).
• Współbieżne i wolne od blokowania: Chociaż jestem bardzo zaznajomiony z programowaniem współbieżnym i bez blokowania i faktycznie przyczyniłem się do powstania kilku elementów w tym kodzie, dodaje to kolejną warstwę złożoności.
• Duża baza kodu: ten konkretny projekt zawiera ponad dziesięć tysięcy wierszy kodu, więc nie ma mowy, abym mógł wszystko wyjaśnić.
• Napisane w Delphi: Po prostu to tutaj przedstawię, chociaż nie uważam, aby język był istotny dla tego pytania, ponieważ uważam, że ten rodzaj problemu jest niezależny od języka.

Zastanawiałem się, jak najlepiej wykorzystać czas do jego odejścia. Oto kilka pomysłów:

• Zdobądź wszystko, aby zbudować na moim komputerze: mimo że wszystko powinno być sprawdzone pod kontrolą kodu źródłowego, który nie zapomniał raz na jakiś czas pobrać pliku, więc prawdopodobnie powinna to być pierwsza kolejność.
• Więcej testów: chociaż chciałbym więcej testów jednostkowych na poziomie klasy, aby kiedy wprowadzę zmiany, wszelkie wprowadzone przeze mnie błędy mogły zostać wykryte wcześnie, ale kod w obecnej postaci nie jest testowalny (ogromne klasy, długie metody, zbyt wiele wzajemne zależności).
• Co należy udokumentować: Myślę, że na początek najlepiej skoncentrować się na tych obszarach kodu, które w innym przypadku byłyby trudne do zrozumienia, np. Z powodu ich niskiego poziomu / wysoce zoptymalizowanego charakteru. Obawiam się, że jest tam kilka rzeczy, które mogą wyglądać brzydko i wymagają refaktoryzacji / przepisywania, ale w rzeczywistości są to optymalizacje, które zostały tam z dobrego powodu, że mógłbym tęsknić (por. Joel Spolsky, Things You Should Nigdy nie rób, część I )
• Jak dokumentować: Myślę, że najlepsze byłyby niektóre klasowe diagramy architektury i sekwencyjne diagramy funkcji krytycznych, którym towarzyszy proza.
• Kogo dokumentować: Zastanawiałem się, co byłoby lepsze, aby napisał dokumentację lub wytłumaczył mi ją, abym mógł napisać dokumentację. Obawiam się, że rzeczy, które są dla niego oczywiste, ale nie dla mnie, nie zostałyby odpowiednio uwzględnione.
• Refaktoryzacja za pomocą programowania w parach: Może to nie być możliwe ze względu na ograniczenia czasowe, ale może mógłbym zrefaktoryzować część jego kodu, aby był łatwiejszy w utrzymaniu, gdy jeszcze był w pobliżu, aby podać informacje na temat tego, dlaczego rzeczy są takie, jakie są.

Skomentuj i dodaj do tego. Ponieważ nie ma wystarczająco dużo czasu, aby to wszystko zrobić, jestem szczególnie zainteresowany tym, jak postąpisz priorytetowo.

Aktualizacja: Po zakończeniu projektu przekazania rozszerzyłem tę listę o własne doświadczenia w poniższej odpowiedzi .

Gdy masz dostęp do programisty, kodujesz: -

• Które moduły były najtrudniejsze do zakodowania / wdrożenia. Jakie były problemy i jak zostały przezwyciężone.

• Które moduły wygenerowały najwięcej błędów.

• Które moduły spowodowały najtrudniejsze do rozwiązania błędy.

• Z jakich fragmentów kodu jest najbardziej dumny.

• Które fragmenty kodu naprawdę chciałby refaktoryzować, ale nie miał czasu.

Te pytania dadzą ci wgląd w to, co sprawi ci najwięcej problemów, a co ważniejsze, zajmą się procesami myślowymi i perspektywami oryginalnego programisty.

Ponieważ projekt przekazania został już zakończony, myślę, że poświęciłbym trochę czasu i napisałem własną odpowiedź zawierającą te rzeczy, które najlepiej mi pasowały.

• Uzyskaj wszystko pod kontrolą wersji: po upewnieniu się, że wszystko, co muszę zbudować, było pod kontrolą wersji, przeszukałem również dysk twardy starego programisty, szukając dodatkowych skryptów lub narzędzi, które byłyby pomocne przy wdrażaniu i / lub testowaniu aplikacji, ale nie były zameldowałem się.
• Z góry na dół: chciałbym zacząć od spojrzenia na najważniejsze klasy i oprowadzenia po starym deweloperze głównych obszarów. Potem sam wnikałem głębiej w resztę, zaznaczając markerem rzeczy, które nie miały dla mnie sensu //TODO.
• Sam pisz całą dokumentację: chociaż stary programista przejrzał moje pismo, aby upewnić się, że wszystko jest w porządku, nalegałem, aby napisać wszystko sam. W ten sposób byłbym pewien, że pisanie ma sens zarówno dla mnie, jak i dla starego programisty.
• Komentarze wszędzie: dodałem podsumowania dokumentacji XML do każdej klasy i każdej metody. W ten sposób upewniłem się, że przynajmniej spojrzałem na każdy fragment kodu i mam dość zrozumienia, aby podsumować, co zrobił w zdaniu. Ułatwiło także zrozumienie metod przy użyciu metod / klas podsumowujących, ponieważ IntelliSense zbiera te informacje. Mogłem również łatwo zidentyfikować obszary kodu, na które wciąż musiałem patrzeć.
• Dokument blisko źródła: Aby ułatwić połączenie między kodem źródłowym a dokumentacją, większość swojej dokumentacji umieściłem bezpośrednio w kodzie źródłowym. Do dokumentacji wysokiego poziomu opisującej interakcje między różnymi podsystemami użyłem wiki, ponieważ umieszczenie tych informacji w jednym miejscu kodu nie działało. Cała dokumentacja powinna być elektroniczna i umożliwiać wyszukiwanie pełnotekstowe.
• Diagramy: Dla podstawowego przeglądu wykorzystałem diagramy klas dla różnych ziarnistości dla różnych podsystemów. Dla współbieżnych części bardzo pomocne były diagramy obiektów i interakcji; zobacz także moje inne pytanie na ten temat .
• Refaktoryzacja jako para: chociaż przeprowadziłem pewne refaktoryzacje ze starym programistą, aby poznać kod i uczynić rzeczy łatwiejszymi w utrzymaniu, był to czasochłonny i ryzykowny proces, z powodu braku dobrych narzędzi do refaktoryzacji i wielu nieprzyjemnych zależności między różnymi częściami. Skuteczna współpraca Michaela Feathersa z Legacy Code jest naprawdę dobrą pomocą, mimo że refaktoryzacja bez odpowiedniego wsparcia narzędzi jest wciąż bolesna. Podczas refaktoryzacji pozwoliłem mu kontrolować mysz i klawiaturę, ponieważ było dla niego więcej zabawy (patrz także mój ostatni punkt) i mogłem zapisać to, czego się uczyłem.
• Oddzielne zameldowania dla komentarzy i zmian: po tym, jak przypadkowo wprowadziłem błąd, pisząc komentarz nad override, ostrożnie wprowadzałem komentarze i zmiany w osobnych zameldowaniach. Użyłem małego narzędzia do usunięcia wszystkich komentarzy z kodu źródłowego przed sprawdzeniem czegoś, więc różnica w odpisie tylko z komentarzem pokazałaby 0 różnic. Wszystkie zmiany (np. Usunięcie nieużywanych pól) zostały dokładnie sprawdzone przez starego programistę, aby upewnić się, że nie usuwam rzeczy, które były nadal potrzebne.
• Omówienie krytycznych fragmentów linia po linii: w przypadku najbardziej zoptymalizowanych / skomplikowanych fragmentów przechodziłbym kod po linii ze starym programistą, a czasem nawet z trzecim kolegą. W ten sposób dogłębnie zrozumiałem kod, a ponieważ więcej osób sprawdzało kod, faktycznie zidentyfikowaliśmy kilka błędów, a także kilka rzeczy, które można jeszcze zoptymalizować.
• Bądź szybki i utrzymuj motywację starego programisty: zauważyłem, że stary programista był coraz mniej zainteresowany, ponieważ jego ostatni dzień był coraz bliżej (co nie jest zaskoczeniem). Dlatego upewnię się, że najważniejsze części zostały przekazane w pierwszej kolejności, a resztę pozostawię samemu, jeśli zajdzie taka potrzeba. Próbowałem też zostawić mu więcej zabawy (np. Sterowanie klawiaturą podczas programowania w parach) i robić nudne rzeczy, takie jak pisanie dokumentacji.
• Zidentyfikuj prośby o funkcje: uznałem za pomocne zapytanie starego programisty o listę funkcji, o które ludzie prosili, ale jeszcze nie zostali dodani. Było kilka rzeczy, które dla mnie wyglądały na proste do dodania, ale tam, gdzie był dobry powód, nie zostały dodane, ponieważ zepsułyby inne rzeczy po wdrożeniu, tak jak myślałem na początku.

Uważam, że w podobnej sytuacji warto rozważyć następujące kwestie:

• Upewnij się, że możesz wykonać i przetestować wdrożenie: Wykonaj własne wdrożenie produktu od zera - i sprawdź, czy jest to identyczne z wykonanym przez osobę, która odchodzi. Pozwoli to upewnić się, że wszystkie skrypty i instrukcje są dla Ciebie jasne, i złapie wszelkie przypadkowe niedopatrzenia, takie jak składniki, które nie zostały zarejestrowane w systemie kontroli wersji. (Nie mówię, że to by się stało, po prostu, że jeśli ma się stało, to będzie dużo łatwiejsze do czynienia teraz, zanim dana osoba odchodzi)

  (Może to nie być dla Ciebie istotne, np. Jeśli wykonujesz już ciągłą integrację lub ciągłe wdrażanie, ale warto o tym wspomnieć, na wszelki wypadek ...)

• Pisanie kolejnych testów: To naprawdę dobry sposób na sprawdzenie swojego zrozumienia systemu. Umożliwi (lub zmusi) przyjrzenie się bliżej obszarom kodu i albo potwierdzi, że kod jest wolny od błędów, jak podejrzewasz, lub ujawni obszary, w których myślałeś, że zrozumiałeś zamiar, ale tak naprawdę przed wyjazdem musisz poprosić kolegę o wyjaśnienia

• Pisanie dokumentacji parami: Jest to skuteczny sposób na pisanie zestawień. I sugeruję, że masz swoją koleżankę do opisania funkcji lub obszar, a następnie możesz zapisać go w górę, w dokumentacji, własnymi słowami. Odkryliśmy, że było to znacznie łatwiejsze, gdy zrobiły to dwie osoby razem.

Osobiście pisałbym, że pisanie testów ma wyższy priorytet niż pisanie dokumentacji, ponieważ testy prawdopodobnie zapewnią więcej - lub mocniejsze - zrozumienia.

Jeśli chodzi o refaktoryzację za pomocą programowania par , jedyne, co powiedziałbym, to to, że istnieje niebezpieczeństwo, że może to stać się bez dna, szczególnie biorąc pod uwagę, że powiedziałeś, że masz tylko testy na wysokim poziomie. Może się okazać, że zużywa o wiele więcej dostępnego czasu, niż zamierzałeś.

+1 za odpowiedzi, które już masz w swoim pytaniu!

Zwiedzanie z przewodnikiem
10k linii kodu to dużo, ale myślę, że nadal nie jest niemożliwe, aby ten drugi facet dał ci „wycieczkę z przewodnikiem”. Siadasz razem przed kodem, a on zabiera cię w podróż z góry na dół, pracując nad „warstwami”. Musisz to zrobić w krótkich seriach - wszystko za jednym razem zabije was oboje.

Powiększanie, pomniejszanie
Zaletą robienia tego jest to, że kiedy ci to wyjaśnia, prawie na pewno będzie miał kilka chwil „och, tak, są też” momenty, których nie mógłby, gdyby tylko próbował to udokumentować na własną rękę. A twoje pytania pomogą skupić się na rzeczach oczywistych dla niego, ale nie dla nikogo innego. Ten rodzaj interakcji przybliżania / oddalania jest możliwy tylko jeden na jednego, próba napisania lub przeczytania czegoś takiego jest niewygodna.

Dokumentacja
Myślę, że oboje powinniście niezależnie dokumentować rzeczy - powinien zacząć od dołu (na wypadek, gdybyś nie miał czasu się tam dostać) i powinieneś zacząć od góry, na podstawie tego, co rozumiesz jego zwiedzanie z przewodnikiem i jakby to było dla kogoś innego [w poprzedniej pracy odziedziczyłem mnóstwo „starszego” kodu i dopiero co miałem czas go udokumentować przed opuszczeniem siebie :)].

Gdzie jest co
Celem większości tego jest, abyś mógł poczuć, gdzie dzieją się rzeczy. Aby dany błąd lub modyfikacja była możliwa, możesz bardzo szybko znaleźć miejsce w kodzie, na którym musisz się skoncentrować. Możesz sprawdzić się, biorąc listę starych błędów i sprawdzając, czy możesz dokładnie przewidzieć, gdzie był problem.

Pompuj go do sucha
Nie ma znaczenia, czy on cię nienawidzi (uśmiech), twoim zadaniem jest wyciągnięcie jak największej ilości informacji z mózgu tego faceta, jak to możliwe, w dostępnym czasie. Upewnij się, że masz zarządzanie po swojej stronie i że priorytetem jest transfer wiedzy zamiast „naprawiania ostatnich błędów przed wyjściem” (chyba że je naprawiasz ...).

Proponuję następujące (oprócz tego, co już zostało zidentyfikowane): - Po pierwsze, poproś swojego kierownika, aby dał ci jak najwięcej czasu na pracę z tym facetem i staraj się z nim usiąść, ilekroć ma za zadanie dokonać zmiany. Nie musisz wiedzieć wszystkiego, co robi, ale staraj się złapać jak najwięcej. Najważniejsze, aby się z nim przyjaźnić.

Traktuj przekazanie jako projekt i opracuj plan oraz zaangażuj kierownictwo.

0 - Upewnij się, że wiesz, jak korzystać z systemu.

1 - Zrób jasny spis składników rozwiązania, źródła każdego z nich i ich położenia (w różnych repozytoriach)

2 - Zdobądź i, jeśli to możliwe, zarządzaj hasłami do różnych serwerów, zaczynając od teraz. Upewnij się, że masz wszystkie informacje o koncie administratora

3 - Uzyskaj licencje dla każdego komponentu zewnętrznego, chyba że jest on poza twoim zakresem (np. Specjalne biblioteki DLL, baza danych itp.)

4 - Uzyskaj pisemny raport o aktualnym stanie systemu od dewelopera i twoich klientów (jeśli są lokalni dla twojej firmy)

5 - Pobierz dokumentację dotyczącą reguł biznesowych, wzorów obliczeniowych itp. Możesz to zrobić z nim. Poproś go o e-maile, informacje o spotkaniach, dokumenty wymagań użytkownika, dokumenty projektowe i tym podobne, które zostaną ci przekazane.

6 - Uzyskaj listę zaplanowanych zdarzeń (comiesięczne serie zadań, cotygodniowe serie zadań), na które oprogramowanie musi odpowiedzieć

7 - Poznaj procedury tworzenia kopii zapasowych / przywracania

8 - Zapoznaj się z ramami zastosowanymi przy tworzeniu aplikacji

9 - Poznaj wymagane / oczekiwane / planowane modyfikacje oraz status wszelkich oczekujących żądań użytkowników. Rozpocznij próbę ustalenia, jak to zrobić samodzielnie.

10 - Upewnij się, że środowiska testowe i programistyczne są bardzo podobne.

11 - Spróbuj zidentyfikować główne zależności (na innych systemach lub między komponentami), których nie można łatwo wykryć.

12 - Zidentyfikuj i udokumentuj wymagane wersje każdego oprogramowania i dane kontaktowe dostawcy (w razie potrzeby)

13 - Zidentyfikuj wszelkie specjalne narzędzia, których używał, których nie masz, na wypadek, gdyby Ci to pomogło.

14 - Uzyskaj wysoki przepływ systemu. i zacznij budować bibliotekę dokumentacji

15 - Dowiedz się, jak zarządzać bezpieczeństwem użytkowników w aplikacji

16 - Pobierz dziennik błędów i spróbuj zrozumieć działania oraz ich wpływ na starsze dane (jeśli dotyczy)

17 - Poznaj procesy, które trwają zbyt długo i na co musisz uważać (np. Nietypowe rozmiary plików, ftp zduplikowanych plików itp.) W stosownych przypadkach.

18 - Sprawdź zegar serwera produkcyjnego

19 - Zidentyfikuj konfiguracje i porównaj każdą konfigurację środowiska z produkcją, aby dowiedzieć się, jakie parametry są różne i dlaczego

20 - Uzyskaj dane kontaktowe tego faceta

21 - Jeśli system jest wewnętrzny, zaplanuj spotkanie z użytkownikami systemu (musisz wiedzieć, kim oni są i jaką rolę odgrywają) i zapoznaj się z nimi. Posłuchaj, co mają do powiedzenia na temat systemu i ich bieżących problemów, jeśli takie istnieją. Upewnij się, że jesteś uwzględniony w wiadomościach e-mail tak wcześnie, jak to możliwe (po zatwierdzeniu przez kierownika)

22 - Oceń swoje zrozumienie na tydzień przed wyjazdem i zgłoś wszelkie problemy, które postrzegasz jako ryzyko

Ponieważ wspomniałeś, że nie masz bazy danych, ta lista jest krótsza.

Powodzenia.

Najpierw rozważę najbardziej skomplikowane, zoptymalizowane pod kątem wydajności części. Poproszę go, aby najpierw udokumentował te części i wytłumaczył je pojedynczo, a następnie spróbuję napisać testy na tych częściach (w tym przed i po testach wydajnościowych, abyś mógł zobaczyć, czy nowa optymalizacja poprawi lub pogorszy sytuację ) i niech druga osoba sprawdzi testy. W ten sposób dokumentuje i wyjaśnia, wykorzystujesz wyjaśnienie do pisania testów (podczas gdy dokumentuje inny obszar), a jego recenzja pomoże ci zrozumieć, co powinieneś testować. W ten sposób otrzymujesz również dodatkową średnią testową dla niektórych najbardziej krytycznych części aplikacji i dokumentacji specjalistycznych optymalizacji wydajności.

Jeśli minę czas, zanim je omówię, przejdę do podobnego procesu z częściami aplikacji, które najczęściej wymagały zmian przez lata, ale których nie ma w pierwszej grupie rzeczy udokumentowanych.

Następnie udokumentuj wszystko, co zostało.

Myślę, że najlepszym sposobem na wywołanie dużego kodu jest podejście odgórne. Spróbuj najpierw zrozumieć duży obraz, a następnie stopniowo wbijaj się głębiej w komponenty jeden po drugim.

Teraz na każdym poziomie kopania poproś go, aby nadał priorytet tym częściom, które wymagają największej uwagi. Niech wyjaśni ci jak najwięcej, ale zawsze udokumentuj to sam.

Najlepsze w samodzielnym dokumentowaniu tego jest to, że kiedy wrócisz później, nie będziesz miał problemu z przypomnieniem sobie tego samego stanu poznawczego, w którym byłeś, kiedy ci to wyjaśnił. Znacznie łatwiej można zrozumieć, co pan napisał ktoś inny niż to, co zrobił. Z mojego doświadczenia wynika, że ​​dwie osoby dokumentujące ten sam fragment kodu nie tworzą podobnie wyglądających fragmentów tekstu.

Wydaje mi się, że rozwiązuje to również problemy związane z dokumentowaniem i dokumentowaniem. Kiedy wyjaśni ci wszystko, możesz sam zdecydować, co chcesz udokumentować po powrocie do kodu - i udokumentuj tylko te części.

Chodzi o to, aby najpierw całkowicie zrozumieć kod (w jego obecności), a następnie napisać / zrobić wszystko, co pozwoli ci go później rozszyfrować (pod jego nieobecność).

Rozumiejąc kod, rozumiem duży obraz - i to, w jaki sposób każdy komponent odnosi się do tego dużego obrazu. Uważam, że szczególnie pomocne jest śledzenie, w jaki sposób każdy kawałek stanowi całość. Nie próbuj niczego rozumieć w izolacji - nigdy nie trać z oczu jego kontekstu.

Wreszcie, kiedy już to zrobisz, proaktywnie przejmij kontrolę. Zdecyduj sam, dla których elementów potrzebujesz pokrycia testem jednostkowym. jakie części muszą być (lub mogą być) zoptymalizowane, w jaki sposób można refaktoryzować jakiś komponent itp. Ufaj, że jeśli znasz system, możesz podjąć wszystkie decyzje po jego odejściu.

Współczuję Ci.

Kilka sugestii:

1. Nagrywaj każdą rozmowę z odchodzącym programistą!
2. Zapytaj o motywację stojącą za „dużymi” problemami. Dobrze, że rozumiesz API, ale szukaj wewnętrznych decyzji - dlaczego kod został podzielony na partycje? jakie są obowiązki.
3. Staraj się naprawdę przestudiować kod. Kiedy przejmujesz obowiązki związane z utrzymaniem i wsparciem, czasami pojawia się presja, by „studiować kod podczas robienia postępów”. Oprzyj się, jeśli możesz, i naprawdę przestudiuj kod.
4. Poszukaj scenariuszy. Znasz interfejs API - zobacz, jak zachowuje się kod. Przykładem, który przychodzi mi na myśl, jest moduł faksu. Jako użytkownik interfejsu API musiałeś przygotować obraz strony i wysłać kod, aby przekazać stronę. Poproś odchodzącego programistę, aby wraz z tobą prześledził kod, aby zobaczyć, jak przebiega ten scenariusz. Następnie oczywiście przejdź do scenariusza „odbieranie strony”.
5. 80/20 - postaraj się najpierw przedstawić bardziej popularne scenariusze.
6. Rozważ ponowne napisanie. Jeśli kod jest stary, a interfejsy są dobrze zdefiniowane, być może technologia zmieniła się wystarczająco, aby to uzasadnić.
7. Nienawidzę tego mówić, ale rozważam szukanie nowej pracy.

Jeśli chcesz porządnej dokumentacji w rozsądny sposób bezboleśnie kupić kopię Pascal Analyzer (PAL) , użyłem tego w projektach Delphi i było świetnie - mogą teraz podzielić funkcjonalność dokumentacji na produkt, którego nie znam (przeglądarka Pascal) więc być może będziesz musiał kupić oba (<300 USD), ale PAL był doskonałym narzędziem do zrozumienia, gdzie używane były zmienne, gdzie wywoływano funkcje z itp. i wychwytywania wszelkiego rodzaju potencjalnych problemów z kodem.

Użyj PAL, aby zorientować się, jak ustrukturyzowany jest kod, a także prawdopodobnie listę około 1000 sugerowanych ulepszeń, jeśli moje doświadczenia byłyby kontynuowane. Przepracowanie listy poprawi jakość kodu, znacznie go uprości i ułatwi życie w przyszłości. Sam Delphi obsługuje refaktoryzację w ostatnich wersjach (ostatnie 5 lat). Musiałeś zawrzeć wszystko w pliku dpr, aby naprawdę działało poprawnie, kiedy to robiłem, więc pamiętaj o tym.

Jeśli potrzebujesz testów jednostkowych, pobierz DUnit i zacznij tworzyć testy przy użyciu oryginalnego kodera - to prawdopodobnie konstruktywny sposób na wykorzystanie przynajmniej części ich czasu.

Chociaż nie wspomniałeś o bazie danych zaplecza, ale zakładając, że jest taka, powinieneś

1. Uzyskaj udokumentowany model danych, zwłaszcza kolumny i PK-FK
2. Skonfiguruj śledzenie sql i zapisz wszystkie zapytania, które są uruchamiane podczas korzystania z aplikacji. Kolejność wykonywania zapytań da ci dobry pogląd na temat przepływu aplikacji, a także pomoże w debugowaniu

Znajduję się w tej samej sytuacji, w której nasz architekt przeprowadził się do Australii i pozostawił po sobie wiele spuścizny, jaką był w firmie z ostatnich 8 lat. On odziedziczył dziedzictwo odziedziczone po poprzednim Architekcie, który był wykonawcą.

Ty i inni już wspomnieliście o dobrych punktach, ale oto problemy, z którymi mieliśmy do czynienia po jego odejściu, być może możecie lepiej się przygotować ...

1) (Osoba techniczna) Dane kontaktowe klientów, z którymi ma do czynienia.

2) Jego konto, na podstawie którego zakupił licencje na oprogramowanie, klucze, które muszą być odnawiane co roku, oraz procesy / koszty ich odnowienia.

3) Dokument konfiguracji bibliotek / komponentów oprogramowania stron trzecich i produktów, które integrują się z twoimi produktami. Przez 4 dni walczyliśmy o przywrócenie maszyny, która została utracona z powodu wyczyszczenia przestrzeni przez IT i przekazano im nieprawidłowe instrukcje.

4) Dokumenty / kroki służy do zdeponowania kodu źródłowego w oprogramowaniu firm depozytowych, np. Escrow.

5) Wciąż istnieje długa lista, ale może nie dotyczyć ciebie. Żadna dokumentacja nie może zastąpić prawdziwej osoby, więc trzymaj jej dane pod ręką, trzymaj się miłych warunków i powodzenia :)

Nie wiem też, czy to pierwszy raz dla ciebie. Dla mnie pracowałem z 5/6 pracodawcami i zawsze odziedziczyłem kod ze złą dokumentacją lub wcale. Więc wraz z całą dokumentacją pozostań pozytywny :)