Czy kiedykolwiek byłeś zaangażowany w DUŻĄ Przepisanie? [Zamknięte]

Joel Spolsky powiedział w jednym ze swoich słynnych postów:

Jeden najgorszy błąd strategiczny, jaki może popełnić każda firma produkująca oprogramowanie: przepisać kod od zera.

Chad Fowler napisał:

Widziałeś filmy, posty na blogu i szum, i zdecydowałeś, że zamierzasz ponownie wdrożyć swój produkt w Railsach (lub Javie, .NET lub Erlang itp.).

Strzec się. Jest to dłuższa, trudniejsza i bardziej podatna na awarie ścieżka niż się spodziewasz.

Czy kiedykolwiek byłeś zaangażowany w DUŻĄ Przepisanie?
Interesuje mnie twoje doświadczenie związane z tym tragicznym tematem, aw szczególności każde duże przepisanie, które zostało pomyślnie ukończone (jeśli w ogóle).

Brałem udział w kilku przepisywaniach w mojej karierze i wszystkie były katastrofami. Myślę, że wszystkie zawodzą z tych samych powodów

• Ogromne niedoszacowanie nakładu pracy: za każdym razem, gdy ktoś chce przepisać, dzieje się tak dlatego, że stary system używa starej technologii i jest trudny w utrzymaniu. Nie biorą pod uwagę tego, że z powodu swojego wieku może to wymagać 30-40 osobolat wysiłku rozwojowego. Myślenie, że możesz napisać całość w ciągu 6 miesięcy z zespołem 5 osób, jest głupie.
• Utrata wiedzy: stary system istnieje od tak dawna, robi wiele rzeczy i jest uzależniony od wszystkiego. Nie ma aktualnej dokumentacji i nie ma jednego punktu władzy, który faktycznie wiedziałby wszystkie rzeczy, które robi system. Znajomość poszczególnych użytkowników w poszczególnych działach będzie wymagała wiedzy, a znalezienie ich wszystkich jest trudne lub niemożliwe.
• Słabe decyzje w zakresie zarządzania: Przepisywanie, w które byłem zaangażowany, miało podobne oczekiwania wobec kierownictwa: nowy system powinien zostać „zrobiony”, a stary system można po prostu wyłączyć w określonym dniu, okresie. Żadna inna opcja nie była dopuszczalna. Myślę, że mają to w głowie, ponieważ wydają te wszystkie pieniądze na zatrudnienie nowych ludzi do tego ogromnego projektu. W rzeczywistości lepszą strategią ograniczania ryzyka jest przepisanie głównych funkcji starego systemu, powiedzmy, że zmierzysz się z 50-75% starego systemu w pierwszej wersji, a następnie zobaczysz, jak to działa! Z powodu powyższych punktów 1 i 2 prawdopodobnie działałoby to znacznie lepiej, ponieważ dowiadujemy się o niektórych funkcjach, które zostały pominięte, oraz o tym, co jest potrzebne do wyłączenia starego systemu.

Przepisywanie może być bardzo udane, jeśli odpowiednio je określisz. Nie wiem, czy spełniają one próg projektów „BIG” (TM), ale pozwól, że opiszę ci kilka bardziej udanych przepisywania.

Projekt 1

Firma, w której pracowałem, miała system drukowania pasków półkowych, który służył do generowania etykiet widocznych na półkach sklepowych na podstawie czegoś zwanego planogramem . Planogram został wygenerowany w standardowym oprogramowaniu branżowym, a nasze narzędzia odczytały ten dokument, aby utworzyć listwy półkowe przy użyciu szablonu dla docelowego sklepu. Oprogramowanie do tworzenia szablonów to bałagan z zagnieżdżonymi skończonymi maszynami stanów, które obejmowały kilka klas i 3 biblioteki DLL. Kiedy nadszedł czas na wdrożenie (wtedy) patentowego podejścia do robienia tablic z kołkami, było jasne, że obecny kod nie może obsłużyć tego, co chcieliśmy zrobić.

Rozwiązanie: Przepisaliśmy zakres tylko do silnika szablonów. Zastosowaliśmy odpowiedni projekt OO, aby zadbać o bieżące wymagania, a także spełnić nowe wymagania dotyczące płytki kołkowej. Czas na przepisanie wynosił 1 miesiąc. Gdybyśmy przepisali cały łańcuch narzędzi na dużą skalę, zajęłoby to dobrze ponad rok - ale nie musieliśmy tego robić.

