Czy mamy obowiązek ulepszania starego kodu?

64

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?

JMQ
źródło
Czy robisz to w swoim czasie lub w firmie?
JBRWilkinson
42
w większości przypadków Twoim pierwszym obowiązkiem jest zwiększenie wartości firmy . Jeśli robisz coś, co nie dodaje bezpośrednio do dolnej linii, wszystko inne jest marnowane na wysiłek. Stary przetestowany działający kod jest testowanym działającym kodem , dotknij go, aby uczynić go lepszym jak ćwiczenie pozłacania, a teraz staje się nowym nieprzetestowanym, a tym samym niedziałającym kodem , co nie dodaje wartości do dolnej linii.
7
Zapytaj swojego szefa, co on chce, żebyś zrobił. Najprawdopodobniej zostaniesz porzucony. Z mojego doświadczenia wynika, że ​​zmiany kodu powinny być dokonywane tylko w ramach rzeczywistej dostawy. Losowe zmiany w czasie mają zbyt duże prawdopodobieństwo wprowadzenia błędów, których naprawienie zajmuje zbyt długo, ponieważ nie myślisz o zmianach na nowo.
1
Dodać jakieś uwagi na temat możliwej poprawy dokumentacji i zostawić to?
James P.
2
Napisz testy jednostkowe lub regresyjne. Nie zmieniaj kodu, ale pozwól, aby ktoś przyszedł później i pewnie wprowadził potrzebne zmiany, mimo że nie zna kodu.
James Youngman

Odpowiedzi:

66

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.

Bernard
źródło
4
Myślałem o „gniciu oprogramowania” i teorii rozbicia okna od pragmatycznych programistów i skutkach entropii oprogramowania. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
jmq
5
O ile nie zwiększysz wartości firmy poprzez refaktoryzację kodu, który już działa i jest w produkcji, trudno będzie uzasadnić niezbędny czas na usunięcie „zgnilizny oprogramowania” przełożonym. Zrób to tylko, jeśli będziesz aktywnie pracował w tym kodzie, w przeciwnym razie nie zyskasz wiele innych korzyści niż refaktoryzacja.
Bernard,
11
@ jmquigley, oprogramowanie gnije tylko wtedy, gdy jego kod źródłowy zostanie zmieniony, a uszkodzone okna działają tylko wtedy, gdy są widoczne. Stara baza kodów, jeśli nie trzeba jej dotykać, będzie działać tak samo, dopóki pozwala na to środowisko.
Péter Török
2
Staraj się nie wprowadzać błędu do działającego programu w trakcie jego „poprawiania” ;-)
robrambusch
4
Myślę, że kod „zgnilizna” jest niefortunną metaforą. kod nie gnije, jeśli nic nie zrobisz, w ogóle się nie zmienia. jeśli cokolwiek, kod twardnieje - wprowadza się entropię podczas pracy i można ją usunąć, wydając dużo energii na jej refaktoryzację (podobnie jak przekształcanie / kucie)
jk.
32

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.

Garrett Hall
źródło
czy mógłbyś być bardziej szczegółowy, co rozumiesz przez „refaktoryzacja powoduje regres”? Czy celem refaktoryzacji jest poprawa projektu oprogramowania bez zmiany jego zachowania? Czy możesz podać przykład?
Manfred
3
@John: Tak, taki jest cel refaktoryzacji: popraw kod, ale zachowaj zachowanie.
Bernard
@John, wszelkie nietrywialne refaktoryzacje ryzykują niezamierzoną zmianę zachowania, szczególnie gdy nie istnieją testy regresji.
Garrett Hall,
14

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. :-)

MathAttack
źródło
4
Aby pożyczyć od prawdziwego przykładu, którego nie ma w oprogramowaniu, niektóre firmy transportowe płacą pracownikom za czyszczenie i polerowanie swoich urządzeń, z różnych powodów, często dlatego, że pomaga to kierowcom / operatorom budować dumę z „ich” jednostki, dzięki czemu lepiej się troszczą i zwróć na to uwagę; unikanie problemów szybko i wygodnie. Z tego samego powodu, jeśli są mile do pokonania, wsiądź do ciężarówki i przejedź nią i martw się o oczyszczenie go po kilku tysiącach mil (od wybrzeża do wybrzeża).
JustinC
@justinC - dokładnie! Twój przykład przedstawia zarówno inny powód, jak i koszt alternatywny.
MathAttack
Koszt (lub wartość itp.) Jest rzeczywiście słowem kluczowym dla właściwej odpowiedzi. Powinno to zwiększyć wartość całej sumy, biorąc również pod uwagę, że dotknięcie starego kodu może zepsuć elementy (usunąć wartość) bez względu na to, o ile bardziej może być zoptymalizowany.
cregox
6

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.

