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

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

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

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

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

Какие требования к сроку? Сосредоточьтесь на тех. Соберите как можно больше из них. Постарайтесь определить, какие из них являются наиболее важными, и сделайте их в первую очередь.

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

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

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

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

Недавно я применил на практике один из лучших советов: если люди не слушают, перестаньте говорить. Моя природа, чтобы быть более непреклонным, но это только имеет неприятные последствия.

ПРИМЕЧАНИЕ. ОП является ведущим разработчиком внешнего интерфейса по комментариям.

Какие решения вы уполномочены принимать? Уточняйте это у вашего менеджера в электронном письме. Можно ли заменить по частям? Не ругайте других разработчиков!

Ваш босс, возможно, слишком много раз слышал слово «переписать» и видел, как оно терпит неудачу. Попробуйте другой подход — установите стандарт кода, который ваш босс может просмотреть. Стандарт кода определяет шаблоны для представлений, моделей и т. д. Например, MVVM.

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

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

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

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

Вы, вероятно, унаследовали некоторые сроки. В краткосрочной перспективе ваша задача — соответствовать им, даже если код не идеален.

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

Наконец, если вы чувствуете, что не можете эффективно выполнять свою работу, пора искать другую работу.

РЕДАКТИРОВАТЬ

Частью вашей работы является установление и обеспечение соблюдения стандартов кодирования, а также информирование руководства о реальных ожиданиях. Даже с нетехническим менеджментом вы можете объяснить стандарты кодирования.

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

Вы можете привлечь команду, позволив ей помочь разработать новый процесс. Частью лидерства является вовлечение всех в процесс. Используйте конвейер CI/CD для принудительного просмотра кода и, возможно, сделайте первые несколько в группе, чтобы все увидели стандарт.

Я уже был на вашем месте. Мне сказали работать над веб-сайтом с ужасной кодовой базой и сдать его до истечения срока. Вот что сделала наша команда,

1. Мы завершили первоначальную поставку с неверным кодом.
2. Всякий раз, когда появляется новая функция, мы говорим: «Эта функция не будет хорошо работать с текущей архитектурой» или «С текущей архитектурой это займет как минимум на x больше дней» и покупают дополнительное время. Затем мы использовали это дополнительное время для рефакторинга кода, связанного с текущим спринтом.
3. Через пару спринтов мы выполнили все основные задачи и немного улучшили код. Затем я убедил руководство и клиентов выделить 2 месяца на полный рефакторинг кода в соответствии с современными стандартами. Я сказал им, что это поможет нам легче вносить изменения и быстрее развертывать обновления (что было правдой).

Теперь у нас есть код, соответствующий современным стандартам, которые нам нужны.

Будучи менеджером, я часто сталкивался с синдромом «изобретено не здесь»; разработчики программного обеспечения настаивали на том, что некоторый код, написанный коллегой, был нестандартным и нуждался в переписывании, а затем они использовали несколько недель сжатого проекта, чтобы сделать именно это.

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

Для меня вы просто открываете для себя, что значит работать в компании.

Есть требования, сроки,... И не всегда можно делать то, что хочется.

Вы не сказали, являетесь ли вы новичком в этой компании (поэтому не успели доказать, на что вы способны). Возможно, back-end парень — это кто-то, кто работает в компании долгое время и спас их от предыдущих неприятностей.

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

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

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

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

Если вы намерены остаться там, один из способов добиться перезаписи — это небольшие рефакторинги. «Маленький» — это относительный термин, но я бы постарался, чтобы они были как можно меньше (нелегко, если плохой код тесно связан). Для каждой функциональности, которую вам нужно сделать, рефакторинг всего, к чему вы прикасаетесь, пока вы это делаете. Это будет сложнее, чем создавать что-то с нуля, но вы будете предоставлять функциональность постепенно, а не очищать существующий код (рефакторинг — очень известная часть разработки программного обеспечения). Это также отличный навык, который немного отличается от написания хорошего кода. Конечно, убедитесь, что требования, которые вы реализуете, небольшие и проверяемые (главным образом, но также см. INVEST), чтобы вы могли сделать рефакторинг относительно небольшим. Напишите модульные тесты для требования, рефакторинг реализующего его кода, чтобы его можно было протестировать. И не пытайтесь сделать все правильно с первого раза, просто сделайте лучше. У вас будет больше возможностей.

Мой взгляд на это.

Надежность: 2 года смешанного опыта в той же области.

Некоторые факты :

1. Вы кажетесь намного лучше кодера, который был до вас. (Возможно, он провел в компании немного больше времени, чем вы, или намного больше, я не знаю, и, следовательно, он мог иметь больше упомянутого вами «уважения»).
2. Вы можете переписать весь код за несколько дней. (скажем так, с гораздо лучшим качеством).
3. Компания инвестировала в вас так же, как и в него. Заплатив ему за его работу, вы платите за вашу работу.
4. Другой человек потратил время на написание кода, и компания рассматривает это как «инвестицию», и поэтому, когда вы переписали код: они восприняли это как оскорбление.

Поправьте меня, если я где-то ошибаюсь до сих пор.

