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