Kiedy kod jest „starszy”? [Zamknięte]

63

Wszyscy to zrobiliśmy, oznaczyliśmy kod (często rzeczy, które odziedziczyliśmy) jako „starszy”? Ale nadal jest używany w systemach produkcyjnych - czy to naprawdę jest dziedzictwo? A co sprawia, że ​​jest to dziedzictwo? Czy powinniśmy unikać tej nieuzasadnionej etykiety doskonale działającego kodu; gdzie etykietowanie jest czystym przekonaniem, które pozwala nam przepychać się przez nowe rzeczy i sprawić, aby kierownictwo było miłe i szczęśliwe?


Podsumowanie odpowiedzi

Przeglądając odpowiedzi widzę cztery ogólne tematy. Oto jak widzę podział:

  1. Każdy dostarczony kod: 6
  2. Martwe systemy: 2.5
  3. Brak testów jednostkowych: 2
  4. Deweloperów nie ma w pobliżu: 1.5
Nim
źródło
1
Jest to starszy kod, gdy tylko zostanie dostarczony i działa.
Martin Beckett,
23
to stary kod, jeśli go nie napisałeś ;-)
Steven A. Lowe
20
Jest to starszy kod, jeśli każdy, kto go napisał, jest na emeryturze lub nie żyje, a jeśli ci, którzy go utrzymują, chcieliby, aby tak było. W przeciwnym razie nazywa się to po prostu istniejącą bazą kodu.
niepythonic
3
@ StevenA.Lowe, biorąc pod uwagę wystarczającą ilość czasu, jest to stary kod, nawet jeśli go napisałem.
Kyralessa

Odpowiedzi:

43

Sam jestem raczej stronniczy w stosunku do streszczenia Wikipedii :

Dotychczasowy system to stara metoda, technologia, system komputerowy lub program aplikacyjny, który jest nadal używany, zwykle dlatego, że nadal działa na potrzeby użytkowników, mimo że dostępne są nowsze technologie lub bardziej wydajne metody wykonywania zadania.

Wiele z tego, co inni opisują w swoich odpowiedziach, jest powodem, dla którego kod staje się „dziedzictwem”. Ale samo zasadnicze pytanie brzmi:

Ale nadal jest używany w systemach produkcyjnych - czy to naprawdę jest dziedzictwo? A co sprawia, że ​​jest to dziedzictwo?

Fakt, że jest nadal używany w produkcji, właśnie sprawia, że ​​jest to dziedzictwo . Jeśli kod nie działa poprawnie lub nie jest już używany w środowisku produkcyjnym, kod ten jest odpowiednio „uszkodzony” lub „wycofany”. Starsza wersja oznacza, że ​​nadal jest używana i działa dobrze, ale zawiera projekty lub techniki, które nie są już w powszechnym użyciu.

Każdy kod lub system, który (a) chciałbyś zaktualizować / zaktualizować, ale nie możesz, lub (b) wciąż jest w trakcie aktualizacji, jest systemem starszym. Nie oznacza to refaktoryzacji ani ogólnego czyszczenia kodu, oznacza znaczące zmiany w projekcie, być może przy użyciu nowej platformy, a nawet nowej platformy.

