Czy istnieją jakieś studia przypadków dotyczące przepisywania wskaźników sukcesu / niepowodzenia oprogramowania?

Widziałem wiele postów o przepisywaniu aplikacji jako złych, doświadczenia ludzi na ten temat tutaj na temat programistów oraz artykuł, który przygotowałem Joel Spolsky na ten temat, ale nie ma twardych dowodów ani studiów przypadków. Poza dwoma przykładami podanymi przez Joela i kilkoma innymi postami tutaj, co robisz ze złym kodem i jak decydujesz, co z tym zrobić na podstawie prawdziwych badań?

W tym przypadku istnieją dwaj znani mi klienci, którzy mają stary starszy kod. Ciągle kuleją wraz z nim, ponieważ jak jeden z nich się dowiedział, przepisywanie było katastrofą, było drogie i tak naprawdę nie działało, aby znacznie poprawić kod. Ten klient ma bardzo skomplikowaną logikę biznesową, o czym szybko się przekonali.

W obu przypadkach są to aplikacje o znaczeniu krytycznym, które przynoszą firmie duże przychody. Ten, który próbował przepisać, czuł, że uderzy w ścianę z cegieł, jeśli starsze oprogramowanie nie zostanie w pewnym momencie zaktualizowane. Dla mnie tego rodzaju ryzyko wymaga badań i analiz w celu zapewnienia udanej ścieżki.

Czy istnieją rzeczywiste studia przypadków, które to zbadały? Nie chciałbym próbować poważnego przepisywania bez znajomości najlepszych praktyk, pułapek i sukcesów opartych na rzeczywistych badaniach.

Aftermath: dobra, po dalszych poszukiwaniach znalazłem trzy ciekawe artykuły na temat studiów przypadków:

1. Przepisz lub użyj ponownie . Przeprowadzili badanie aplikacji Cobol przekonwertowanej na Javę.
2. Drugi dotyczył oprogramowania Reuse: Developers Experiences and Perceptions .
3. Ponowne użycie lub przepisanie Kolejne badanie dotyczące kosztów utrzymania w porównaniu do przepisania.

Niedawno znalazłem inny artykuł na ten temat: Wielka Rewrite . Tam autor wydaje się poruszać niektóre z głównych problemów. Wraz z tym pojawił się pomysł prototypowania przy użyciu proponowanego stosu nowych technologii i pomiaru, jak szybko deweloperzy go podnieśli. To wszystko było preludium do przepisywania, które moim zdaniem było świetnym pomysłem!

Nie mogę uwierzyć w te wspaniałe komentarze, ale nie zostały one nigdy udzielone przez autora, więc zaznaczam to jako wiki społeczności.

Nie znam studiów przypadków, ale myślę, że standardową odpowiedzią na to podejście jest prawdopodobnie „dodaj testy jednostkowe i refaktoryzuj”.

Wydaje mi się, że jest to prawdopodobnie możliwie najniższe dostępne podejście. Oczywiście nie znam wystarczającej ilości szczegółów, aby mieć pewność, że jest to właściwe podejście, ale na podstawie tego, co wiem do tej pory, nie wiem zbyt wiele, co może być znacznie lepsze.

Jeśli przeprowadzą testy jednostkowe (prawidłowo - naprawdę wychwytując wszystkie wymagania), trudno jest znaleźć sposób na refaktoryzację, aby doprowadzić do prawdziwej katastrofy. Najgorsze, co może się zdarzyć, to to, że nie robisz tyle postępów, ile chcesz. Jednocześnie, jeśli baza kodu jest w tak złym stanie, jak sugeruje to pytanie, istnieje spora szansa, że ​​konieczne będą poważne wysiłki, aby umożliwić postęp, niezależnie od wybranej trasy.

Zakładam, że projekty przepisywania nie różnią się znacząco pod względem wskaźników awaryjności niż projekty ogólnie i odsyłam do najnowszego raportu CHAOS w celu uzyskania najlepszych informacji.

Jakiś czas temu przejrzałem Efektywną pracę ze Starszym kodem autorstwa Michaela Feathersa i odkryłem, że oferuje on dobry wgląd w rzeczywistą praktykę utrzymywania starszego kodu, w tym pisanie testów (nawet jeśli nie wiesz, do czego służy kod) oraz refaktoryzacja / przepisywanie kursów. Jest trochę przestarzały, ale wysoko oceniany na Amazon.

Mówiąc z doświadczenia i mieszkając w firmie, która od początku źle rozumiała architekturę korporacyjną, mogę szczerze powiedzieć, że największym problemem jest wypracowanie kompleksowego zrozumienia.

