Czy mamy obowiązek ulepszania starego kodu?

Przeglądałem stary kod, który napisałem. Działa, ale nie jest to świetny kod. Teraz wiem więcej niż wtedy, więc mogłem to poprawić. To nie jest bieżący projekt, ale jest to aktualny, działający kod produkcyjny. Czy mamy obowiązek cofnąć się i poprawić kod, który napisaliśmy w przeszłości, czy też jest to właściwe podejście „jeśli nie jest zepsute, nie naprawiaj go”? Moja firma kilka lat temu sponsorowała klasę recenzji kodu, a jednym z głównych problemów było to, że czasami jest po prostu wystarczająco dobra; pójść dalej.

Czy w którymś momencie powinieneś po prostu nazwać go wystarczająco dobrym i przejść dalej, czy też powinieneś próbować pchać projekty w celu ulepszenia starego kodu, gdy uważasz, że może być lepszy?

O ile nie wprowadzisz zmian w tym „starym kodzie”, aby naprawić błędy lub dodać funkcje, nie zawracałbym sobie głowy ulepszaniem go tylko ze względu na to. Jeśli chcesz go ostatecznie ulepszyć, upewnij się, że masz testy jednostkowe, które przetestują kod, zanim zaczniesz go refaktoryzować.

Możesz użyć „starego kodu”, aby poznać lepsze praktyki. Jeśli to zrobisz, będzie to nauka w niepełnym wymiarze godzin i nie powinieneś oczekiwać, że ten kod zastąpi to, co jest obecnie wydane lub wdrożone przez klientów / klientów.

Refaktoryzuj obszary kodu, które musisz modyfikować najczęściej . Ponieważ często odwiedzasz te obszary, refaktoryzacja poprawi twoje zrozumienie kodu i czytelność, kiedy będziesz musiał je odwiedzić ponownie, podczas gdy nie ma sensu refaktoryzować kodu, którego nikt nigdy nie będzie oglądać.

Co więcej, jeśli refaktoryzujesz obszary kodu tylko wtedy, gdy musisz je zmodyfikować, daje to uzasadnioną wymówkę, jeśli refaktoryzacja powoduje regresję . Oczywiście, spróbuj pokryć swoje refaktoryzacje testami jednostkowymi, ale nie zawsze jest to możliwe, szczególnie w przypadku starszego kodu i powinieneś spodziewać się, że duże refaktoryzacje będą co jakiś czas tworzyć regresje.

Jeśli chcesz dodać funkcje, a Twój projekt spowalnia Cię lub powoduje duplikację, refaktoryzuj . Kiedy projektuję kod, prawie nigdy nie przewiduję dokładnie, jakie zmiany będą potrzebne w przyszłości. Jednak po dodaniu nowych funkcji zwykle kończę refaktoryzację udostępnionego kodu. Do tego czasu dodałem trzeci cykl funkcji / refaktoryzacji, moje refaktoryzacja już się zwraca, a mój wspólny kod jest dość stabilny.

TLDR: refaktoryzator w razie potrzeby, nie ma obowiązku.

Wszystko, co robisz, kosztuje. Masz ograniczony czas na programowanie. Należy przeciwstawić się wszystkim, co robisz w programowaniu: „Jaka jest z tego korzyść?” i „Jaka jest korzyść z robienia czegoś innego?”

Jeśli nie weźmiesz pod uwagę kosztu alternatywnego (jaki jest koszt zrobienia czegoś innego?), Jakość jest bezpłatna. Lepiej poprawić swój kod. Dowiesz się czegoś. Będzie lepiej. Sprzeda więcej.

Prawdziwe pytanie brzmi: co możesz zrobić z czasem? A potem dokonujesz kompromisów.

Czy będzie sprzedawać więcej oprogramowania?

Czy spowoduje to mniejszy ból głowy do wsparcia?

Czego się nauczysz

Czy stanie się bardziej estetyczny?

Czy poprawi to twoją reputację?