Projekt 2

Aplikacja internetowa, którą nasz zespół zbudował od podstaw, zaczynała przerastać swój pierwotny wygląd. Nasz klient miał także pakiet nowych wymagań, dzięki którym strona byłaby znacznie lepsza dla naszych użytkowników, bardziej zgodna z „Web 2.0”, jeśli chcesz. Podczas gdy moglibyśmy wykreślić nasz dotychczasowy projekt w ramy, które obecnie mieliśmy, konserwacja była koszmarem. Znaliśmy aplikację dokładnie i wiedzieliśmy, które części musieliśmy przedstawić, a które zniknęły w ramach nowej wersji.

Rozwiązanie: Ukończenie naszego zespołu zajęło 3 miesiące - nie było to łatwe. Produkt końcowy był szybszy, bardziej skalowalny i przyjemniejszy dla użytkowników końcowych. Przekroczyliśmy oczekiwania naszych klientów. To powiedziawszy, musieliśmy podzielić nasz zespół, aby bardziej natychmiastowe poprawki błędów i łatki wspomagające zespół zostały wykonane w istniejącym systemie, podczas gdy druga połowa działała w nowym systemie. Przeprowadziliśmy szeroko zakrojone testy i włączyliśmy je na początku procesu. Powodem, dla którego tak dobrze się to potoczyło, jest to, że dobrze znamy tę aplikację i naszego klienta.

Projekt 3

Muszę tu dołączyć awarię. Wspieraliśmy klienta, który potrzebował narzędzia do zarządzania informacjami do użytku w sytuacjach katastrof / kryzysów. Odziedziczyliśmy aplikację Java Swing, którą napisali oryginalni programiści, nie rozumiejąc Swinga. Rozumiem przez to, że nie postępowali zgodnie z zaleceniami Sun dotyczącymi radzenia sobie z Swingiem i prawidłowego zarządzania interfejsem, w wyniku czego wpadlibyście w nieskończone pętle zdarzeń i inne dziwne i trudne do śledzenia problemy. W rezultacie było mnóstwo błędów, problemów z interfejsem użytkownika itp. To była bardzo skomplikowana aplikacja. Aby zachować nasze zdrowie psychiczne, próbowaliśmy przepisać źle napisaną aplikację Swing na dobrze napisaną aplikację Swing.

Rozwiązanie: Przepisanie zakończyliśmy w około 4,5 miesiąca, kiedy szacowaliśmy 3 miesiące. Aplikacja działała lepiej, zarówno w interfejsie użytkownika, jak i pod względem ilości danych, jakie mogła obsłużyć. Potem nastąpiło tsunami w 2004 roku. Ogromna liczba osób, które musieli śledzić, pokazała, że ​​Swing był niewłaściwą technologią do tego, czego naprawdę potrzebowali. Nie mogliśmy nadążyć za dostrajaniem wydajności i ostatecznie porzucili to narzędzie na rzecz brukowanej aplikacji internetowej stworzonej przez zespół Oracle, który mieli w domu. Jasne, że moglibyśmy uzasadnić to, co zrobiliśmy w oparciu o wiedzę, którą mieliśmy w tym czasie, ale przepisanie nie było wystarczająco agresywne i nie powiedzieliśmy naszemu klientowi, że jego wymagania dotyczące liczby osób, które mogłyby być potrzebne do śledzenia, były zbyt duże Niska.

Wniosek

Przepisywanie jest czasem konieczne i można je pomyślnie ukończyć, jeśli poprawnie je zaplanujesz. Możesz uzyskać więcej dzięki ukierunkowanym przepisywaniu części systemu niż przepisywaniu całej sprzedaży. Wreszcie, to, co powoduje niepowodzenie projektu, niekoniecznie musi samo przerabiać. Chociaż nigdy nie możemy być jasnowidzem, możemy wymyślić najgorsze scenariusze. Nauczyłem się projektować swoje systemy tak, aby obsługiwały dwa najgorsze możliwe scenariusze. W przypadku systemu zarządzania kryzysowego to nie wystarczyło - rzeczywiste liczby były 20 razy najgorsze, jakie otrzymaliśmy. Ale to nie był najgorszy możliwy scenariusz.

