W jaki sposób moja międzynarodowa firma może przejść z jednej platformy programistycznej na drugą?

10

Pracuję w dziale IT dużej międzynarodowej firmy. Tworzymy różne aplikacje intranetowe dla firmy (Reklamacje, Rabaty, Service Desk itp.). Teraz zdecydowaliśmy się na migrację z platformy PHP do .NET (integracja z MS CRM Dynamics, Exchange i MS Office jest jednym z wielu powodów). Ponieważ na obecnej platformie PHP jest około 20 różnych aplikacji, będziemy musieli wymyślić najlepszy sposób na przeniesienie ich wszystkich na nową platformę. Nie chcę wchodzić w szczegóły, jak przekonwertować kod itp., Ponieważ podczas migracji chcemy ulepszyć wszystkie te aplikacje.

Wymyśliliśmy 2 główne sposoby przenoszenia tych aplikacji:

  1. Obsługuje tylko jedną platformę. Co by to znaczyło Utwórz stronę główną i dosłownie migruj wszystkie aplikacje w systemie .NET (bez ich ulepszania, gdy to robimy). Po uruchomieniu nowego intranetu zaczniemy odbudowywać migrowane aplikacje i ulepszać je. Oszczędziłoby to nam rozwoju intranetu w .NET przy jednoczesnym wspieraniu platformy PHP.

  2. Obsługuj obie platformy przez pewien czas. Oznaczałoby to zbudowanie tylko strony głównej i 1 lub 2 nowych aplikacji (które nie istnieją na naszej platformie PHP). Udostępnianie ich użytkownikom, ale bez zdejmowania platformy PHP (dodalibyśmy menu i linki, aby ułatwić użytkownikom poruszanie się między aplikacjami na stronie PHP i nową). Następnie zaczniemy przepisywać aplikacje PHP, jednocześnie je ulepszając.

Teraz nie jestem pewien, co byłoby lepsze, z jednej strony (opcja 1) potencjalnie ułatwimy wszystkim użytkownikom, nie zmuszając ich do korzystania z dwóch różnych platform jednocześnie. Chociaż nie zobaczą żadnej poprawy w posiadaniu nowej platformy, oprócz wszystkiego ładniej wyglądającego, funkcjonalność aplikacji na nowej platformie będzie przez pewien czas taka sama. Myślę też, że dodalibyśmy (IT dep) więcej pracy, ponieważ zasadniczo pisalibyśmy każdą aplikację dwukrotnie.
Z drugiej strony w opcji dwóch (2) użytkowników miałoby gorsze doświadczenie, ponieważ dwie platformy wyglądają inaczej, ale zdają sobie sprawę z zalet nowej platformy, gdy nowe aplikacje są przenoszone.

Czy ktoś z was spotkał coś takiego? Co byś wybrał? A może jest jeszcze inny, lepszy sposób niż te, które przedstawiłem? Chciałbym wiedzieć, co myślisz i jak byś do tego podszedł.

Daniel Gruszczyk
źródło
1
Czy # 2 nie jest krokiem do # 1?
Tae-Sung Shin
Nie, to są dwie różne rzeczy. W 1 migrowalibyśmy cały intranet, zanim użytkownicy mogliby z niego korzystać, a następnie pracowaliśmy nad ulepszaniem aplikacji. W 2 migrowalibyśmy istotną część intranetu, pozwalaliśmy użytkownikom z niego korzystać, a następnie rozpocząć migrację innych aplikacji i ulepszanie ich podczas migracji ...
@greengit: przeczytaj ten temat, integracja z innymi, krytycznymi dla biznesu aplikacjami jest jednym z powodów. Moje pytanie nie dotyczy jednak „Dlaczego migrować”, ale „Jak migrować”.
Daniel Gruszczyk
Przeczytałem ten temat i zadałem to samo pytanie. Bardzo wątpię, czy projekt mógłby kiedykolwiek być uzasadniony kosztami. Czy możesz podać nam nazwę firmy, abyśmy mogli ją krótko sprzedać? ;)
Mcottle,
haha, szczerze mówiąc, nie dbam o koszty, ponieważ jestem studentem informatyki na stażu w firmie. Po prostu proszę o własną wiedzę ... Zupełnie mój kierownik uzasadnił koszty na tyle, aby uzyskać zgodę CEO ...
Daniel Gruszczyk

Odpowiedzi:

5

Rozważmy oba scenariusze:

Migracja od razu

Podczas migracji bazy kodu klienci będą nadal korzystać z istniejących aplikacji. Ponieważ migracja zajmie mało czasu, oznacza to, że będziesz musiał mieć zespół konserwacyjny na starej bazie kodu, w celu naprawy błędów i rozwoju funkcji. Każda zmiana dokonana w starej bazie kodu musi nastąpić w nowej bazie kodu. Skończysz pisać każdy wiersz kodu dwa razy, dopóki migracja nie zostanie zakończona, co będzie tym droższe, im dłużej będzie trwała migracja. Wszystko sprowadza się zatem do: jaki będzie czas realizacji pełnej migracji? Twoje koszty rozwoju będą gwałtownie rosły tak długo, jak długo potrwa czas realizacji.