Istnieje wiele powodów, dla których systemy lub kod mogą stać się dziedzictwem:

  • Brak regularnej konserwacji lub zepsucia oprogramowania . Oczywiście, jeśli aplikacja nie jest regularnie utrzymywana, nie dotrzyma kroku głównym zmianom w świecie oprogramowania. Może to wynikać z prostego zaniedbania lub celowych wyborów opartych na priorytetach biznesowych lub ograniczeniach budżetowych.

  • Brak testowania. Inna odpowiedź odwołuje się do hiperbolicznego twierdzenia popularnego autora na temat dowolnego kodu nieobjętego testami będącymi starszym kodem. To naprawdę nie jest dokładna definicja, ale jest to możliwa przyczyna; bez dobrych testów (automatycznych lub ręcznych) programiści stają się nieśmiali i boją się wprowadzić poważne zmiany, ponieważ martwią się o coś, co może popsuć, prowadząc w ten sposób „zgniliznę oprogramowania” powyżej.

  • Blokowanie obrotów, często pomijany czynnik, który jest szczególnie podstępny w projektach wykorzystujących duże biblioteki lub frameworki typu open source (chociaż widziałem, że dzieje się tak również z narzędziami komercyjnymi). Często do frameworku / biblioteki zostanie wprowadzone duże dostosowanie, co sprawi, że aktualizacja będzie niemożliwie trudna lub kosztowna. W ten sposób system staje się starszy, ponieważ działa na starszej (i prawdopodobnie już nieobsługiwanej) platformie.

  • Kod źródłowy nie jest już dostępny, co oznacza, że ​​system można tylko dodawać, a nie zmieniać. Ponieważ systemy te muszą zostać przepisane w celu aktualizacji - w przeciwieństwie do przyrostowych / iteracyjnych zmian - wiele firm nie będzie się tym przejmować.

Wszystko, co spowalnia lub zatrzymuje aktualizacje bazy kodu, może spowodować, że baza kodu stanie się dziedzictwem.

Teraz osobne, niepotwierdzone, ale dorozumiane pytanie brzmi: co jest nie tak ze starszym kodem? Jest często używany jako pejoratywny termin, stąd pytanie:

Czy powinniśmy unikać tej nieuzasadnionej etykiety doskonale działającego kodu?

Odpowiedź brzmi: nie, nie powinniśmy; etykietowanie jest uzasadnione, a sam termin wyraźnie oznacza funkcjonujący kod. Nie chodzi o to, że jest to funkcja, ale o to, jak działa.

W niektórych przypadkach nie ma nic złego w starszym kodzie. To nie jest złe słowo. Starsze kody / systemy nie są złe. Właśnie zebrali trochę kurzu - czasem trochę, czasem dużo.

Dziedzictwo staje się przestarzałe, gdy system nie jest już w stanie zaspokoić (wszystkich) potrzeb klienta. Ta etykieta jest tym, na którą musimy uważać. W przeciwnym razie jest to po prostu równanie kosztów i korzyści; jeśli koszt aktualizacji byłby niższy niż koszt jego korzyści (w tym niższe przyszłe koszty utrzymania), to zaktualizuj, w przeciwnym razie pozostaw to w spokoju. Nie musisz wyrzucać słowa „dziedzictwo” w tym samym tonie, który zwykle rezerwujesz dla „kontroli podatkowej”. Jest to całkowicie OK sytuacja.

Aaronaught
źródło
To powiedziawszy, kontrola podatkowa powinna być również całkowicie OK.
Florian Margaine
Powiedziałbym: System, którego nie można już skalować za pomocą istniejącego stosu technologii.
Ramiz Uddin,
40

Zwykle oznacza to, że jest napisany w języku lub w oparciu o system, w którym zwykle nie tworzysz nowego oprogramowania.

Na przykład większość miejsc nie pisze nowych programów w Cobolu. Jednak duża część ich działalności może działać na aplikacjach napisanych w Cobolu. Dlatego te aplikacje są oznaczone jako „Starsze”.