Что, я думаю, вы могли бы сделать (аналогичный опыт):

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

2. Вы выполняете свое требование, и всякий раз, когда вам нужно включить зависимость от его компонентов (сделайте выбор, хотите ли вы сделать вариант 1), если нет, просто используйте его компонент и «выполните работу», потому что в конце, более высокий уровень руководству на самом деле наплевать на "качество", так как они заняты конвертацией требований в деньги для нас. Я не виню их.

3. Вы пишете тестовые примеры для его кода, где бы он ни ломался (просто выполните эту часть исправления), а затем продолжаете выполнять свои требования.

4. (Упоминается другими) переделать всю кодовую базу. Есть много причин, по которым я бы не стал этого делать. Во-первых, вам платят за то, чтобы вы делали «новую работу», а не переделывали «старую работу», а также делали «новую работу». Компания несет ответственность за наличие политики или практики для таких проблем (вы сделали свою часть работы, упомянув проблему и предложив решение). Но я думаю, что они не доверяют/не хотят рисковать, прося вас переделать работу и закончить ваше требование. Естественная человеческая склонность, но я не буду их винить. Вполне возможно, что вы застрянете, не сдержите свое слово, что также нанесет негативный удар по вашему имиджу.

Я бы предложил придерживаться варианта 1: (обычно это заканчивается новым требованием, а не временем для улучшения, но приоритет есть приоритет). Вам платят за то, что пользователь получает приложение, а не за то, насколько хорошо мы пишем код (это играет роль в долгосрочной перспективе, как сейчас, но это то, что руководство должно выяснить или напомнить). Не берите стресс на себя.

Некоторые советы, которые я хотел бы, чтобы вы улучшили (будьте непредвзяты при чтении)

• Постарайтесь улучшить ваше общение. Очевидно, у вас хорошие коммуникативные навыки, вы объяснили здесь хорошую ежедневную проблему разработчика. Я пытаюсь сказать, что вы можете стать более убедительным.
• Подумайте с точки зрения других людей:
  • Менеджер: У меня есть сотрудник, который просит у меня разрешения переделать старую работу и переделать за 5 дней, по сравнению с «неспособностью» выполнить новую работу за 5 дней.
  • Парень, который написал код: он перепишет этот код, и новости распространятся, и люди будут думать обо мне хуже??
  • Ты: Я хочу, чтобы все было идеально! Я изменю код и сделаю его идеальным.
  • Пользователь: Когда я получу свой продукт? Я заплатил за это!!!

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

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

PS У меня был платежный репозиторий, от которого нужно было зависеть :) Переделывать не стал. (Не мои проблемы :)

Переписать

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

Лучше просить прощения, чем спрашивать разрешения.

Это смелый принцип, и он может в конечном итоге привести к вашей [профессиональной] смерти. Но во многих случаях это работает. Главное, чтобы вы давали результат. В конце концов, никого, кроме вас, не волнует, хорош код или нет. Их заботит только то, смогут ли они получить кредит на результаты бизнеса. Пока они нажимают на кнопки, а сайт делает то, что они ожидают, им все равно, как он питается. Скорее всего, бывший разработчик уже забыл о коде и был бы рад никогда больше к нему не прикасаться. Другие разработчики, вероятно, просто подлизываются к старшему, потому что это хорошо для их карьеры.

Стратегия

Очевидно, что вам нужно поддерживать 100% существующего функционала. Не ломайте ничего из того, что уже работает, иначе вы будете просить гораздо больше, чем прощение. В противном случае замените каждую плохую деталь, которую вы можете сойти с рук, даже если это означает немного отодвинуть крайний срок. Вы действительно заработаете очки, если сможете добавить надежности или даже функциональности своему переписыванию. Надеюсь, вы сможете определить некоторые крайние случаи, когда старый код дает сбои, и задокументировать репродукции для него в виде модульных тестов (которые вы зарегистрируете). Затем вы исправляете их с помощью рефакторинга.

Не говорите никому, что вы делаете все это. Менеджеры, которые сказали бы вам остановиться, недостаточно разбираются в коде, чтобы иметь здравый смысл. У разработчиков, которые могут сказать, что вы делаете, недостаточно здравого смысла, чтобы распознать плохой код. В конце концов, все, что имеет значение, — это бизнес-результаты. Если другие разработчики, которым приходится работать с вашей кодовой базой, что-то говорят, спросите их, лучше или хуже ваша версия, чем старая. Если они говорят, что стало лучше, значит, их работа упростилась, а у вас появился новый союзник. Если они говорят, что стало хуже, попросите их объяснить, почему, но не спорьте с ними. Вместо этого углубитесь в каждую причину и заставьте их обосновать ее техническими аргументами, а не стилем или «мы всегда так делали». Всегда идите вперед, задавая вопросы, и думайте о сценариях, которые делают их версию менее желательной.

Безопасность

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

Управление вверх

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

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