Zadaj te pytania (i wszelkie inne istotne dla Ciebie) dla tej i innych czynności w kolejce, a to pomoże odpowiedzieć, czy warto to naprawić. Te kompromisy powodują, że ekonomia jest ważna dla programistów. Joel powiedział to zanim to zrobiłem, a stary mentor powiedział mi to jeszcze przed Joelem.

Lub jeśli chcesz uzyskać prostszą odpowiedź, po prostu przestań oglądać telewizję, dopóki nie naprawisz kodu. :-)

Myślę, że powinieneś zacząć od zadania sobie pytania, które wydaje się być pominięte. W jaki sposób kod jest zły? I przez to naprawdę zadajesz sobie następujące pytania:

• Czy kod nie robi tego, co powinien?
• Czy kod powoduje problemy podczas konserwacji oprogramowania?
• Czy kod jest całkowicie samodzielny?
• Czy planujesz aktualizację lub wymianę kodu w dowolnym momencie w dającej się przewidzieć przyszłości?
• Czy istnieje uzasadnienie biznesowe, które możesz zrobić, aby zaktualizować kod, który Cię dotyczy?

Jeśli nauczyłem się przez te lata jednej rzeczy, nie możesz sobie pozwolić na drugie zgadnięcie po fakcie. Za każdym razem, gdy rozwiązujesz problem w kodzie, uczysz się czegoś i prawdopodobnie zobaczysz, jak twoje rozwiązanie - lub coś podobnego - mogło być lepszym rozwiązaniem problemu, który rozwiązałeś inaczej lata temu. To dobra rzecz, ponieważ pokazuje, że nauczyłeś się na podstawie swoich doświadczeń. Prawdziwe pytanie brzmi jednak, czy kod, który napisałeś wcześniej, prawdopodobnie stanie się problemem, który z czasem staje się trudniejszy do rozwiązania.

Naprawdę mówimy tutaj o tym, czy kod, który Ci przeszkadza, jest łatwy czy trudny w utrzymaniu, a także o tym, jak kosztowna będzie ta konserwacja w miarę upływu czasu. Zasadniczo jest to pytanie dotyczące Długu Technicznego i tego, czy warto spłacić ten dług przy użyciu niewielkiej konserwacji chirurgicznej, czy też dług jest na tyle mały, że można pozwolić mu na chwilę się przesunąć.

Są to pytania, które naprawdę musisz porównać z obecnym i przyszłym obciążeniem pracą, i powinny zostać szczegółowo omówione z kierownictwem i zespołem, aby lepiej zrozumieć, gdzie zainwestować zasoby i czy twój stary kod jest wart czas, który możesz poświęcić na to - jeśli w ogóle. Jeśli potrafisz zrobić dobry argument biznesowy do wprowadzenia zmiany, zrób to z całą pewnością, ale jeśli masz ochotę majstrować przy kodzie, ponieważ czujesz się zawstydzony sposobem, w jaki to napisałeś, sugeruję, że nie ma miejsce na osobistą dumę, jeśli chodzi o zachowanie starego kodu. To działa albo nie działa, albo jest łatwe w utrzymaniu, albo kosztowne w utrzymaniu, i nigdy nie jest dobre ani złe po prostu dlatego, że dzisiejsze doświadczenie nie było dla ciebie dostępne wczoraj.

Zdecydowanie nie poprawiaj go tylko ze względu na ulepszenie. Jak powiedzieli inni (i jest to zdrowy rozsądek), wszyscy stajemy się lepsi (dla pewnej wartości „lepszego”) w miarę upływu czasu. To powiedziawszy, przeglądanie kodu (formalnie lub nieformalnie) często rozjaśnia te fragmenty, których prawdopodobnie chcielibyśmy nigdy więcej nie ujrzeć.

Chociaż nie uważam, że mamy obowiązek cofnąć się i poprawić kod, który nie jest zasadniczo uszkodzony, niepewny lub zależy od funkcji na wycofanej liście / EOL, oto kilka rzeczy, które zrobiłem w przeszłości w tej sytuacji :