Peter Mortensen
źródło
Najbardziej zgadzam się z tą odpowiedzią. Starsza wersja polega raczej na utknięciu na przestarzałej platformie niż na irytującym (ale nowoczesnym) kodzie, którego nie chcesz obsługiwać. Starszy kod jest często całkiem dobry (w przeciwnym razie nikt by się nie przejmował, gdyby go zostawić!), Ale zwykle jest przywiązany do przestarzałego sprzętu i przestarzałych języków / bibliotek / baz danych / itp.
Satanicpuppy
3
@Satanicpuppy: Po prostu nie mogę się zgodzić - poradziłem sobie (na przykład) z Javą, która zdecydowanie nie była powiązana z żadnym konkretnym sprzętem, biblioteką ani bazą danych - ale była tak „starsza”, jak to możliwe (i była przepisywane w Javie, więc język też nie był problemem). Ja również do czynienia z jakimś kodem, który był przywiązany do konkretnego sprzętu, ale wciąż tylko ledwo krawędzi do kategorii „Legacy”.
Jerry Coffin
4
@jerry: Więc co sprawiło, że to dziedzictwo? Dziedzictwo nie jest synonimem „złego”.
Satanicpuppy
1
W przypadku, o którym myślę, był to dość duży system rozproszony (zbudowany wokół BEA Tuxedo). Projekt wydawał się oparty na scenariuszach z podręczników, które mają uczyć o synchronizacji poprzez maksymalizację liczby potrzebnych synchronizacji / miejsc. To (w pewnym sensie) ma sens dla podręcznika, ale jest okropne dla prawdziwych projektów. Był na tyle duży, że nawet zaprojektowanie zamiennika było projektem wieloletnim. Wymiana musiała być przeprowadzana etapami bez przestojów, ponieważ system był absolutnie niezbędny dla firmy.
Jerry Coffin
1
@Cawas: Wydaje mi się, że odpowiedź @ Chada miałaby zastosowanie, gdy / jeśli nowy system byłby wykonywany w innym języku lub przy użyciu innego sprzętu itp. To było przebudowywane nadal przy użyciu Javy, wciąż przy użyciu Tuxedo itp. Nie uważam tego za stosowne.
Jerry Coffin
28

Legacy oznacza kod chcesz raczej zastąpić niż pracować. Biorąc pod uwagę stosunek większości programistów do większości istniejących kodów, zazwyczaj obejmuje to prawie wszystko oprócz tego, co piszesz w danym momencie (i dużego projektu, w którym musisz kodować według zamrożonego projektu, nawet tego, co piszesz w moment może być również uwzględniony).

  1. Nacisk „raczej” ma na celu przekazanie tego starszego kodu również oznacza, że ​​utknąłeś przy nim, nawet jeśli wolisz. Nie jestem jednak pewien, czy nacisk był wystarczający. Przyczyny tego mogą być różne. Niektóre naprawdę są po prostu zbyt duże i złożone, aby je zastąpić. Inne są interfejsami do innych systemów. Jeszcze inni kierują się polityką i osobowościami (na przykład kod jest okropny, ale babka na stoisku była niesamowita).
  2. Inną kwestią, której nie mogłem wystarczająco podkreślić, jest fakt, że chociaż jakość kodu może być czynnikiem, rzadko (jeśli w ogóle) jest jedynym czynnikiem - a często nawet nie jest szczególnie istotna.
  3. Myślę, że ludzie przeprowadzający testy jednostkowe jako jedyny czynnik decydujący są jak facet, który patrzy w świetle latarni na kolczyk, który jego żona upuściła blok. Światło może być lepsze, ale nadal patrzysz w niewłaściwe miejsce. Pomyśl, zanim wypijesz Kool-Aid .
  4. (Następstwo do 3.) Wydaje mi się, że niektórzy ludzie mówią więcej o tym, jak sobie życzą, niż są naprawdę. Jeśli Johna Conways ' Game of Life dla firmy Apple IIc Plus nie jest starszego typu, to dlatego, że jest na tyle mały i prosty, że jest to łatwe do ponownego wdrożenia od podstaw. Najdoskonalsze testy jednostkowe, jakie kiedykolwiek napisano, nie zmienią tego ani jota .

Ostatni punkt prowadzi do dwóch innych punktów, które moim zdaniem są często prawdziwe.

Po pierwsze, kod jest często zachowywany jako dziedzictwo, nawet jeśli tak naprawdę nie powinno być. Menedżerowie wyższego poziomu ogólnie zakładają, że ponowne wdrożenie systemu będzie kosztowało tyle samo lub więcej niż początkowe wdrożenie, co rzadko jest prawdą.

