Если вам «прилетел» плохой код, начните с прямого вопроса заказчику, насколько ему важно сохранить код в текущем состоянии. Если очень важно, можно попытаться доступно и без лишних эмоций объяснить минусы этого решения. В частности, донести до клиента, что низкое качество кода неизбежно увеличивает расходы на дальнейшее развитие продукта. Какие аргументы можно привести? 1. На то, чтобы разобраться с кодом, уйдет неоправданно много времени. Простой пример: команде достался по наследству функционал, работающий на четырех переменных и особой математической магии. Нужно было поменять в нем одно условие. При хорошем коде эта работа заняла бы 30 минут, но программист убил 10 часов, потому что ему пришлось практически побуквенно разбираться, как все это работает. 2. При сохранении некачественного кода в продукте возникнет так называемый «фактор автобуса»: разобравшийся в проекте специалист станет единственным носителем знания по нему. Если он уволится (или попадет под автобус, как следует из названия этого явления), владелец кода опять понесет все убытки, связанные с вводом новых программистов в проект. Также не помешает дать клиенту точную оценку затрат на рефакторинг. Если даже после этих аргументов заказчик не согласится с тем, что старый код безопаснее облить бензином и сжечь, придется работать с тем, что есть.

Для начала нужно убедиться, что код действительно плох: не исключено, что он сложен для понимания из-за специфики предметной области. Например, код DSP-контроллера чрезвычайно сложно читать без релевантного опыта. Для верности стоит посоветоваться с коллегами, более осведомленными в данном вопросе. Если код действительно плохого качества, важно понять, можно ли закрыть на него глаза. Толерантность к чужому коду — важный скилл. Если нельзя, стоит определить: — Какова трудоемкость переписывания кода (оценка трудоемкости — это сложно, есть риск просчитаться на целые месяцы); — Хорошо ли ты понимаешь код, который планируешь переписать; — А сможешь ли ты написать более качественный код; — Если проблемный код не покрыт тестами (а так, скорее всего, и будет), то есть риск, что новый код создаст регрессию в проекте. Готов ли ты взять на себя ответственность за результат? На заметку: переписанный код в лучшем случае будет оценен по достоинству вашими коллегами, но не начальством. Другими словами, премию и прочие плюшки за это не жди. Если все же остается желание переписать код, могу дать несколько советов: — Максимально декомпозируй код — чем меньше кусок переписываемого кода, тем лучше. — Используй методы рефакторинга, покрой код тестами, если их нет. — Не трать много времени на переписывание, оно не должно мешать основной работе.