Все, что вы говорите, должно быть коммерческим аргументом, который ваш босс может использовать на встречах с коллегами и их боссом, чтобы получить бонусы/повышения/повышения по службе. Вам нужно продавать свои улучшения как то, что они могут перепродать по личной наценке. И если все это их не тронет, извлеките электронные письма от коллег-клиентов, восхваляющих улучшенный пользовательский интерфейс. Затем скажите: «Послушайте, я знаю, что я нажал на эти изменения, и я полностью готов отменить их. Но, э… некоторые клиенты уже знают, что будет дальше, и они могут задать несколько сложных вопросов. если мы просто добавим больше старого пользовательского интерфейса. Итак... скажите мне, когда вы хотите, чтобы я нажал кнопку отката, и я буду счастлив сделать это. И мысленно просто скажите: "Шах и мат!"

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

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

Вы упомянули, что у вас гораздо более чистая версия, обеспечивающая 80% функциональности. Что вы не упомянули, так это последствия для бизнеса предоставления только 80% функциональности к крайнему сроку, а также вы не упомянули, какие преимущества для бизнеса дает более чистый код в долгосрочной перспективе. Если, например, заказчики будут сильно расстроены недостающими 20% функционала и проект после этого вряд ли сильно изменится (будь то из-за запросов на изменение функционала или запросов на исправление ошибок), то это было бы вполне разумно, с точки зрения бизнеса, чтобы предоставить то, что вы получили от исходного кода, и не слишком беспокоиться о затратах на будущие изменения.

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

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

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

1. Делай то, что тебе говорят
2. Поговорите с первоначальным разработчиком и узнайте остальную часть истории
3. Ищите другую работу

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

В конце концов, вы не единственный, у кого были разногласия с руководством, где теперь эти зацепки.

Обоснование DRY, GRASP и т. д. также является частью этого. Вместо этого объясните с точки зрения влияния на бизнес краткосрочных и долгосрочных возможностей.

CYA — записывайте простые заметки с каждой встречи, замедляйте обсуждение, чтобы записывать их по ходу дела, общий экран на удаленных встречах отлично работает. (Держите копию под рукой на тот случай, если вас внезапно вызовут, чтобы объясниться)

Не занимайте чью-либо сторону, давайте объективные рекомендации, выраженные в компромиссах.

Но никогда не обвиняйте другого разработчика.

Существует множество принципов создания единственно-верного программного обеспечения, перестаньте им верить.

Вы сказали, что среди клиентов есть "громкие имена". Когда работа должна быть выполнена непрактичным или технически невозможным способом, потому что босс или клиент «важны», начните гуглить «враждебная рабочая среда».

Что вы должны сделать / должны были сделать:

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

Поскольку существует крайний срок, «приемлемое» качество — это то качество, которого едва хватает, чтобы уложиться в срок.

Если вы не можете получить желаемое качество в установленные сроки, что-то должно дать результат: либо качество, либо сроки. Именно здесь вы разговариваете со своим менеджером, ставите его в известность о фактах и ​​выясняете, насколько важен крайний срок. Ваш начальник может сказать: «Если вы не уложитесь в срок, то последний месяц будет вашей последней зарплатой». Или он может сказать: «Перевыполнение срока на четыре недели — это нормально, кроме того, у компании будут проблемы».

Как только вы узнаете «настоящий» крайний срок, вы решаете, что вам нужно сделать, чтобы уложиться в этот срок без неоправданного риска. Между крайним сроком и следующим результатом может пройти время, чтобы улучшить код.

PS. Пропуск срока может стоить вашей компании значительных денег, потому что они подписали какой-то контракт. Теперь возможно, что у вас крайний срок 31 марта, и если вы сдадите в этот день с десятью тысячами ошибок, вашей компании не придется платить за нарушение срока, в то время как сдать 1 апреля без ошибок очень, очень дорогой. В реальной жизни это не будет так экстремально, но бывают случаи, когда сроки имеют свои правила (а в других случаях они совершенно бессмысленны). Вы должны знать, что, прежде чем вы сможете предпринять какие-либо действия.

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

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

Здесь у вас совершенно неверный подход.

Если бы вы провели рефакторинг кода всего за 2 дня, вы могли бы только что закончить рефакторинг, выпустить более качественный продукт и при этом уложиться в срок.

Рефакторинг всегда можно продать как "улучшение", т.е. "я улучшил код - теперь он реактивный! :)"

Таким образом, вы получаете то, что хотите (технические улучшения), и ориентируетесь в политической сфере, никого не расстраивая.

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

Хотя, если вы хотите попробовать что-то новое, есть и третий способ.

Учитывая, что это фронтенд и ты единственный Front End Developer в компании, а если есть время - делай что надо и параллельно делай новый UI.

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

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

Будь готов к тому, что тебя НЕ поздравят, когда они поймут, ты :)

Насколько вы заботитесь о работе и насколько реально важна эта функция? Сколько вы будете поддерживать его в будущем? Насколько точен ваш график полной перезаписи (МНОГИЕ разработчики недооценивают здесь, часто не понимая реальной сложности кода). В итоге есть 3 варианта:

1) Разберитесь с этим. Это можно сочетать с стремлением улучшить его в будущем.

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

3) Скажи, к черту, и делай это в любом случае.

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

За свою карьеру я сделал все 3. Это действительно зависит от обстоятельств.