Po drugie, testy jednostkowe to miecz obosieczny. Sprawiają, że aż nazbyt łatwo jest myśleć, że ważne są zlokalizowane zmiany we wdrożeniu. Aby wprowadzić znaczące ulepszenia w większym systemie, często (zwykle?) Trzeba zmienić na tyle ogólną konstrukcję, że wiele (jeśli nie większość) testów jednostkowych staje się nieistotna. Niestety obecność testów jednostkowych i nastawienie, które wywołują, może bardzo łatwo zignorować zmiany, które są naprawdę konieczne.

Być może pomoże to przykład: załóżmy, że program ma bibliotekę interfejsu użytkownika ze świetnymi testami jednostkowymi i kilka programów korzystających z tej biblioteki. Ktoś z wyższej kadry kierowniczej przekonuje się, że „włączony internet” jest ważny (i tylko dla argumentu załóżmy, że w tym przypadku tak naprawdę ma rację). Po uważnej analizie menedżerowie średniego szczebla stwierdzili, że ich bieżące testy jednostkowe są wystarczające, aby przejść z interfejsu użytkownika wyświetlanego przez funkcję okienkowania lokalnego systemu operacyjnego na wyświetlanie zdalne za pomocą HTML / CSS / AJAX, zachowując przy tym wszystkie oryginalne sprawdzenie poprawności danych wejściowych.

To wspaniale, prawda? Pokazuje, jak przydatne może być testowanie jednostkowe. Wymieniliśmy całą implementację całego interfejsu użytkownika, ale zadbaliśmy o to, aby wygląd, działanie i funkcjonalność były praktycznie spójne, a wszystkie dane wprowadzane przez użytkowników są sprawdzane w celu zapewnienia integralności danych. Testy jednostkowe uratowały dzień!

Albo nie! Ta wspaniała, wysoce elastyczna, starannie przetestowana biblioteka interfejsu użytkownika pomogła wszystkim oślepić fakt, że w przypadku tego programu na rynku wraz z użytkownikami interfejs sieciowy jest zupełnie niewłaściwy. Tak naprawdę potrzebna jest usługa internetowa z interfejsem RESTful i absolutnie nie ma własnego interfejsu użytkownika.

Teraz z pewnością jest prawdą, że testy jednostkowe same w sobie nie usuwają zdolności ludzi do zrozumienia ich rynku lub uświadomienia sobie, że jest to naprawdę potrzebne. Jednocześnie przypomina mi się stara linia dotycząca młotów i gwoździ. Może być jeszcze gorzej, gdy nie tylko masz młotek, ale masz duże doświadczenie z tym młotem i wiesz, że jest to naprawdę wysokiej jakości młotek, który działa niesamowicie dobrze w wielu różnych sytuacjach. Sam fakt, że jest tak dobry w tak wielu rzeczach w tak wielu sytuacjach, sprawia, że ​​jeszcze trudniej jest rozpoznać, kiedy jest to całkowicie nieodpowiednie narzędzie do danego zadania.

Jerry Coffin
źródło
3
Widzisz, teraz nie wiem, czy to zaznaczyć, czy nie, niestety jest to prawda, ale zastanawiam się, czy jest to postawa, od której musimy uciec ...
Nim,
+1. Już miałem odpowiedzieć na coś w tym samym stopniu. Starsza wersja to dowolny kod, który jest używany, a nie aktywnie utrzymywany.
Denis de Bernardy,
@Nim: Nie sądzę, że jest to postawa, od której „musimy” uciec. To zwykłe stwierdzenie tego, co oczywiste. :-) Pomyśl o tym przez chwilę i zastanawiaj się, co byś uważał za starszy kod, gdybyś przybył w nowym środowisku; będzie wszystko oprócz nowych i fajnych rzeczy, które są aktywnie rozwijane.
Denis de Bernardy,
@Jerry, więc nie lubisz testów jednostkowych? ;)
Nim
1
@Nim: Nie tak - myślę, że są przydatne, ale daleko im do panaceum, które często są przedstawiane.
Jerry Coffin
17