• Przepisywanie ze względu na przepisywanie nie jest twoim przyjacielem. Zawsze jest dużo złożoności, której nie widzisz, a okropne rzeczy, które widzisz, są narzędziami szkoleniowymi dla Twojego klienta. Zawsze pokazuj swoje bieżące postępy swojemu klientowi w regularnych odstępach czasu , aby pomóc Ci złapać najgorsze wykroczenia.
• Ukierunkowane przepisywanie przydaje się do radzenia sobie z najgorszymi wykroczeniami w bazie kodu. Nie rób całego przepisywania, jeśli możesz ograniczyć zakres i rozwiązać większość swoich problemów.

Brałem udział w kilku przepisywaniach z VB6 na .NET. W 2 przypadkach przepisywanie przebiegło bezproblemowo i właściwie skończyliśmy przed terminem. Drugie przepisanie trwało dłużej niż oczekiwano, ale zakończyło się bez większych problemów.

W naszym szczególnym przypadku przepisywanie NIE było najgorszą decyzją, jaką nasza firma mogła podjąć. Rezultaty końcowe były o wiele bardziej stabilne niż oryginały i umieściły nas w znacznie lepszym miejscu.

Jedną z największych pułapek przy kompletnym przepisywaniu istniejącego systemu jest myślenie: „Nie musimy określać, co ma robić nowy system - to bardzo proste, wystarczy zrobić dokładnie to, co robi stary system!” .

Problem polega na tym, że najprawdopodobniej nikt nie wie dokładnie, co robi stary system, a ty poświęcisz niezliczone godziny na uruchomienie nowego systemu zgodnie ze sposobem, w jaki różni użytkownicy starego systemu uważają, że powinien on działać. Pierwotne wymagania starego systemu również najprawdopodobniej nie są dostępne.

Mój jest historią „sukcesu”. Mój projekt dotyczył strony głównej z 4 niezależnie zarządzanymi / zapisanymi stronami satelitarnymi (poddomenami z różnymi aplikacjami). Mieliśmy 4 podstawowe bazy użytkowników (wszystkie w oddzielnych aktywnych katalogach) i żadna nie miała wspólnego systemu uwierzytelniania. 3 były dobrze ugruntowanymi i silosowymi aplikacjami, a czwarty satelita był zupełnie nowy i skopiował znaczną część kodu z naszej najbardziej znanej strony.

Cel: Wdrożenie systemu tożsamości dla całego przedsiębiorstwa, który może uwierzytelniać konta w 4 domenach i w pełni zarządzać (z samoobsługą) kontami w 1 domenach. Ponieważ .Net został już zaimplementowany w satelitach, klasyczna witryna asp, która służyła jako „wprowadzenie”, musiałaby zostać przepisana, dodane zarządzanie tożsamością, a wszystkie strony musiałyby przetestować regresję, aby upewnić się, że nie wpłynie to na usługi.

Zasoby: 3 głównych architektów - programista, zarządzanie tożsamością, kierownik projektu. Około 20 programistów, 10 analityków, 10 testerów.

Czas do zakończenia (od początku do końca): 1,5 roku

Uruchomienie Sukces: prawie awaria

Sukces długowieczności: wspaniały

Byłem architektem zarządzania tożsamością, więc zaprojektowałem bazy danych, podsystemy i interfejsy logiczne, dzięki którym wszystkie satelity będą oddziaływać. Architekt „programista” był głównym programistą z rozległą wiedzą biznesową na temat wszystkich satelitów oraz doświadczeniem związanym z aplikacjami i ich rozwojem do tego momentu.

Po kilku miesiącach gromadzenia wymagań przez około 50 różnych osób z różnych działów naszej korporacji udało nam się uporządkować logiczną architekturę i zaczęliśmy wymieniać kod. Ze względu na charakter zmiany musieliśmy przepisać własną stronę internetową i wszystkie funkcje, które ona zawierała w .Net. W niektórych przypadkach była to tylko kwestia refaktoryzacji. W wielu przypadkach wymagało to pełnego przepisania otaczających go procesów. W 2 przypadkach po prostu porzuciliśmy oryginalną funkcję jako nieistotną. W tym czasie nie dotrzymaliśmy 2 terminów (ale ostatecznie dotarliśmy do pierwotnie zaproponowanego terminu - ledwo). W dniu premiery nic nie działało. Uruchomiliśmy w sobotę, więc wpływ był dość minimalny, ale spędziłem cały dzień przeczesując dzienniki, przepisując elementy i oceniając obciążenia serwerów. Więcej testów mogło pomóc.

