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