Любой прямой ответ будет экстремальным. Очевидно, что есть случаи, когда крайний срок настолько ограничен, что вы должны использовать некрасивый код, и есть случаи, когда код настолько уродлив, что его стоит пропустить, чтобы его улучшить. Что вам нужно, так это методы, позволяющие судить о том, в чем вы находитесь, и, возможно, методы, позволяющие установить реалистичные сроки, позволяющие писать лучший код.
Не сохраняйте очистку на потом. Если у вас обычно не бывает периодов, когда ничего не нужно делать, кроме рефакторинга, не существует «позже», в котором каким-то образом станет более приоритетным приводить в порядок код, чем сейчас. Процедура «красный, зеленый, рефакторинг», а не «красный, зеленый, сделай что-то совершенно другое в течение двух недель, рефакторинг». Реально вы не будете менять код до тех пор, пока в следующий раз не пересмотрите его по какой-либо другой причине, и вы, вероятно, тоже будете в срок. Ваши реальные варианты - это исправить это сейчас или оставить.
Конечно, хорошо стилизованный код лучше, чем плохо стилизованный, если вы планируете когда-либо читать его снова. Если вы планируете никогда не читать его снова, не приводите его в порядок . Отправьте первое, что проходит испытания. Но это довольно редкий сценарий, для большинства программистов это происходит примерно никогда. Игнорируя этот случай, только у вас есть детали вашего реального случая, чтобы судить, сколько стоит исправить, а сколько стоит (в будущем увеличенное обслуживание), чтобы не исправить это.
Есть некоторые вещи, которые не сложнее исправить в тот момент, когда код требует обслуживания, чем они должны исправить сейчас. Это на самом деле не очень полезно для исправления. Наиболее очевидными являются тривиальные проблемы (ошибки с пробелами и т. П.), Поэтому трудно представить, что у вас есть время задать этот вопрос, но не исправить его ;-) Для тех, которые не являются тривиальными и относятся к этому типу, тогда ОК у вас есть код, который не идеален, но вы должны быть прагматичными. Это работает, и вы в срок. Используй это.
Есть некоторые вещи, которые гораздо легче исправить сейчас, чем они будут позже, когда (а) они не так свежи в памяти каждого; (б) написаны другие вещи, которые полагаются на них или подражают им. Сейчас их гораздо важнее исправить, поэтому расставьте приоритеты. Если у вас нет времени на их устранение, то вам нужно как можно больше настаивать на более длительных сроках, потому что вы накапливаете долг в своей базе кода, который вам, вероятно, придется заплатить в следующий раз, когда вы посетите код.
Предпочтительный метод исправления кода - процесс проверки. Прокомментируйте проблемы, с которыми вы столкнулись, и отправьте их младшему для изменения . Вы можете привести примеры того, что вы имеете в виду, и оставить младший, чтобы найти все случаи в коде, к которому они применяются, но не просто закончить свой код для них. Если вы это сделаете, то вы не дадите им средств для улучшения.
Вы должны записать общие проблемы в руководство по стилю, которое гласит: «Не делай этого, делай это вместо этого» и объясняет, почему. В конечном счете, причина может заключаться в том, чтобы «сделать наш код эстетически непротиворечивым», но если вы не готовы записывать свои правила с некоторым обоснованием, то, вероятно, вам также не следует их применять. Просто оставьте каждого программиста свободным выбирать.
Наконец, остерегайтесь склонности к бесконечным изменениям. Возврат уменьшается, и вы должны учиться на опыте, где они все еще хороши. Абсолютно важно, чтобы вы сформировали реалистичное представление о том, что является достаточно хорошим, иначе вы не сможете провести переговоры, в которых вы убедитесь, что ваши сроки дают вам время для создания «достаточно хорошего» кода. Потратьте свое время на вещи, которые недостаточно хороши.