• Zidentyfikuj osoby w zespole, które naprawdę kopią cofanie się i ulepszanie kodu, jako rodzaj czyszczenia mózgu lub miłego zadania wielkości kęsa, które daje poczucie spełnienia, i znajdź czas w harmonogramie, aby robili to regularnie. Zawsze miałem co najmniej jednego z tych ludzi w zespole, a takie podejście może również zwiększyć morale (lub przynajmniej nastrój), jeśli wszyscy jesteśmy w stanie spoczynku lub upadku.

• Użyj go jako podstawy do ćwiczenia uczenia się. W przypadku stażystów, studentów lub nowych / młodszych członków zespołu refaktoryzacja starego kodu z wytycznymi od starszych członków zespołu daje im możliwość komunikowania się z nowymi członkami zespołu, lepszego zrozumienia systemu i nabrania nawyku pisania / aktualizowanie testów jednostkowych i praca z ciągłą integracją. Ważne jest, aby pamiętać, że ćwiczenie to jest wykonywane z wytycznymi i jasno sformułowane jako ćwiczenie mające na celu ulepszenie kodu, ponieważ nie jest on zgodny z aktualnymi standardami / normami.

Więc nie ma odpowiedzialności za naprawę, ale te stare rzeczy mogą być naprawdę przydatne. A testy jednostkowe i CI są twoimi przyjaciółmi!

Niekoniecznie. Jeśli jednak przeprowadzasz konserwację kodu i natkniesz się na coś, co może być lepsze, możesz to zmienić, pod warunkiem, że masz odpowiednie testy jednostkowe, aby upewnić się, że nie utworzyłeś regresji.

Jeśli nie ma takich testów i nie możesz być pewien, że będzie on zachowywał się dokładnie tak, jak powinien, lepiej zostaw to w spokoju.

Z perspektywy inżyniera z pewnością bardzo chciałbym pracować nad starym kodem, dopóki nie będzie już można go poprawić. Ale czy jest na to uzasadnienie biznesowe? Pod koniec dnia kod ma przyczynić się do rentowności twojego miejsca pracy. Jeśli nie jest, po prostu to zostaw.

Jest duże zastrzeżenie, jeśli poprawiając kod, unikniesz wystąpienia błędu (myśląc o dużych piłkach Y2K tutaj ...) Zdecydowanie przywołałbym to z kimś wyżej, może twoim kierownikiem jednostki biznesowej, i przedyskutuj konsekwencje ulepszenia kodu.

Jeśli chodzi o mnie, pytanie można przeformułować i uogólnić: „Dlaczego ktoś miałby wydawać dodatkowe zasoby (czas, pieniądze, umysł, itp.), Jeśli ten konkretny fragment kodu działa teraz dobrze? Czy nie jest to strata zasobów? ?

Za każdym razem, gdy znajduję starszy kod, myślę o kilku rzeczach, które wydają się być ważne.

1. Po co mam wprowadzać zmiany?
2. Czy będę musiał obsługiwać ten kod? Jak szybko to może się wydarzyć (w bliskiej / dalekiej przyszłości)?
3. Czy ten kod jest wystarczająco wygodny do pracy? (Teraz)
4. Czy mogę mieć pewność, że wszystkie wprowadzone zmiany są bezpieczne? Różne testy zwykle pomagają odpowiedzieć na to pytanie.
5. Jakie konsekwencje mogę ponieść, jeśli popełnię błąd (błędy) podczas modyfikacji kodu? Czy można szybko przywrócić moje zmiany? Czy to będzie strata czasu?
6. ...

Właściwie powinieneś zadać sobie wiele pytań. Nie ma ich pełnej i ostatecznej listy. Tylko ty i prawdopodobnie twoi koledzy z drużyny możecie znaleźć odpowiedź.

PS Zauważyłem, że często przepisuję kod bardzo często, podczas gdy mój przyjaciel i kolega z drużyny pozostawiają go nietkniętym. To dlatego, że odpowiadamy na wspomniane pytania w różny sposób. I muszę powiedzieć, że bardzo często odpowiadamy na nie źle ... ponieważ nie możemy przewidzieć przyszłości.

Czy Microsoft musi aktualizować system Windows? Czy wszystkie dystrybucje * nix muszą się ciągle rozwijać? Lub bardziej praktyczny przykład, czy wszyscy nadal prowadzą samochody z lat 70.?

