Задать вопрос

Как смириться с тем, что нельзя убирать плохой код на проекте?

Не так давно начал работать на проекте (бек + фронт). Столкнулся с низкокачественным кодом, который раз за разом наслаивается. Если на беке как-то могу все исправлять, что мне не нравится, добавляю документацию, то на фронте крайне много варнингов, ничего не документировано, а повторяющийся код дело обычное. Из-за этого файлы раздуты до нескольких тысяч строк. Исправлять что-либо нельзя, т.к. работает, что делать?
  • Вопрос задан
  • 1039 просмотров
Подписаться 4 Простой 3 комментария
Решения вопроса 1
Zoominger
@Zoominger
System Integrator
Ну, коль вы сеньор, то взять и всё исправить. Ах, вы не сеньор? Ну тогда не умничать.
Простити за грубость. Работает - не трогай.
Ответ написан
Пригласить эксперта
Ответы на вопрос 8
Забить и получать бабос
Ответ написан
Комментировать
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Смириться. Рефакторинг редко входит в roadmap проектов у организаций и причин этому несколько:
- работает не трогай (сломаешь еще чинить придется)
- зачем платить за тот же результат (редко кто кроме разработчиков понимает зачем нужен рефакторинг)

Если смириться не получается:
- сделай оценку изменений
- составь списк плюсов и рисков этого мероприятия
- выстави это принимающим решения людям в организации

Если все грамотно сделать и расходы соизмеримые для бизнеса, а плюсов достаточно то идею поддержат. Если нет то см.п.1
Ответ написан
Комментировать
HeadOnFire
@HeadOnFire
PHP, Laravel & WordPress Evangelist
Сделать презентацию для бизнес-руководства, нарисовать в начале большую страшную проблему и графики роста стоимости поддержки и обслуживания, падения конверсии и тд. Дальше слайды с перечислением пользы рефакторинга. Например - внедрение новых фич сократится по времени и себестоимости на X и Y, изменения существующих фич - на 5X и 5Y. Себестоимость поддержки и развития проекта понизится в X раз, себестоимость тестирования снизится на Y. Нагрузка и расходы на сервера снизятся на X, скорость загрузки страниц увеличится на Y, показатели Bounce Rate снизятся до Z, конверсия вырастет минимум на X и тд и тп. Хорошо, если презентацию вместе с бизнесом будет смотреть маркетинг - для них такие штуки важны тоже. Бизнес понимает конкретные цифры, говнокод как философский концепт - не понимает.

Ну и главное - презентация должна содержать конкретное предложение. Что-то типа "на рефакторинг понадобится Min-Max часов, но чтобы не останавливать работу, мы его делаем параллельно на 3м приоритете после баг/секюрити фиксов и критических новых фич, выделяя на это X часов в неделю."

ЛПР должен понимать, что бизнесу это в итоге будет выгодно а на текущие задачи это заметно не повлияет.

зы: это конечно все слегка преувеличено для наглядности, но суть думаю понятна.
Ответ написан
@vaservaser
Уволиться
Ответ написан
Комментировать
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Часто и много демонстрировать к фронтендерам пренебрежение, по случаю делать снисходительные заявления типа "Ну ничего, когда-нибудь и вы станете настоящими программистами" и "Да я понимаю, не всем дано". На любые возражения искренне удивляться и спрашивать "А чего вы обижаетесь, у вас же пёстрые логи и говнокод вперемешку со спагетти-кодом." Не факт, что поможет, но хотя бы весело. Главное не перегнуть палку с критикой, она должна выглядит искренне доброжелательной.
Ответ написан
Комментировать
@iMaximus
Правильный ответ это комбинация уже данных выше ответов (Забить и получать бабос || Уволиться)
Ответ написан
Комментировать
ApeCoder
@ApeCoder
Прочитать книжку "эффективная работа с унаследованным кодом" и подумать за счёт чего достигается уверенность в том, что вы ничего не сломаете при рефакторинге.

Если у вас нет чего-то из того что ниже постараться это внедрить:
- автоматические тесты
- continuous integration
- code review или парное программирование
- автоматические средства рефакторинга
- статическая проверка (typescript, например)

Начать анализировать статистику по причинам возникновения ошибок - часто она в плохом коде.

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

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

Как-то так
Ответ написан
Комментировать
@vanyamba-electronics
Напиши оптимизатор.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы