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