Pod koniec pierwszego dnia wszystkie strony były uruchomione i wszystko działało (powiedziałbym, że był to nominalny sukces). W ciągu ostatnich 2,5 roku wszystko odniosło ogromny sukces. Posiadanie wszystkich naszych witryn na wspólnej architekturze ze wspólną bazą szkieletową znacznie ułatwiło programowanie i pracę między programistami. Funkcje, które napisałem na naszej stronie 2,5 roku temu (podczas przepisywania) zostały odtąd zauważone / przyjęte przez kilka silosów satelitarnych.

Zwiększyliśmy logowanie, śledzenie użytkowników, dłuższy czas działania, pojedynczą aplikację odpowiedzialną za uwierzytelnianie / autoryzację / identyfikację. Silosy satelitarne mogą całkowicie skupić się na swoich aplikacjach i mogą ufać, że występują problemy z uwierzytelnianiem / autoryzacją aplikacji do zarządzania tożsamością.

Nasz projekt był pełen frustracji, bólu serca i katastrof. W końcu się opłaciło, a potem trochę. W 100% zgadzam się z oceną przepisywania przez Joela Spolsky'ego z reguły, ale zawsze są wyjątki. Jeśli zastanawiasz się nad przepisaniem, musisz tylko upewnić się, że jest to absolutnie to, czego potrzebujesz. Jeśli tak, to bądź przygotowany na wszystkie bóle, które się z tym wiążą.

Jestem teraz zaangażowany w ogromną przeróbkę kodu ... jedynym problemem jest to, że nad tym pracuję! Koszty utrzymania naszego obecnego oprogramowania są oburzające, ma wiele błędów, a my mamy 1 pracownika FT, który je utrzymuje, więc postanowiliśmy zbudować własne.

Jest znacznie wolniejszy, niż się spodziewałem, ale ostatecznie myślę, że będzie o wiele lepiej, ponieważ będziemy mieli własną bazę kodów, aby wszelkie zmiany, których chcą w przyszłości, można łatwo wdrożyć (oprogramowanie musi się często zmieniać, aby nadążać za aktualne czasy). Wprowadzamy też kilka poważnych zmian w projekcie podczas jego przepisywania.

Brałem udział w kompletnym przepisaniu w mojej poprzedniej pracy. I byliśmy bardzo szczęśliwi, że to zrobiliśmy. Powiedzmy, że czasami baza kodów jest tak zepsuta, że ​​lepiej zacząć od nowa.

Była to aplikacja wewnętrzna - tak naprawdę główna aplikacja biznesowa.

Zachowaliśmy stary system, tak jak napisaliśmy wersję 2. Jeśli dobrze pamiętam, zajęło nam to około roku (dwóch programistów, a potem trzeciego). Nie musieliśmy jednak dotykać bazy danych, więc przynajmniej migracja danych nie stanowiła problemu.

To wszystko zależy. W moim przypadku zastosowałem się do rady Joela Spolsky'ego i się myliłem . Chodziło o stronę ubezpieczeniową. Strona była okropna i oto, co zrobiłem, a następnie to, co powinienem był zrobić:

Zła strategia: nadzorowałem grupę 4 uczniów, aby:

• Student nr 1 - przepisał dostęp do bazy danych / zapytania, aby były bezpieczne
• Student nr 2 - przesunął wszystkie css „w górę”
• Student # 3 - dostosował wszystkie strony w3c
• Student # 4 - rozwiązał wszystkie oczekujące błędy
• Sam: usunąłem wszystkie ostrzeżenia php i bzdury (duplikaty kodu itd.)

Zajęło to 2 miesiące. Następnie przeprojektowaliśmy stronę. Potem zrobiliśmy to w wielu językach. W sumie musieliśmy zachować dużą część gównianego kodu, a struktura bazy danych pozostała taka sama. Nadal więc pracuję nad gównianymi rzeczami od roku i nigdy się nie skończy, dopóki nie zdecydujemy o całkowitym przepisaniu, co nigdy się nie wydarzy.

Dobra strategia:

• Przestudiuj całą witrynę, zrób dobry „Dokument wymagań produktu”.
• Przeprojektuj poprawnie bazę danych
• Zacznij od zera w moim własnym frameworku (który już działa)
• Przeprojektowana strona.
• Czy wielojęzyczny.