Zwykle możesz lepiej pisać kod za drugim razem, więcej dowiedziałeś się o domenie, pisząc go początkowo.

Nie ma prostej odpowiedzi na pytanie, czy warto ponownie wykonać lakierowanie. Zasadniczo nie powinieneś chyba, że: a) jest to dla ciebie dobra nauka lub b) oszczędzasz czas na dłuższą metę dzięki lepszemu kodowi. Pamiętaj, że każda zmiana wiąże się z ryzykiem błędów.

Na marginesie zdecydowanie zalecam testy jednostkowe. Bardzo łatwo jest zlikwidować refrakcję, szczególnie jeśli nie masz wyraźnie zaznaczonego obecnego zachowania za pomocą zautomatyzowanych pauz.

Uważam, że mamy obowiązek napisać najlepszy możliwy kod, jaki możemy dzisiaj. Oznacza to wykorzystanie wszystkiego, czego nauczyliśmy się w przeszłości i odmawianie skrótów w naszym projekcie. Jeśli presja harmonogramu powoduje, że coś zostanie obcięte, nie uważam, że jakość naszego oprogramowania powinna nawet zostać wzięta pod uwagę, ten schludny, animowany spinacz do papieru, z drugiej strony ...

Teraz, jeśli pracujesz i okazuje się, że kod, z którym musisz wchodzić w interakcje, nie jest napisany do poziomu, który obecnie jesteś w stanie napisać, rozsądnie jest go naprawić, JEŚLI możesz to zrobić w kontrolowany sposób metodyczny. Osobiście mam bardzo minimalne doświadczenie z tego rodzaju refaktoryzacją, jak wszyscy (prawie wszyscy?) Próbowałem całego „pozwól mi po prostu wszystko zmienić i módlmy się, żeby to działało” i dostałem dość kęsa. Proponuję zajrzeć do dyskusji Martina Fowlera ( jego książki lub jednego z wielu artykułów ) na ten temat. Wydaje się, że zainspirował większość obecnych przemyśleń na temat tego procesu.

Oczywiście czasami możesz nie być w stanie wyczyścić kodu tak, jak chcesz. Joel Spolsky napisał artykuł o tym, dlaczego warto poświęcić kilka tygodni na zwykłe przeredagowanie kodu. Przeczytaj tutaj i tak, jest trochę stary, ale myślę, że informacje są nadal aktualne.

Mam nadzieję że to pomogło

Wydaje mi się, że refaktoryzacja / ulepszanie starego kodu określa samego programistę. Chcesz ulepszyć kod napisany przed rokiem, pokazuje tylko twoje postępy, a jeśli poprawi to aplikację, a będziesz mieć możliwość, czas i zgodę na jej ulepszenie, zrób to.

Lepsze / ulepszone to porównanie wieloosiowe. Czy uważasz, że możesz uczynić go szybszym, mniejszym, bardziej zasobooszczędnym, bardziej czytelnym, bardziej użytecznym informacją, bardziej precyzyjnymi wynikami, bardziej elastycznym, bardziej ogólnym, zdolnym do działania na większej liczbie systemów, eliminując zależność od osobnego produktu?

Dlaczego Twoja firma powinna płacić za poświęcanie czasu na przepisywanie tego kodu zamiast pisania nowego kodu lub przepisywania innego fragmentu kodu?

Powinieneś wprowadzać ulepszenia, gdy okazuje się, że okazja się pojawia, ale szansa oznacza, że ​​albo już pracujesz nad kodem, albo podałeś powód biznesowy do wprowadzenia zmiany.

Przesunięcie zmiany do produkcji wprowadza niezerową szansę na zerwanie rzeczy (testy jednostkowe i funkcjonalne tylko zmniejszają tę szansę, nie eliminują jej) i powinny być wykonywane tylko wtedy, gdy oczekiwane korzyści przewyższają ryzyko.

