Podajmy trochę kontekstu Twojemu pytaniu.

Twoja firma ma:

• 25-letni produkt
• Starszy programista back-end ze znaczną wiedzą instytucjonalną.
• Założenie: kilku średnich / młodszych programistów
• Chęć zmodernizowania środowiska
• Warstwa tłumaczenia

Niewyczerpująca lista wymagań dotyczących warstwy tłumaczeniowej:

• Transformacja wiadomości
• Walidacja wiadomości
• Łączność z bazą danych
• Integracja z siecią z systemami innych firm
• Przetwarzanie danych
• Złożone wykonywanie warunkowe

Tak więc tę warstwę tłumaczenia można nazwać integracyjnym oprogramowaniem pośrednim . Obsługuje logikę biznesową niezwiązaną z podstawowym 25-letnim produktem, z (spodziewam się) różnymi przepływami i paradygmatami.

Jest kilka aspektów, które nazwałbym Bad Ideas ™, ale istnieje integracyjne oprogramowanie pośredniczące nie jest jednym z nich. Najgorszy, IMHO, jest brak dokumentacji : może mieć to swoje źródło w tym, że masz tylko jednego programistę z wystarczającym doświadczeniem, aby zwizualizować cały proces. Powinien udokumentować proces, więc jeśli zostanie potrącony przez autobus, rozwój nie zatrzyma się z piskiem. Zmniejszy to również zapotrzebowanie zespołu devteam na zadania wsparcia API.

O serwerze Node - jestem zmuszony, przynajmniej na początku, zgodzić się z twoim architektem. Dzielenie logiki biznesowej na różne platformy / języki bez silnego powodu architektonicznego można nazwać złym pomysłem ™. Dwie bazy kodów do utrzymania, dwa zestawy wymagań dla nowych stanowisk pracy. Zasady KISS mogły zostać tutaj zastosowane w celu obniżenia kosztów.

Nie mówię, że nie należy podejmować takiej decyzji, ale należy wziąć pod uwagę wszystkie koszty (ponowne szkolenie, mapowanie procesów, walidację przepływu itp.), a Twój architekt prawdopodobnie jest ich świadomy. Język używany do kodowania starszego produktu może zostać wycofany, na przykład wymuszając pełną migrację na inną platformę, a pełną implementację NodeJS można wybrać jako Plan A.

Mimo to myślę, że chęć Poprawa obecnej sytuacji jest godna podziwu i cenna, a zamiast toczyć żmudną bitwę, zasugerowałbym inny plan.

Fakt, że starszy programista kieruje wysiłkiem w zakresie oprogramowania pośredniego, sugeruje, że nie jest on przeciwny do zmiany i zdolnym profesjonalistą. Podziel się z nim swoim punktem widzenia i wysłuchaj jego opinii. Może to docenić, przedstawić własny punkt widzenia (który pomoże zrozumieć uzasadnienie obecnego stanu) i rozważyć chęć unowocześnienia rozwiązania z uwzględnieniem całej wiedzy instytucjonalnej - i dojść do wniosku, że pomysł nie jest bez zasług. Firma polega na jego możliwościach, a jego sugestia dotycząca modernizacji może mieć duże znaczenie.

Pełne ujawnienie: w przeszłości byłem starszym facetem, na którego narzekasz. Byłem, nie z wyboru, ale z konieczności, głównym architektem i programistą frameworka uderzająco podobnego do tego, co opisujesz.

Powiem ci, że zdawałem sobie sprawę ze wszystkich problemów technicznych i organizacyjnych przez cały czas . To był proces narastający; nigdy nie było takiego punktu w czasie, w którym można by podjąć jedną decyzję, aby to powstrzymać. Prawie każdy krok wydawał się wówczas dobrym pomysłem.

Istnieje sposób myślenia i pewne inne aspekty (np. Presja czasu, postrzegana presja, kultura zespołowa itp.), co prowadzi do takich rozwiązań. Nie mówi ci nic o inteligencji, charakterze ani żadnych ukrytych planach twojego programisty.

Skończyłem bałagan tymi środkami, które zajęły dosłownie lata:

• Wybierz zupełnie nowy język programowania i framework sieciowy oraz ekosystem modułów, który zastąpi stare języki i nasz własny framework, który mieliśmy do tej pory.
• Oceniaj i ucz się wszystkiego w wolnym czasie.
• Wdrażaj mały, w pełni opłacony projekt klienta jako dowód koncepcji z tą technologią, upewniając się, że używasz tylko podejść, które są naprawdę standardowe, ogólnie akceptowane sposoby w tym ekosystemie, aby upewnić się, że nowe osoby (posiadające wcześniejszą znajomość języka, ale nie naszej domeny) mają dobry start.
• Znajdź sposoby na uruchomienie nowego rozwiązania poza starym, bez ponownego wpadnięcia w pułapkę oprogramowania pośredniego (tj. luźno połączone przez mikrousługi lub pośrednio przez przeglądarkę klienta.
• Powoli i pracochłonnie przekonaj bardzo konserwatywny zespół, że GoodIdea [tm] nie tworzy nowych projektów / funkcji w starym frameworku, ale zanurza się w nowym. To było bardzo wyczerpujące emocjonalnie.
• Zmiana orientacji mojej roli w firmie, ostatecznie opuszczenie tego zespołu i zbudowanie nowego pod innym kątem, aby odciąć wszystkie więzi z (techniczną) przeszłością (część problemu polegała na tym, że potrafiłem rozwiązywać problemy w tym starym zespole i musiałem ich zmusić, aby stanęli na własnych nogach, odchodząc).

To była fajna jazda iz perspektywy czasu bardzo udana. Zespół jest teraz na dobrej drodze do wyjścia z tamtej epoki. Ale podejście też było dość nietrywialne. Może daje ci to kilka pomysłów i ośmielam się twierdzić, że albo będziesz potrzebować pełnego wsparcia swojego dewelopera Seniour, albo usuniesz go z tego stanowiska (w jakikolwiek możliwy sposób). Usiądź i porozmawiaj z nim długo, jeśli masz jakąkolwiek pozycję, aby to zrobić, rozmowa typu „gdzie chcemy być za 5 lat” ...

Jedna uwaga, co nie może być wystarczająco podkreślone: ​​istniejący system może być świetny (właściwie prawdopodobnie był, skoro mógł przetrwać tak długo), ale będą problemy organizacyjne związane z podejściem. Istnieje ogromny problem z dokumentacją, ogólną dystrybucją know-how, współczynnikiem ciężarówki i bardzo długą fazą uczenia się nowych kolegów. Ponadto wielu, zwłaszcza młodszych programistów, nie jest zainteresowanych inwestowaniem dużej ilości wiedzy w bardzo specyficzny kontekst aplikacji, co wcale nie pomoże im w dalszych projektach. Powody takie jak ten (w moim przypadku) doprowadziły do ​​opisanej zmiany, a mówienie o nich otwarcie usuwa osobiste żądło z problemu.

Dalsza lektura: Zgodnie z komentarzami nie wydaje się jeden, który wymyślił ten proces. :-) Zobacz wzorzec StranglerApplication, aby uzyskać więcej przemyśleń na ten temat.