Czas potrzebowałby: dwa miesiące ( może mniej ).

• Dobry kod
• Dobra konserwacja.
• Wydajność.
• Brak odpowiedzi typu „nie możemy tego zrobić, witryna nie obsługuje takich produktów”.

Moje ostatnie słowa: wszystko zależy od złożoności rzeczy, które trzeba przepisać .

Proszę nie wahaj się poprawić mojego postu, aby był poprawny angielski, bardzo dziękuję

Olivier Pons

Firma, w której pracowałem, otworzyła główny projekt bazy kodu.

Połowa zespołu pracowała nad refaktorem, a druga połowa kontynuowała konserwację i ulepszanie istniejącego produktu.

Jak możesz sobie wyobrazić, refaktor tak naprawdę nigdy nie osiągnął punktu, w którym cokolwiek działało - był to tylko ciągły proces, który tak naprawdę nigdy nie miał niczego do pokazania.

Pomysł polegał na tym, że lepiej byłoby zrestrukturyzować bazę kodu i moglibyśmy po prostu „wpaść” w nowe funkcje, które zespół dodał do istniejącego produktu, a potem „nadrobić”.

Ale skończyło się to upadkiem firmy.

Byłem na wielkim przepisywaniu przez ostatnie 3 lata. Oryginalne oszacowaliśmy, że projekt potrwa 2 lata. Podstawowym pomysłem była wymiana sprzętu, użycie istniejącego systemu operacyjnego, przepisanie logiki biznesowej (od c do CPP), utworzenie nowej karty IO i napisanie nowego interfejsu użytkownika.

Po drodze podjęliśmy okropne decyzje. Nie mieliśmy żadnego prawdziwego doświadczenia w CPP i mentora, aby dobrze go uczyć. Próbowaliśmy samodzielnie zbudować strukturę interfejsu użytkownika opartą na win32. Sprzęt był tani, a BSP miał błędy. Oprogramowanie było bardzo elastyczne, ale trudne w utrzymaniu. W zeszłym roku wyrzuciliśmy domowy interfejs użytkownika i opracowaliśmy interfejs w .net. Całkowicie przepisaliśmy również nasz mechanizm trwałości i protokół transmisji danych.

Wymagało to dużo dodatkowego wysiłku, ale teraz projekt jest prawie ukończony, a pierwsze urządzenia są testowane w terenie. Projekt miał duże ryzyko, aby każda zmiana zakończyła się sukcesem. W projekcie były pewne pozytywne rzeczy, zaczęliśmy używać SVN (zamiast VSS), poświęciliśmy czas na napisanie testów jednostkowych i wdrożyliśmy kompilację nocną. Zaczęliśmy również używać scrum, aby uzyskać lepszy proces.

Patrząc wstecz, myślę, że przepisanie logiki biznesowej nie było konieczne, powinniśmy tylko zmienić najbardziej brzydkie części. A do pisania interfejsu użytkownika od zera nie rób tego, chyba że jest to twoja podstawowa działalność.

Właściwie zaczynam dużą refaktoryzację. 4MLoki prawdopodobnie powinny zostać zmniejszone do 800 KB lub mniej. Ten projekt ma wiele funkcji kopiowania i wklejania, niezrozumiałych funkcji językowych, mnóstwo powtarzających się bezużytecznych komentarzy, złe decyzje, tymczasowe włamanie i więcej włamań zmieniło się na stałe (w tym obejścia), całkowity brak wiedzy na temat podstawowych zasad informatyki lub inżynierii oprogramowania. Prawdopodobnie zespół serwisowy 32 złych programistów zostanie zastąpiony 2 dobrymi po refaktoryzacji.

Napisałem silnik do blogowania w 3 tygodnie. Przepisałem go w ciągu 8 godzin.

Planowanie z wyprzedzeniem jest kluczem do udanego przepisania. Znajomość systemu wewnątrz i na zewnątrz to także korzyść.

Nieco ponad dziesięć lat temu pracowałem dla firmy, która postanowiła „przeprojektować” swój starzejący się produkt podstawowy. Odtąd wymawianie słowa „przeprojektowanie” jest karalne. Trwało to znacznie dłużej niż oczekiwano, oczywiście kosztowało więcej, a nowy produkt był znacznie bardziej podobny do starego produktu, niż początkowo planowano.