Co jeszcze należy rozważyć - czy zamierzasz wprowadzić tę zmianę do produkcji, czy po prostu do działu rozwoju? Pasek dla dwóch scenariuszy jest zupełnie inny. Jeśli dzieje się to tylko w dziale rozwoju i może nigdy nie wejść do produkcji, to możliwość oznacza po prostu, że z jakiegoś powodu patrzysz na kod i nie jest to czasochłonne. To może być weryfikowana wymagane, jeśli push powinno się wydarzyć, a pominięte jeśli uważa się nieuzasadnione w tym czasie. Z drugiej strony, jeśli idzie o produkcję, jak powiedziałem powyżej, musisz rozważyć, czy ta zmiana jest warta kosztu: pod względem czasu poświęconego na wypchnięcie i korzyści z używania nowego kodu.

Jedna dobra zasada polega na tym, że jeśli zajęło ci trochę czasu, aby zrozumieć, co robi kod, i jeśli ten czas można by skrócić dzięki dobrze dobranym refaktoryzacjom, to służysz potrzebom firmy i zespołu przez podejmowanie tych kroków.

Jeśli kod nie korzysta z twojej analizy, jeśli nazwy pól nie stały się wyrazem zamiaru kodu, a metody nie zostały podzielone na czytelne części, firma straciła coś wartościowego: twój stan zrozumienia. Dzięki takim narzędziom, jak Visual Studio i ReSharper, tego rodzaju refaktoryzacje są bezpieczne, neutralne logicznie i potencjalnie mają dużą wartość dla przyszłej produktywności i zaufania programistów.

Jak mówi wujek Bob Martin: „Zawsze zostawiaj obozowisko czystsze, niż je znalazłeś”.

To pytanie zadaje kierownictwo w Twojej firmie.

Czy masz czas i zasoby niezbędne do powrotu i wprowadzenia zmian w starym kodzie?

Czy masz czas i zasoby, aby przeprowadzić test zespołu QA, który zmieniłeś, aby upewnić się, że nie jest uszkodzony?

Wpadłem w tę pułapkę, zanim byłem w module naprawiającym błąd, i widzę kod napisany przeze mnie lub kogoś innego, który był nieefektywny lub nieelegancki, zmieniam go i mam więcej problemów do rozwiązania, niż gdybym tylko naprawił błąd, który miałem za zadanie naprawić.

To zależy.

Jeśli dany kod jest naprawdę uszkodzony, tak że zawiera błędy, które nieuchronnie pojawią się w jednym punkcie (np. Jakiś licznik, który w pewnym momencie przepełni się i spowoduje nieprzyjemne problemy), to naprawienie ich może być warte wysiłku - ale jeśli zrób to, najpierw zastosuj wszystkie możliwe zabezpieczenia, aby uniknąć wprowadzania nowych błędów: upewnij się, że masz sensowne testy jednostkowe obejmujące wszystko, czego dotykasz, wszystkie zmiany sprawdzane przez kogoś kompetentnego, nalegaj na dokładne przetestowanie, upewnij się, że możesz wrócić do starej wersji wersji w dowolnym momencie, wykonaj kopię zapasową danych przed uruchomieniem produkcji, najpierw wdróż do środowiska akceptacji i przetestuj przez rzeczywistych użytkowników itp. Będziesz także chciał uzyskać zgodę przed kontynuacją: jeśli błąd jest naprawdę bombą zegarową , a twój menedżer jest nieco kompetentny,będziesz w stanie przekonać go / ją, by pozwolił ci to naprawić (a jeśli nie uzyskasz zgody, może to oznacza, że ​​się mylisz).

OTOH, jeśli twoja skarga jest tylko brakiem elegancji kodu, nie waż się jej dotykać. Od dłuższego czasu wykonuje wierną służbę w produkcji, zmiana kodu tylko cię zadowoli, ale nie doda żadnej wartości, i jak każda zmiana, istnieje ryzyko, że coś zepsujesz. Nawet jeśli tego nie zrobisz, twój czas jest cenny (dosłownie: zarabiasz za to, co robisz, więc każda minuta czasu kosztuje pieniądze), a ponieważ nie dodajesz żadnej rzeczywistej wartości, taka zmiana byłaby strata netto dla firmy i projektu.