Migracja kawałek po kawałku

W tym scenariuszu będziesz mieć lepszą kontrolę nad podwójnym wysiłkiem, ale nadal będziesz mieć wiele dodatkowych kosztów. Wdrożenie będzie obejmować dwie oddzielne platformy, z podwójnymi problemami z wdrożeniem i wymaganymi dodatkowymi zasobami serwera. O ile nie masz bardzo modularnie zorganizowanej aplikacji, przekonasz się, że często fragment kodu znajduje się na innej platformie niż ta, na której go potrzebujesz, co powoduje dodatkowe wysiłki związane z przenoszeniem i konserwacją. Dopóki migracja się nie zakończy, koszty rozwoju będą wyższe. Jednocześnie presja funkcji spowoduje, że migracja zajmie Ci dużo czasu.

Wniosek

Z własnego doświadczenia mogę powiedzieć dwie rzeczy:

  • Zmiana języków programowania rzadko się opłaca. Z analizy kosztów i korzyści wynika, że ​​bardzo mało prawdopodobne jest przejście na platformę .NET z PHP. Więc moja główna rada to: nie. Spróbuj rozwiązać problemy z istniejącą bazą kodów.
  • Najlepsze jest podejście kawałek po kawałku, ale będziesz miał trudności z robieniem tego na poziomie modułów aplikacji. Przekonasz się, że będziesz musiał opracować i utrzymywać funkcje po obu stronach architektury, dopóki migracja nie zostanie w pełni wykonana. Dobrym pomysłem może być ustalenie priorytetów funkcji nie w oparciu o to, czego klienci najbardziej potrzebują, ale o to, co ograniczy ilość podwójnego wysiłku (tym samym obniżając koszty).
Joeri Sebrechts
źródło
Zrobiłeś bardzo ciekawe punkty. Chociaż to nie ode mnie zależy, czy zmienimy platformę, czy nie, a ja będę pracował dla firmy do końca września (jestem z nimi na stażu w uni). Przejście z PHP na .NET może być dobrym pomysłem, ponieważ stary framework PHP, który mamy, wymagałby MAJOR prac, baz danych, a system, z którego obecnie korzysta firma, jest STARY i stworzony przez ludzi, którzy nie mieli wielkich umiejętności programistycznych. ..
Daniel Gruszczyk
Moje pytanie brzmiałoby również: czy „zmiana zamrożenia” na starej platformie to dobry pomysł? Rozumiem przez to, że wszelkie zmiany w istniejących systemach na platformie PHP, inne niż poprawki błędów, są zawieszane, dopóki nie zaczniemy przenosić danej aplikacji do .NET. To część mojego menedżera w planie migracji ...
Daniel Gruszczyk
Jeśli jest to nietrywialny system, bardzo mało prawdopodobne jest, aby zamrażanie zmian działało w praktyce. Jeśli ktoś naprawdę potrzebuje funkcji, eskaluje ją na wyższy poziom niż Twój menedżer i będziesz zmuszony wprowadzić zmiany. Również same poprawki błędów mogą pochłaniać znaczną ilość zasobów zespołu. I zawsze należy pamiętać, że w starych systemach wprowadzono wiele ulepszeń, a nowe projekty prawdopodobnie zapomną o tych wszystkich drobnych poprawkach, które będą musiały się powtórzyć, aby użytkownicy zaakceptowali przeprojektowany produkt.
Joeri Sebrechts
Jeszcze jedna kwestia: jeśli system ma zostać przebudowany, jakie zabezpieczenia są stosowane, aby tym razem zapewnić lepszą jakość kodu? Widziałem aplikację, która została przepisana 4 razy z powodu problemów z platformą i jakością kodu.
Joeri Sebrechts
2

Ze względów finansowych większość firm, w których pracowałem, stosowała drugie podejście, słusznie mogę dodać. Osiągnięcie # 1 zajmuje dużo pieniędzy, czasu i ryzyka. Użytkownik w większości rozumie numer 2, pod warunkiem, że zobaczy Twoje postępy i interakcję z nimi. W tej oszczędnej i wrednej gospodarce wątpię, aby ktokolwiek zająłby pierwsze miejsce.

Tae-Sung Shin
źródło
To była dokładnie moja myśl. Mój menedżer chce zacząć od nr 1, co wydaje mi się trudne do zrozumienia.
2

