Na marginesie: poszukaj nowej pracy. Ten nie byłby lepszy.
Cele sprawdzanego kodu to:
Aby wysłać funkcję, która powinna działać zgodnie z wymaganiami.
Ograniczenie wzrostu zadłużenia technicznego.
Pierwszy cel jest weryfikowany przez sprawdzenie, czy testy jednostkowe, integracyjne, systemowe i funkcjonalne są tutaj, czy są odpowiednie i czy obejmują wszystkie sytuacje, które muszą zostać przetestowane. Musisz także sprawdzić przekonania autora na temat języka programowania, co może prowadzić do subtelnych błędów lub kodu udającego, że robi coś innego niż to, co faktycznie robi.
Drugi cel to ten, na którym koncentruje się twoje pytanie. Z jednej strony nie oczekuje się, że nowy kod zwiększy zadłużenie techniczne. Z drugiej strony zakresem przeglądu jest sam kod, ale w kontekście całej bazy kodu. Odtąd jako recenzent możesz oczekiwać dwóch podejść od oryginalnego autora:
Kod zewnętrzny nie jest moją winą. Po prostu implementuję tę funkcję i nie dbam o całą bazę kodu.
W tej perspektywie kod skopiuje wady bazy kodu, a zatem nieuchronnie zwiększy techniczny dług: więcej złego kodu jest zawsze gorsze.
Chociaż jest to prawidłowe podejście krótkoterminowe, w perspektywie długoterminowej spowodowałoby to zwiększenie opóźnień i niską wydajność, a ostatecznie doprowadziłoby do tak kosztownego i ryzykownego procesu rozwoju, że produkt przestałby ewoluować.
Napisanie nowego kodu jest okazją do refaktoryzacji starszego kodu.
W tej perspektywie wpływ wad starego kodu na nowy może być ograniczony. Co więcej, dług techniczny można zmniejszyć lub przynajmniej nie zwiększyć proporcjonalnie do wzrostu kodu.
Chociaż jest to prawidłowe podejście długoterminowe, wiąże się z nim ryzyko krótkoterminowe. Głównym z nich jest, że krótkotrwałe, to czasami wymaga więcej czasu, aby wysyłać funkcji konkretnego. Innym ważnym aspektem jest to, że jeśli starszy kod nie zostanie przetestowany, jego refaktoryzacja stwarza ogromne ryzyko wprowadzenia regresji.
W zależności od perspektywy, którą chcesz zachęcić, możesz być skłonny doradzić recenzentom, aby dokonali większego refaktoryzacji. We wszystkich przypadkach nie oczekuj bezbłędnego, czystego fragmentu kodu z ładną architekturą i designem w kiepskiej bazie kodu. To, czego nie powinieneś zachęcać, to zachowanie, w którym dobrze poinformowany programista, który musi pracować nad kiepską bazą kodu, stara się dobrze wykonać swoją rolę . Zamiast upraszczać, tylko komplikuje je przedtem. Teraz, zamiast jednolitego, złego kodu, masz część ze wzorami projektowymi, inną część z czystym, przejrzystym kodem, inną część, która z biegiem czasu została gruntownie zreformowana, i nie ma żadnej jedności.
Wyobraź sobie na przykład, że odkrywasz starszą bazę kodów witryny średniej wielkości. Jesteś zaskoczony brakiem jakiejkolwiek zwykłej struktury i faktem, że rejestrowanie, gdy jest zrobione, polega na ręcznym dodawaniu elementów do pliku tekstowego, zamiast korzystania z frameworka rejestrowania. Ty decydujesz, aby nowa funkcja korzystała z MVC i środowiska rejestrowania.
Twój kolega wdraża kolejną funkcję i jest bardzo zaskoczony brakiem ORM, w którym można uzyskać idealny rozmiar. Więc zaczyna używać ORM.
Ani ty, ani twój kolega nie jesteście w stanie przejść przez setki tysięcy wierszy kodu, aby wszędzie korzystać z MVC, frameworka rejestrowania lub ORM. W rzeczywistości wymagałoby to miesięcy pracy: wyobraź sobie wprowadzenie MVC; ile to zajmie? A co z ORM w sytuacjach, w których zapytania SQL były chaotycznie generowane przez konkatenację (z okazjonalnymi miejscami dla SQL Injection) wewnątrz kodu, którego nikt nie rozumiał?
Myślisz, że wykonałeś świetną robotę, ale teraz nowy programista, który dołącza do projektu, musi stawić czoła znacznie większej złożoności niż wcześniej:
Stary sposób traktowania próśb,
Sposób MVC,
Stary mechanizm rejestrowania,
Ramy rejestrowania,
Bezpośredni dostęp do bazy danych dzięki zapytaniom SQL budowanym w locie,
ORM.
Przy jednym projekcie, nad którym pracowałem, były używane cztery (!) Struktury rejestrowania obok siebie (plus rejestrowanie ręczne). Powodem jest to, że za każdym razem, gdy ktoś chciał się zalogować, nie było wspólnego podejścia do tego, więc zamiast uczyć się nowego frameworka (który we wszystkich przypadkach był używany tylko w 5% bazy kodu), wystarczy dodać kolejny już wie. Wyobraź sobie bałagan.
Lepszym rozwiązaniem byłoby przefakturowanie bazy kodu krok po kroku. Biorąc jeszcze raz przykład rejestrowania, refaktoryzacja składałaby się z następujących małych kroków:
Znajdź wszystkie miejsca, w których odbywa się rejestrowanie starszego typu (tj. Gdy plik dziennika jest uzyskiwany bezpośrednio) i upewnij się, że wszystkie wywołują te same metody.
Przenieś ten kod do dedykowanej biblioteki, jeśli dotyczy. Nie chcę logować pamięci masowej w mojej klasie koszyka.
W razie potrzeby zmień interfejs metod rejestrowania. Na przykład możemy dodać poziom wskazujący, czy wiadomość jest nieformalna, czy jest ostrzeżeniem lub błędem.
Użyj nowo zreformowanych metod w nowej funkcji.
Przeprowadź migrację do środowiska rejestrowania: jedynym kodem, którego dotyczy problem, jest kod z dedykowanej biblioteki.