W jaki sposób nadal rozwijasz duże (długoterminowe) systemy oprogramowania ze starszym i nowym kodem?

Question

Pracuję na dużej podstawie kodu z dużą bazą instalacyjną użytkowników. Kod został pierwotnie napisany w wersji vb6 z kilkoma modułami COM dla C++ dla pracy na niskim poziomie.

Całkowicie nie można przepisać całego kodu, który jest już napisany w wersji vb6 i jest używany przez naszych klientów każdego dnia, ale nadal wprowadzamy ulepszenia i dostosowania oprogramowania (duże i małe).

Moje dotychczasowe rozwiązanie to napisanie większości nowego kodu w C# (winForm, a nawet wpf teraz), a następnie użycie COM interop do wywołania modułów z vb6.

Czy ktoś tam ma doświadczenie z długoterminowymi pakietami oprogramowania podobnymi do tego (ponad 10 lat), których nie można przerwać na kompletny przepis, ale wymaga ciągłego rozwoju w tym samym czasie. Ponadto, w mieszanych systemach takich jak ten, jaki jest najlepszy sposób na połączenie modułów? Używam teraz COM, ale rozważyłem także IPC z oddzielnymi procesami.

Answer 1

Trudno podać jedną, kompleksową odpowiedź, ale podejście wysokiego poziomu jest jasne. Przynajmniej takie podejście zastosowałem. Ustal priorytety swoich celów, a następnie spróbuj określić koszty osiągnięcia tych celów. Twoje koszty zasadniczo sprowadzają się do "czasu programisty".

Po pierwsze, chcesz, aby wszystko działało. Jeśli masz coś, co działa i nie ma powodu, aby go przepisać, zachowaj to.

Jeśli część istniejącego kodu wymaga aktualizacji w celu wykonania swojej pracy, wówczas trzeba liczyć się z kosztami utrzymania. W tym momencie musisz ustalić, czy przepisanie poprawi koszty utrzymania na tyle, by być tego warte. Nie zapomnij odjąć testów i debugowania nowych błędów, ponieważ pojawią się nowe błędy. Nie lekceważ kodu roboczego tylko dlatego, że jest stary.

Jeśli twój istniejący kod jest wystarczająco modułowy, zwykle można go odłamać po kawałku. Najpierw przepisz komponenty wysokiej konserwacji.

Jeśli będziesz robić nowy rozwój w C#, powinieneś dobrze pracować z komponentami COM, dopóki nie będziesz miał wystarczającego uzasadnienia, aby je zastąpić.

Answer 2

Myślę, że trzeba spojrzeć na ścieżki uaktualnień dla swoich klientów. Faktem jest, że w pewnym momencie, kiedy mają 16 rdzeni procesorów, będziesz chciał współbieżności, aby przyspieszyć działanie. Masz więc biznesowe uzasadnienie, aby odejść z VB6 i do WCF. WCF ma wbudowaną obsługę współbieżności i synchronizacji. Może być używany do komunikacji lokalnej w procesie, jak również komunikacji między procesami i między maszynami. Ma także tę zaletę, że pozwala ci wykonywać więcej programowania stylu AOP.

Answer 3

Myślę, że masz dobry plan. To ostatecznie przeniesie większość kodu do C#, korzystając z lepszego zestawu narzędzi.

Czy kod VB6 zawiera obiekty COM?

Wspomniał Pan, że kod "nie może zostać zatrzymany po całkowitym przepisaniu". Ale nie musisz się zatrzymywać. Jeden po drugim można zastąpić każdy element funkcji VB6 równoważnym kodem C#. Umożliwiłoby to dokonanie jednej zmiany na raz (najlepiej za pomocą zautomatyzowanych testów, aby udowodnić, że niczego nie złamałeś).

Answer 4

Napisz ponownie w razie potrzeby, gdy istnieje czynnik motywujący.

Jeden stary projekt Windows, nad którym pracowałem, miał silnik reguł napisany w C, który działał, więc zostawiliśmy go jako czarną skrzynkę DLL.

Zbudowaliśmy nowy front-end, a baza użytkowników była pod wrażeniem łatwego w użyciu, nowoczesnego wyglądu aplikacji. Nic w internalach naprawdę się nie zmieniło.

Warstwa dostępu do bazy danych korzystała z SQL Server DBLIB i nie była ponownie przekształcana, dopóki nie zaktualizowaliśmy serwera SQL.

Answer 5

Obecnie jestem jednym z kilku programistów pracujących nad dużym, starszym systemem, który zaczął się jako połączenie C i C++ z Win32, a później z MFC z niewielkim zbiorem wśród kodu C z tyłu. Niedawno przeskoczyliśmy z VC++ 6 do Visual Studio 2005 (i od tego czasu uaktualniliśmy to do 2008) do najnowszej wersji projektu, nad którym pracujemy. Od aktualizacji IDE/kompilatora, oczyszczaliśmy część wyglądu i sposobu działania i dodaliśmy zarządzane C++ z WinForms, a teraz C# z WCF.

Podczas gdy podstawy naszego systemu, w tym back-end, z pewnością pozostaną w C (przynajmniej w dającej się przewidzieć przyszłości), wszystko co nowe w interfejsie użytkownika będzie najprawdopodobniej wykonane w C#/WCF. Kiedy mamy czas i/lub potrzeby, zamierzamy zacząć zastępować starsze części interfejsu z równoważnym kodem C#/WCF.

Answer 6

Posiadamy kilka tego typu systemów. Niepokojącą częścią tego wszystkiego jest lifecycle support status of VB6. Istnieje ryzyko (jednak niewielkie), że nie będziesz w stanie uzyskać pomocy od firmy Microsoft z powodu problemu showstopper z np. przyszłe uaktualnienie serwera i nie będzie można go naprawić samodzielnie (np. z powodu niezgodności między bibliotekami DLL VB6 a poprawionym serwerem O/S). Jest to ryzyko, które może interesować twoje kierownictwo - ale jeśli nie masz obecnie żadnych umów o wsparcie, być może są z tym zadowoleni?

Właściwie patrzymy na przepisywanie i przeprojektowywanie kilku najważniejszych. Próbowaliśmy ewolucji przyrostowej i może ona działać, ale tworzy (powiedzmy) interesującą operację i sytuację konserwacyjną. Zdecydowanie polecam oprzyrządowanie wszystkiego (starego i nowego kodu) z dużą ilością konfigurowalnych rejestratorów, jeśli jeszcze tego nie zrobiłeś, aby pomóc w izolowaniu błędów.

COM brzmi jak rozsądny interfejs między starszymi i nowymi. Jeśli nie masz bardzo prostych interakcji między komponentami, nie widzę powodu, dla którego chciałbyś wrócić do bardziej podstawowego mechanizmu IPC. COM ma złożoność, ale zapewnia również wiele przydatnych abstrakcji dla np. pisanie i porównywanie danych, które musiałbyś wymyślić na nowo i utrzymać ...