Podejścia związane z Wielkim Wybuchem rzadko są konstruktywne, jeśli chodzi o użytkowników końcowych. Odradzam to i szczerze mówiąc, nie mogę uwierzyć, że ktokolwiek poważnie uznałby to za opcję, biorąc pod uwagę liczbę rozpatrywanych wniosków.

Byłbym skłonny pójść z opcją drugą i zająć się ponownymi pracami w poszczególnych przypadkach. Wprawdzie może to potrwać dłużej niż podejście na papierze, ale w rzeczywistości narażasz się na znaczną część ryzyka biznesowego, wybierając podejście pierwsze i naprawdę nie chciałbym być w pobliżu w sprawie zgłoszeń do pomocy technicznej pierwszego dnia, jeśli nawet tylko jeden mały problem po stronie użytkownika.

Ponadto, jeśli przytłaczająca większość aplikacji opartych na usługach internetowych jest już napisana w php, w jaki sposób dostępna jest wiedza specjalistyczna .Net?

Myślę, że tak czy inaczej, użytkownicy będą musieli doświadczyć zmian, albo Big Bang (cue wiele zgłoszeń do pomocy technicznej), albo fragmentarycznie (zwiększenie znajomości). Jestem skłonny sądzić, że tak naprawdę nie oszacowałeś dokładnie, ile pracy trzeba będzie zrobić, aby przejść od bycia prawie całkowicie php do całkowicie .Net albo.

kuszenie
źródło
Wydaje mi się, że jest to bardziej skomplikowane niż obsługiwanie dwóch oddzielnych platform, czy nie. Tak czy inaczej, podejście nie jest zbyt dobre ... Dziękuję za poświęcony czas!
Daniel Gruszczyk
1

Po pierwsze, zgadzam się ze wszystkim, co mówi Joeri.

Pierwsza opcja jest naprawdę okropna. Jeśli to zrobisz i nie będziesz kontynuować wsparcia, jak opisuje Joeri, zamkniesz wsparcie na kilka lat, o ile klient to zobaczy. Po dwóch latach uzyskują efektywnie tę samą witrynę ze wszystkimi tymi samymi problemami, które znają i których nienawidzą przez ostatnie kilka lat. Plus ryzyko, że rynek zmienił się w międzyczasie i sprawił, że aplikacja stała się przestarzała i wymagała poważnej przebudowy. Ponadto, jeśli zamkniesz wsparcie na dwa lata, co według Ciebie stanie się z wszystkimi zleceniami serwisowymi? Nie odejdą. Przynajmniej niektórzy z twoich użytkowników „popadną w nieuczciwość” i opracują systemy o znaczeniu krytycznym w (prawdopodobnie) dostępie, aby uzupełnić luki w systemach, które przepisujesz - wtedy nadal będziesz obsługiwać dwie platformy ...

Opcja druga oznacza, że ​​będziesz obsługiwać obie technologie przez dłuższy czas. Ten okres czasu będzie dłuższy, niż myślisz, i możesz skończyć z trwale rozdrobnionym ekosystemem - tj. Znaczną ilością kodu PHP, który nie jest ekonomiczny do przepisania zmieszanego z nowszym kodem .NET.

Odepchnij się mocno od tego, kto to sugeruje. Znacznie taniej będzie napisać kod do zintegrowania aplikacji PHP z produktami, które sugerujesz, niż przepisać wszystko w .NET, a następnie zintegrować przepisany kod z produktami, nie zapomnij, integracja nie nastąpi magicznie, jeśli używasz .NET .

Jeszcze jedno, weź liczbę wierszy kodu PHP i umieść go w narzędziu COCOMO 2, aby dowiedzieć się, ile czasu i ilu programistów będziesz potrzebować, aby dokończyć przepisywanie.

Mcottle
źródło
Słuszna uwaga. Co byś wtedy zrobił, gdyby to nie od Ciebie zależało, czy migrujesz system, czy nie. Które podejście wybierzesz? Czy może istnieje inne podejście do nich, które wymieniłem? Jeśli Twój menedżer się z tobą nie zgodzi, czy spróbujesz udowodnić, że twoje podejście jest lepsze?
Daniel Gruszczyk
Napisz aplikacje PHP w bardziej warstwowy sposób „zorientowany na usługi”. Użyj magistrali usług przedsiębiorstwa, aby buforować interfejs między platformami PHP i Microsoft. Kluczową sprawą jest oszacowanie COCOMO, które powinno wystraszyć żywe przepisywania od twojego menedżera.
mcottle,
1

Masz trzecią opcję: -

Przeprowadź migrację kodu php na serwer Windows i ISS (taki sam, jak planujesz uruchomić .NET na!)

Następnie możesz dodawać nowe aplikacje w .NET (i powoli konwertować niektóre starsze na .NET), jednocześnie prezentując użytkownikom coś, co wygląda jak pojedynczy system.

James Anderson
źródło
PHP rzeczywiście działa pod IIS
Bart