Stary kod jest zwykle osierocony w jakiś sposób. Główny programista, jedyny facet, który to zrozumiał, został potrącony przez autobus, a jego notatki zostały napisane w jego ojczystym ukraińskim dialekcie, który jest teraz martwym językiem. Lub, alternatywnie, wszystko napisane w Visual Basic 6.0 .

Cały czas pracuję nad starszym kodem. Powiedziałbym, że cechy są następujące:

  • Nie można go przedłużyć bez ogromnego wysiłku
  • Nie można go łatwo przenieść na nowy sprzęt
  • Jest to zbyt ważne z punktu widzenia biznesu, aby można je łatwo wymienić

Jeśli nie ma tych cech, prawdopodobnie nie jest to dziedzictwo. Jeśli nie podobają ci się skrypty Perla twoich poprzedników , sympatyzuję, ale nie sądzę, że to spuścizna. Niedawno zmodernizowałem 15-letni skrypt Perla, który został dołączony do przestarzałej bazy danych Sybase . To był tort w porównaniu z wprowadzeniem nawet najmniejszej zmiany w naszym okropnym systemie księgowym COBOL .

Satanicpuppy
źródło
Przerażające, nasz główny programista też jest Ukraińcem ... haha ​​... Zgadzam się ze środkową częścią twojej odpowiedzi, pierwszy punkt - nie tyle - myślę, że to zależy od konfiguracji twojego zespołu programistów.
Nim,
1
lol, prawdopodobnie udało ci się obrazić (kierowcy autobusów, język ukraiński i twórcy VB6) wszystko w jednym akapicie. Ale cholera, śmiałem się :)
Darknight
Jestem podróżnikiem w czasie od 1999 roku, masz na myśli, że Visual Basic 6 jest dziedzictwem od 2011 roku?
hjk
@hjk Powiedziałbym prawie wszystko po pojawieniu się C # / asp.net w 2005 r. na chwiejnym gruncie, ale na pewno po zakończeniu wsparcia ze strony Microsoft w 2008 roku.
Satanicpuppy
12

W swojej książce, Skutecznie współpracując ze starszym kodem, Michael Feathers definiuje starszy kod jako kod, który nie jest objęty testami jednostkowymi. To jedna definicja, z którą się zgadzam. Uważam też, że starszy kod jest stary, ale nadal można go używać.

Grant Palin
źródło
24
Uderza mnie to w przypadku próby zdefiniowania „wszystkiego, co nie jest zgodne z wybraną przeze mnie metodologią” jako „dziedzictwa”. To nic innego jak tania taktyka debatowania, po prostu biorąc prawo Godwina i łagodząc język (ledwo) na tyle, aby czytelnicy nie mogli od razu rozpoznać, że to nic innego jak nieobsługiwany (i często nieobsługiwalny) atak każdego, kto nie przestrzega jego preferencje.
Jerry Coffin
4
@Jerry: Zgadzam się z definicją Feather. Kod bez testów jednostkowych jest grozą. Jeśli zdecydujesz, że chcesz przefakturować niektóre jego części, aby łatwiej było to uzasadnić, zapomnij! w każdym razie możesz wprowadzać błędy i kod prawdopodobnie nie jest możliwy do przetestowania! Uważam, że definicja Feather jest niekonwencjonalna, ale on jest kimś, kto zarabia na życie dzięki starszemu kodowi.
pożarł elysium
10
@devoured: testy jednostkowe nie są dokładnym testem lakmusowym pod kątem umiejętności pracy z kodem. Miałem do czynienia z kodem, w którym brakowało testów jednostkowych, ale było bardzo proste - oraz z kodem, który zawierał testy jednostkowe i wciąż był koszmarem. Ostatecznie testy jednostkowe same w sobie niczego nie rozwiązują. Testy jednostkowe dla projektu, w którym (na przykład) podział na jednostki został źle wykonany, wciąż mogą być całkowicie bezwartościowe, a cały projekt (łącznie z testami) musi zostać wyrzucony na miejsce, aby wyprodukować coś użytecznego.
Jerry Coffin
6
Zgadzam się z komentarzami Jerry'ego. Brak testów jednostkowych jest tylko jednym z wielu zapachów kodu, które mogą ( ale nie muszą) wskazywać na zło.
smci
4
Znowu zgadzam się z definicją Pióra, a także pochłoniętą. Brak testu jednostkowego to wszystko, ponieważ oznacza to, że brakuje nawet najpiękniejszego fragmentu kodu. Testy jednostkowe stanowią 51% dokumentacji i 100% specyfikacji kodu. W kodzie brakuje większości jego dokumentacji, a cała jego specyfikacja powinna słusznie zostać zaklasyfikowana jako starsza wersja.
8

