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

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

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.

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

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.

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 .

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

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

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

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.

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.

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.