rev. S.Robins
źródło
5

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!

jcmeloni
źródło
4
przekazywanie nowemu kodowi złego kodu jest najgorszym anty-wzorem zarządzania projektami, widzą go i myślą, że jest poprawny i po prostu go duplikują, zły kod rozprzestrzenia się jak rak z powodu takich złych porad.
1
@JarrodRoberson Dzięki za wskazanie, co powinienem uczynić bardziej oczywistym; Zredagowałem swoją odpowiedź, aby zauważyć, że robię to bardzo konkretnie w ramach uczenia się, a oni pracują z mentorem. To nie jest sytuacja, w której trzeba rzucić głęboko.
jcmeloni
Nadal uważam, że jest tak sformułowane, że ludzie będą czytać: „Daj to nowicjuszom, zwłaszcza stażystom i studentom”. i przestańcie czytać dla zrozumienia tutaj. Jeśli zostało sformułowane w miejscu, w którym zaczynało się od starszego członka i pary młodszych członków programujących styl XP lub coś w tym stylu, może nie być tak źle. Mam problemy z aspektami pozłacania i zwiększam ryzyko zmiany rzeczy ze względu na zmianę pierwszego punktu kuli.
1
Przeglądy kodu służą do zapobiegania wprowadzaniu złego kodu do kontroli wersji, a nie do identyfikowania złego kodu po fakcie, jest już za późno.
@JarrodRoberson Dziękuję za zwrócenie uwagi na problemy związane z moim niejasnym i niestety potencjalnie mylącym językiem; Wprowadziłem więcej zmian i trzymam się tego, co jest teraz.
jcmeloni
2

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.

Otávio Décio
źródło
4
Dodałbym „a jeśli to zmieni, nie
wydłuży
2

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.

tehnyit
źródło
2

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.

Igor Soloydenko
źródło
2

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.?

S3cretz
źródło
1

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.

Tom Squires
źródło
1

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

Jonathan
źródło
1

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.

Jeff
źródło
1

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.

jmoreno
źródło
Zmiany w kodzie produkcyjnym, które nie mają być wprowadzane do produkcji? Ale są trzymane w dziale rozwoju? hmm Nie sądzę, żebym to zaakceptował. Służy to jedynie zmieszaniu i złożoności późniejszego rozwoju, ponieważ nikt nie będzie pewien, czy należy go zmienić (ponownie), czy też nie zastosować się do innych zmian, które są przeznaczone do produkcji.
Marjan Venema
@MarjanVenema: po zakończeniu programowania wszystkie gałęzie powinny być identyczne. Jeśli później zobaczysz coś, co można poprawić, ale NIE MUSI być poprawione, popraw to w gałęzi programistycznej i pozostaw to tam, aby czekało na wznowienie rozwoju i podjęcie nowej decyzji.
jmoreno
Ach, ok, rozumiem. Dla mnie oznacza to, że nadal jest przeznaczony do produkcji, tylko później. Jest to dość ryzykowne, chyba że upewnisz się, że w systemie śledzenia problemów występuje problem towarzyszący, więc testerzy / dział qa również mogą zadać ci trud z powodu „ulepszeń”. W przeciwnym razie wprowadzą go do produkcji niesprawdzonej, ponieważ będzie się poruszać wraz z innymi zmianami.
Marjan Venema
@MarjanVenema: być może powinienem był powiedzieć, że zamierzam natychmiast wprowadzić go do produkcji. Jeśli masz pewność, że zmiana nigdy nie zostanie popchnięta do prod, to nie wprowadzaj zmiany. Jeśli OTOH, jesteś niepewny, ale zmiana jest łatwa do wykonania i już tam jesteś ... dokonaj zmiany. Jeśli chodzi o śledzenie i testowanie, miało to obejmować „sprawdzone zgodnie z wymaganiami”.
jmoreno
hmm, chyba zdecydowałbym się nie dokonywać zmian, chyba że jest to bezpośrednio związane z tym, nad czym pracuję. A ponieważ mamy branche na wydanie, zawsze wiem, kiedy (które wydanie) coś wejdzie do produkcji. Poza tym naprawdę uważam, że każda wprowadzona zmiana musi zostać przetestowana, a nie „tylko” sprawdzona zgodnie z wymaganiami. Oceny ludzi dotyczące tego, co stanowi ryzyko, są różne, a druga para oczu nigdy się nie zepsuje. Z drugiej strony, pracuję głównie nad kodem po stronie serwera, gdzie zmiany mogą subtelnie wpływać na wyniki zwracane do klientów. Ocena ryzyka zmian kodu po stronie klienta jest prawdopodobnie dużo bardziej prosta.
Marjan Venema
1

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ś”.

Dan Solovay
źródło
1

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ć.

scott.korin
źródło
0

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.

tdammers
źródło