Wygląda na to, że ten programista opanował rynek. Niezłe narzędzie negocjacyjne do negocjacji wynagrodzenia na koniec roku.

IMHO, logika biznesowa nie należy do tłumacza, możesz zasugerować podział tego tłumacza na warstwy , oddzielając logikę biznesową od prostych metod tłumaczenia.

Przygotuj się na to, że deweloper będzie temu przeciwny;)

Ponadto kierownictwo może po jego stronie, określając dodatkowy wysiłek / koszt by to potrwało.

To może być długa walka i możesz być tym, który ostatecznie dokona separacji;)

Jak mogę przekonać tego programistę (i resztę mojego zespołu, którzy są dość bierni w tego typu sprawach), że to zły pomysł?

To nie jest Twoim zadaniem jest „przekonać” programistę.

Zasadniczo główne pytanie dotyczy Twojej pozycji:

• jeśli jesteś tylko kolegą na tym samym lub niższym poziomie możesz zgłosić ryzyko kierownictwu. Skoncentruj się przy tym na problemach, które mogą wyniknąć z obecnego systemu. To wtedy to ich decyzja, a nie twój problem;
• jeśli jesteś szefem , uzgodnij z innymi menedżerami potrzebę zmiany systemu programowania, a następnie przekaż tę decyzję programistom . Decyzja powinna być uzasadniona i poprawnie zakomunikowana (zarządzanie zmianą w Google) oraz zorganizowana zmiana, ale wtedy powinieneś oczekiwać, że Twoi podwładni dostosują się do niej. Możesz zaoferować starszemu programistowi wpisowe, aby został z firmą, np. podwyżka pensji, więcej dni wolnych i troska o jego ego.

Pracując dla firmy ważne jest, aby rozwinąć umiejętność oderwania się od siebie i braku troski. pozytywny sens! Jeśli próbujesz zmienić coś, czego nikt inny nie chce zmienić, zostaniesz znienawidzony przez współpracowników i kierownictwo.

Skoncentruj się więc na tym, czym jest Twoje zadanie. Oznacz i informuj - ale pozwól podejmować je ludziom, którzy faktycznie są odpowiedzialni za podejmowanie decyzji. Nie ma znaczenia, czy masz rację - znam wiele osób, łącznie ze mną, którzy zostali zwolnieni, mimo że mieli rację - lub dlatego, że miała rację.

Edycja: nie rezygnuj z pracy; Miałem błędne przekonanie

Wow, kiedy pierwotnie czytałem ten post, rozwiązanie techniczne brzmiało jak warstwa tłumaczeniowa, która niepotrzebnie wykonywała niepowiązane zadania. Brzmiało to bardzo sprzecznie z zasadą „pojedynczej odpowiedzialności” / filozofią UNIX, niezbyt spójne lub dobrze skonstruowane.

Myślę, że kluczowym szczegółem, którego przegapiłem, było to, że jest to archaiczny system zaplecza obsługujący podstawową logikę biznesową i myślę, że to sugeruje, że biznes utknął na tym z jakiegoś zrozumiałego powodu. Dzięki komentarzom i głosom negatywnym za skłonienie mnie do uznania tego.

Ponieważ firma jest stara, prawdopodobnie nie chce jej dotykać. Lub możliwe, że firma logika zaimplementowana w warstwie translacji jest całkowicie niezwiązana z celem tego podstawowego zaplecza.

Inne komentarze są słuszne; dokumentacja jest w porządku

Decyzja o napisaniu warstwy tłumaczeniowej wydaje się rozsądna teraz, gdy czuję, że mam w głowie dokładniejszy obraz rzeczywistości.

To, co opisujesz, nie działa Brzmi to tak bardzo jak nowy język programowania, być może nowy framework, napisany specjalnie dla tego przypadku użycia. Brzmi jak dość standardowa inżynieria w tym, co teraz rozumiem jako scenariusz.

Musisz zapoznać się z kodem, a Ty i Twoi koledzy potrzebujecie szkolenia i dokumentacji, aby zrozumieć system. Efektywne byłoby pisanie dokumentacji na temat rzeczy, gdy się ich uczysz.