Pomysł, że system można rozbić na części i rozumieć indywidualnie, ma wady. W pewnym momencie jedna osoba lub kilka osób musiało być w stanie zrozumieć cały problem w całości. Jeśli ten problem jest serią problemów biznesowych i napędzających je technologii; zrozumienie wszystkich systemów do poziomu, na którym możliwa jest ich wymiana bez katastrofy lub niespełnienia wymagań, może zająć kilka lat. Tak było z całą pewnością w mojej firmie, kiedy objąłem stanowisko dyrektora ds. Technologii. Gdyby nie to, że sam jestem programistą, nie byłbym w stanie powoli zrozumieć wszystkich szczegółów źle zorganizowanej, ściśle powiązanej, ściśle związanej architektury i integracji technologii. Jeśli małe ukryte, nieudokumentowane szczegóły, takie jak"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" są pomijane, wyniki mogą być katastrofalne, a jedynym sposobem, aby to wiedzieć, jest powolne odkrywanie wszystkiego.

Jeśli ktoś zostanie poproszony o wymianę silnika w samolocie podczas lotu lub ponieść pewną śmierć - biorąc pod uwagę odpowiednią liczbę narzędzi i zasobów, które osoba będzie musiała wiedzieć, jak obejść czujniki, układ hydrauliczny, jak zmienić trasę przepływu paliwa , manipuluj systemami, które nigdy nie zostały zaprojektowane do zmiany lub manipulowania z zewnątrz lub z kokpitu. Tak często wygląda perspektywa przepisania aplikacji biznesowej. Aplikacja jest zwykle wtłaczana w biznes między wieloma innymi technologiami.

Wydaje mi się, że moją podstawową kwestią jest to, że system musi być rozumiany w niemal pełnej złożoności, a w pewnym momencie musi być zrozumiany w swojej kompletności, aby nowy system mógł być właściwie „zaprojektowany”, a nie tylko „wykonany”.

Pliki cookie są tworzone, oprogramowanie (powinno być) projektowane.

Istnieje wiele przykładów firm, które zmarły w wyniku przepisania, takich jak Netscape . Są też firmy, które przetrwały przepisywanie bez większych problemów, takie jak Twitter .

Nie ma żadnych skwantyfikowanych studiów przypadku, ponieważ nie jest możliwe przeprowadzenie eksperymentu kontrolnego, w którym spojrzy się na sukces biznesowy nieprzepisywania w porównaniu z sukcesem biznesowym przepisywania. Każda aplikacja jest inna.

Istnieje kilka oczywistych przypadków, w których przepisywanie ma sens i wiele przypadków, w których nie ma sensu. Przygotowałem mały przepis, aby dowiedzieć się, czy przepisanie w twoim przypadku ma sens .

Myślę, że przepisywanie ma teraz więcej sensu, ponieważ szybko kodujemy na ramiona ciągle udoskonalanych inwazyjnych frameworków, takich jak Rails, Grails, AngularJS. Jeśli chcesz przejść z zwykłego js do Angulara, przepisanie jest wszystkim, co możesz zrobić. To wciąż może mieć mnóstwo sensu. Jeśli zamieniasz jedną implementację DIY na inną (jak wszystkie przykłady w artykule Joela Spolsky'ego ), prawdopodobnie zwariowałeś.

Nie znajdziesz wielu bezstronnych studiów przypadków, które są niczym innym niż po raportach z działań - większość ludzi nie będzie płacić za wykonanie tej samej pracy co najmniej dwa razy (raz jako przepis, raz jako uaktualnienie, najlepiej przypadkiem byłoby wielokrotne przepisanie / uaktualnienie przez różne zespoły).

Studium przypadku, które znalazłeś, wydaje się być opracowane przez Fujitsu, i nic dziwnego, że wynik był taki, że lepiej było użyć narzędzi Fujitsu.

Z organizacyjnego punktu widzenia przepisywanie jest najwyraźniej błędem tylko wtedy, gdy przepisana aplikacja nie działa lub projekt jest anulowany przed zakończeniem - w przeciwnym razie nie wiadomo, czy opóźnienie w wydaniu przepisanej wersji było opóźnieniem z powodu jakiejkolwiek straty, którą poniosłeś lub po prostu zbiegiem okoliczności. Jeśli anulujesz przed zakończeniem, jest to ogólnie uważane za całkowitą stratę czasu i zasobów. Uaktualnienie może potencjalnie wiązać się z tym samym problemem, ale jest mało prawdopodobne, aby zmiana była na taką samą skalę (dostajesz coś za swoje pieniądze).

Najlepszym przypadkiem z punktu widzenia programowania jest zrobienie obu - przyrostowych aktualizacji podczas przepisywania, zarówno wzajemnego wspierania, jak i inspirowania. Jeśli nie masz różnych zespołów, będzie to naturalnie trwało dłużej.

Należy pamiętać, że stanowi to przybliżoną wskazówkę, kiedy należy rozważyć całkowite przepisanie - projekt jest na tyle mały, że można to zrobić tak łatwo, lub organizacja jest na tyle duża, że ​​może sobie pozwolić na jedno i drugie, licząc wysiłek lub koszt nauki wart. Zauważ też, że jeśli przepisywanie nigdy nie nadrabia zaległości, może to oznaczać kilka rzeczy, ale wszystkie inne są równe, prawdopodobnie oznacza to, że przepisywanie nie było konieczne.