Как быть со старшим коллегой, который написал свой собственный язык программирования? [закрыто]

Давайте дадим вашему вопросу некоторый контекст.

В вашей компании есть:

• Продукт 25-летней давности.
• Старший бэкенд-разработчик со значительными институциональными знаниями
• Предположение: Несколько мид/младших разработчиков
• Желание модернизировать окружающую среду
• Слой перевода

Неполный список требований к уровню перевода:

• Преобразование сообщения
• Проверка сообщения
• Подключение к базе данных
• Сетевая интеграция со сторонними системами
• Обработка данных
• Сложное условное исполнение

Таким образом, этот уровень перевода можно назвать промежуточным программным обеспечением интеграции . Он обрабатывает бизнес-логику, не связанную с базовым продуктом 25-летней давности, с (я ожидаю) другими потоками и парадигмами.

Есть несколько аспектов, которые я бы назвал Bad Ideas™, но существование промежуточного ПО для интеграции не входит в их число. Худшее, ИМХО, это отсутствие документации : это может быть связано с тем, что у вас есть только один разработчик с достаточным опытом, чтобы визуализировать весь процесс. Он должен задокументировать процесс, чтобы, если его собьет автобус, разработка не остановилась. Это также уменьшит потребность команды разработчиков в задачах поддержки API.

Насчет Node-сервера - вынужден, по крайней мере на начальном этапе, согласиться с вашим архитектором. Разделение бизнес-логики на разные платформы/языки без серьезной архитектурной причины можно назвать Плохой Идеей™. Две кодовые базы, которые нужно поддерживать, два набора требований для новых должностей. Принципы KISS, возможно, были применены здесь для снижения затрат.

Я не говорю, что это решение не должно приниматься, но все затраты (переобучение, картирование процессов, проверка потока и т. д.) должны быть приняты во внимание, и ваш архитектор, вероятно, знает о них. Язык, используемый для кодирования устаревшего продукта, может быть прекращен, например, что приведет к полной миграции на другую платформу, и в качестве плана А может быть выбрана полная реализация NodeJS.

Тем не менее, я думаю, что желание улучшить текущую ситуацию похвально и ценно, и вместо того, чтобы вести тяжелую битву, я бы предложил другой план.

Тот факт, что старший разработчик возглавляет работу над промежуточным программным обеспечением, говорит о том, что он не против изменений и является способным профессионалом. Поделитесь с ним своей точкой зрения и выслушайте его мнение. Он может оценить этот факт, предложить свою точку зрения (которая поможет вам понять обоснование текущего состояния) и рассмотреть ваше желание модернизировать решение с учетом всего институционального знания - и прийти к выводу, что идея не без заслуг. Компания рассчитывает на его возможности, и его предложение по модернизации может иметь значительный вес.

Полное раскрытие: в прошлом я был старшим парнем, на которого вы жалуетесь. Я был не по выбору, а по необходимости главным архитектором и разработчиком фреймворка, поразительно похожего на то, что вы описываете.

Скажу вам, что я был в курсе всех технических и организационных проблем в течение всего времени . Это был постепенный процесс; никогда не было того единственного момента времени, когда можно было бы принять единственное решение, чтобы остановить это. В то время почти каждый шаг казался хорошей идеей.

Существует способ мышления и некоторые другие аспекты (например, нехватка времени, воспринимаемое давление, командная культура и т. д.), которые приводят к таким решениям. Это ничего не говорит вам об интеллекте, характере или каких-либо скрытых планах вашего разработчика.

Закончил бардак вот такими мерами, на которые ушли буквально годы:

• Выберите совершенно новый язык программирования и веб-фреймворк, а также модульную экосистему, чтобы заменить устаревшие языки и наш собственный фреймворк, который у нас был до этого момента.
• Оценить и узнать все об этом в свободное время.
• Реализуйте небольшой полностью оплачиваемый клиентский проект в качестве доказательства концепции с этой технологией, убедившись, что используются только действительно стандартные, общепринятые в этой экосистеме подходы, чтобы убедиться, что новые люди (имеющие предварительное знание языка , но не наш домен) разбежались.
• Найдите способы запустить новое решение в стороне от старого, не попадая снова в ловушку промежуточного программного обеспечения (т. е. слабо связанного через микросервисы или косвенно через клиентский браузер).
• Медленно и упорно убеждайте очень консервативную команду в том, что хорошей идеей[tm] является не делать новые проекты/фичи со старой структурой, а окунуться в новую. Это очень эмоционально выматывало.
• Переориентация своей роли в компании, в конечном итоге уход из этой команды и создание новой с другим углом зрения, чтобы разорвать все связи с (техническим) прошлым (частично проблема заключалась в том, что я был решателем проблем в том старом команда, и пришлось заставить их встать на ноги, уйдя).