Technicznie, spuścizna to dowolny kod, który jest gotowy do napisania. Gdy tylko pojawi się w produkcji, jest to dziedzictwo. Ponieważ jest tam już wartość, nie możesz jej po prostu wyrzucić ... Musisz sobie z tym poradzić.

To „przed czasem”, ale „wciąż boli cię głowa” .

kretynów
źródło
5

Starszy kod to kod, który pozostaje tylko w bazie kodu, ponieważ w przeciwnym razie wiele rzeczy przestałoby działać. Innymi słowy: jedynym powodem bycia jest zgodność wsteczna.

Wolisz go zmienić, a nawet wyrzucić, ale nie możesz, ponieważ złamiesz cały kod na nim polegający (który może być kodem, którego nie możesz odpowiednio dostosować). Dlatego musisz go zachować (a czasem nawet zachować), ale nie chcesz, aby cały nowy kod był napisany przeciwko niemu.

Przykładem są przestarzałe metody interfejsu API biblioteki. Nadal tam są, więc jeśli ktokolwiek zaktualizuje bibliotekę, może nadal zbudować swój projekt, ale są one oznaczone jako przestarzałe, a ty kompilator powinien dać ci ostrzeżenie.

Kolejnym przykładem są te wszystkie dziwne sztuczki, które Microsoft robi, aby uruchomić programy napisane dla wersji systemu operacyjnego, które całkowicie przestały działać. Szczytem tego bytu:

Po raz pierwszy usłyszałem o tym od jednego z twórców przebojowej gry SimCity, który powiedział mi, że w jego aplikacji jest krytyczny błąd: wykorzystał pamięć zaraz po jej zwolnieniu, główne nie-nie, które działało OK na DOS, ale nie działałby w systemie Windows, w którym zwolniona pamięć prawdopodobnie zostanie natychmiast przechwycona przez inną uruchomioną aplikację. Testerzy z zespołu Windows przeglądali różne popularne aplikacje, testując je, aby upewnić się, że działają poprawnie, ale SimCity ciągle się zawieszał. Zgłosili to programistom systemu Windows, którzy zdemontowali SimCity, przeszli przez debugger, znaleźli błąd i dodali specjalny kod, który sprawdzał, czy SimCity działa, a jeśli tak, uruchomił alokator pamięci w specjalnym trybie, w którym nadal może korzystać z pamięci po jej zwolnieniu.
- Joel w sprawie oprogramowania

back2dos
źródło
4

Dziedzictwo pociąga za sobą dziedziczenie. Starszy kod to po prostu kod odziedziczony z przeszłości. Jest to starszy kod, nawet jeśli sam go napisałeś!

Wszystkie inne rozważania wynikają zasadniczo z faktu, że nie napisałeś tego specjalnie dla bieżącego projektu. Niekoniecznie jest to zła rzecz sama w sobie.

