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

Question

[LookAtIos]

Не так давно начал работать на проекте (бек + фронт). Столкнулся с низкокачественным кодом, который раз за разом наслаивается. Если на беке как-то могу все исправлять, что мне не нравится, добавляю документацию, то на фронте крайне много варнингов, ничего не документировано, а повторяющийся код дело обычное. Из-за этого файлы раздуты до нескольких тысяч строк. Исправлять что-либо нельзя, т.к. работает, что делать?

Comments

[Константин Нагибович]

У вас какая роль в команде?

[Максим Федоров]

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

[Одиночка Айс]

Максим Федоров, а там глядишь и восстание поднимут все)

Answer 1

[Рональд Макдональд]

Ну, коль вы сеньор, то взять и всё исправить. Ах, вы не сеньор? Ну тогда не умничать.
Простити за грубость. Работает - не трогай.

Comments

[Максим Федоров]

Работает - не трогай

А как-же правило бойскаута "Оставь после себя лучше, чем было до тебя"? :-)

[Дмитрий Осипов]

Максим Федоров, +1
Не нужно сразу бросаться с шашкой и все править. Понемногу то тут, то там вноси исправления.

[AlexHell]

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

Answer 2

[Алексей Николаев]

Забить и получать бабос

Answer 3

[Иван Шумов]

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

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

Если все грамотно сделать и расходы соизмеримые для бизнеса, а плюсов достаточно то идею поддержат. Если нет то см.п.1

Answer 4

[Игорь Воротнёв]

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

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

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

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

Comments

[Иван Шумов]

Вот тут уже перебор. Настолько большую работу не требуется проводить

[Игорь Воротнёв]

Иван Шумов, Зависит от конкретной компании и ее размера, количества отделов вверх и ЛПРов, размера проекта и еще многих параметров. Поделился личным опытом из крупной международной компании где мы с командой выступаем разработчиками сайтов компании и поддерживаем их, по long term контракту. Разговоры о необходимости рефакторинга велись с нашей стороны в течении 2х лет - эффекта ноль. Одна качественная презентация, для которой были собраны нужные люди менее чем за час позволила принять все необходимые решения, вдогонку переписать и переоформить контракт поддержки, который был существенно расширен и добавлены часы на рефакторинг.

[Иван Шумов]

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

[Игорь Воротнёв]

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

[Игорь Воротнёв]

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

[Иван Шумов]

Игорь Воротнёв, я про автора, а не тебя) случаи абсолютно разные

[Иван Шумов]

Игорь Воротнёв,

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

Б - бюрократия

[Игорь Воротнёв]

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

[Игорь Воротнёв]

Иван Шумов,

я про автора, а не тебя) случаи абсолютно разные

ну я нигде в тексте не видел, что он джун в в лодке из fortune 500 :)
человек спросил совета, я привел пример как разговаривать с не-разработчиками их языком. Масштабы разные, суть одна.

[Иван Шумов]

Игорь Воротнёв, если лид и CTO это допустили то под их руководством лучше не находиться - ничему хорошему не научат. Не задача младших совсем

[Иван Шумов]

Игорь Воротнёв,

ну я нигде в тексте не видел, что он джун в в лодке из fortune 500 :)
человек спросил совета, я привел пример как разговаривать с не-разработчиками их языком. Масштабы разные, суть одна.

достаточно посмотреть в профиль человека

[Игорь Воротнёв]

Иван Шумов, а вот с этим, пожалуй, полностью соглашусь. Я бы с такого корабля бежал еще до крыс.

Answer 5

[vaservaser]

Уволиться

Answer 6

[Сергей Горностаев]

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

Answer 7

[iMaximus]

Правильный ответ это комбинация уже данных выше ответов (Забить и получать бабос || Уволиться)

Answer 8

[ApeCoder]

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

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

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

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

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

Как-то так

Answer 9

[vanyamba-electronics]

Напиши оптимизатор.