Это была веселая поездка и, если оглянуться назад, очень успешная. Сейчас команда находится на пути к тому, чтобы оставить ту эпоху позади. Но и подход был весьма нетривиальным. Может быть, это натолкнет вас на какие-то идеи, и я полагаю, вам либо понадобится искренняя поддержка вашего старшего разработчика, либо отстраните его от этой должности (любым доступным вам способом). Сядьте и поговорите с ним подолгу, если вы в состоянии сделать это, разговор типа "где мы хотим быть через 5 лет"...

Одно замечание, которое невозможно переоценить: существующая система может быть отличной (на самом деле, вероятно, таковой она и была, чтобы просуществовать так долго), но возникнут организационные проблемы, связанные с подходом. Существует огромная проблема с документацией, общим распространением ноу-хау, фактором грузовика и очень длительным этапом обучения новых коллег. Кроме того, многие, особенно молодые разработчики, не очень заинтересованы в том, чтобы вкладывать много времени в изучение очень специфического контекста приложения, что совсем не поможет им в дальнейших проектах. Подобные причины (в моем случае) привели к описанному изменению, и открытое обсуждение этих причин устраняет личную остроту проблемы.

Дальнейшее чтение: Согласно комментариям, я, кажется, не изобрел этот процесс. :-) См. паттерн StranglerApplication, чтобы узнать больше о предмете.

Похоже, этот разработчик загнал рынок в угол. Хороший инструмент для ведения переговоров о зарплате в конце года.

ИМХО, бизнес-логике не место в трансляторе, Вы можете предложить разделить этот транслятор на слои, отделив бизнес-логику от простых методов перевода.

Будьте готовы к тому, что этот разработчик будет против;)

Кроме того, руководство может встать на его сторону, заявив о дополнительных усилиях / затратах, которые потребуются для этого.

Это может быть долгая битва, и в конце концов вы можете быть тем, кто разделяет ;)

Как я могу убедить этого разработчика (и остальную часть моей команды, которая довольно пассивно относится к такого рода проблемам), что это плохая идея?

Это не ваша задача "убедить" разработчика.

В принципе, главный вопрос здесь о вашей позиции:

• если вы просто коллега того же уровня или ниже, вы можете отметить риски для руководства. При этом сосредоточьтесь на проблемах, которые могут возникнуть в текущей системе. Тогда это их решение, а не ваша проблема;
• если вы начальник , согласуйте с другими менеджерами необходимость изменения системы программирования, а затем сообщите о решении программистам. Решение должно быть обосновано и правильно донесено (погуглите «управление изменениями») и должен быть организован переход, но тогда вы должны ожидать, что ваши подчиненные приспособятся к нему. Вы можете предложить старшему программисту какие-то бай-ины, чтобы он остался с компанией, например, повышение зарплаты, больше выходных и некоторое угождение его эго.

При работе в компании важно также развивать способность отстраняться и не заботиться. В положительном смысле! Если вы пытаетесь изменить что-то, чего больше никто не хочет менять, вас ненавидят коллеги и руководство.

Поэтому сосредоточьтесь на своей задаче. Пометить и сообщить - но пусть их принимают люди, которые фактически ответственны за принятие решений. Неважно, правы ли вы — я знаю множество людей, включая меня самого, которых уволили, несмотря на то, что они были правы — или потому, что они были правы.

Редактировать: не бросайте свою работу; у меня было неправильное представление

Вау, при первоначальном чтении поста техническое решение звучало как слой перевода, который без необходимости выполнял несвязанные задачи. Звучало очень вопреки «принципу единой ответственности»/философии UNIX, не очень связно или хорошо структурировано.

Я думаю, ключевая деталь, которую я упустил, заключалась в том, что это архаичная серверная система, выполняющая основную бизнес-логику, и я думаю, что это подразумевает, что бизнес застрял с ней по какой-то понятной причине. Спасибо комментариям и отрицательным голосам за то, что подтолкнули меня признать это.

Поскольку он древний, компания, вероятно, не хочет его трогать. Или возможно, что бизнес-логика, реализованная на уровне перевода, совершенно не связана с назначением этого основного серверного модуля.

Другие комментарии верны; документация в порядке

Решение написать слой перевода звучит разумно теперь, когда я чувствую, что у меня в голове более точная картина реальности.

То, что вы описываете, похоже не столько на новый язык программирования, сколько на новую структуру, специально написанную для этого варианта использования. Звучит как довольно стандартная инженерия в том, что я сейчас понимаю как сценарий.

Вам необходимо ознакомиться с кодом, а вам и вашим коллегам необходимо пройти обучение и получить документацию, чтобы понять систему. Было бы эффективно писать документацию о вещах по мере их изучения.