Ando
źródło
Przeszłość może trwać 1 dzień, 1 godzinę lub 1 rok. To nie czyni z tego dziedzictwa.
Vince Panuccio,
2

Moim zdaniem to, co jest uważane za starszy kod, zależy od wielu rzeczy, a znacznik „starsze” jest prawdopodobnie specyficzny dla organizacji.

Jeśli sprzęt / system operacyjny, na którym działa, są stare i zostały wycofane przez dostawcę - ostrzeżenie 1.

Jeśli jest więcej pracy, spróbuj go naprawić, niż przepisać, z dowolnego powodu, ponieważ

  • pierwotni programiści zniknęli
  • program jest źle napisany
  • można to zrobić lepiej na nowszej platformie i nadal jest to opłacalne dla firmy

aby to zrobić

  • oryginalne źródło nie jest już dostępne i / lub brakujące elementy

Uderzenie 2.

Połączenie wielu organizacji w jedną - Strike 3 - jedna strona prawdopodobnie zostanie oznaczone jako dziedzictwo.

Czy istnieje lepsza, tańsza alternatywa sprzedawana jako aplikacja lub usługa innej firmy - strike 4.

Czy organizacja jest czymś w rodzaju szpitala lub okręgu szkolnego, w którym spójność jest ceniona w stosunku do nowych technologii, jeśli chodzi o codzienne operacje? Uznanie aplikacji za starszą potrwa dłużej niż w przypadku tej samej aplikacji w organizacji komercyjnej / konkurencyjnej.

Jeśli firma jest małą firmą programistyczną, która stale ulepsza / wspiera aplikację, aby robić to, czego potrzebują klienci, czy jest to uważane za starszy kod, czy po prostu „stary” kod. Znam firmę o nazwie Mc2Ok - opracowali oprogramowanie na systemie Windows 3.1 i po prostu je kontynuowali. Wciąż ma bardzo podobny wygląd do Windows 3.1, ale dodali także interfejs sieciowy. Jest to dwuosobowa firma deweloperska (zgaduję) i powiedziałbym, że kiedy przestaną nad tym pracować, będzie to uważane za dziedzictwo i czas na migrację po roku lub dwóch, jeśli go użyjesz. Ale to może być kolejne 10 lub więcej lat.

Czasami, gdy zmienia się zarządzanie, może zmieniać się falami, które mają wiele efektów spływu ... W zależności od siły nowego zarządzania, może sprawić, że wiele aplikacji pozostanie starymi, które w przeciwnym razie mogłyby być w porządku.

Uważam, że każda organizacja musi zdefiniować, co dla nich znaczy „starszy kod”. Kiedyś patrzeć przez The Sunday Times ogłoszeniach co tydzień, aby zobaczyć, jakie organizacje szukaliśmy. To był mój barometr dla tego, co nie było już istotne (to znaczy dziedzictwa). No cóż, Sunday Times nie ma już znaczenia :-) I możemy uogólnić, że COBOL jest dziedzictwem, ASP Classic jest dziedzictwem itp. Ale wierzę, że każda organizacja musi zdecydować, kiedy wniosek zostanie uznany za dziedzictwo.

Gregory Thomson
źródło
+1, fajna odpowiedź - lepiej rozważyć coś spuścizny z perspektywy organizacji ...
Nim,
0

Kod jest dziedzictwem, gdy ktoś boi się go zmienić, ponieważ może go złamać. Jeszcze bardziej bolesne jest to, że cały system może zostać ugodzony przez zmiany w tym kodzie.

Dlatego też zgadzam się z definicją Michaela Feathersa. Kod, który ma dobre testy jednostkowe, można bez obaw zmienić.

Uważam również, że starszy kod nie ma nic wspólnego z tym, ile ma lat. Od samego początku można pisać starsze kody.

komisacroS
źródło