Заморозка кода, когда вы не собираетесь закончить
Я работаю над проектом, который работает в течение длительного периода времени, и мы готовимся к финальной версии продукта.
Текущие попытки тестирования обнаружили, что в системе осталось около тридцати дефектов, однако у нас нет времени, чтобы исправить все эти дефекты (я уверен, что это очень распространенная ситуация).
У меня было несколько дискуссий с разными людьми о том, следует ли продолжать замораживание кода. В настоящее время мой менеджер хочет сохранить код заморозить, однако, чтобы исправить оставшиеся критические дефекты в окне между заморозкой и выпуском (около 5 недель). Я беспокоюсь, что это не фактическое замораживание кода, а скорее всего "слякоть" кода в лучшем случае. Дефекты будут устранены группой старших инженеров, чтобы убедиться, что только критические исправления из оставшихся проблем действительно прорабатываются, однако, на первый взгляд, критические проблемы, по-видимому, составляют около двух третей от общего числа оставшихся дефектов.
Я понимаю, что замораживание кода представляет определенные психологические преимущества для разработчиков, такие как предоставление фиксированной даты окончания всей работы. Однако мой менеджер открыто обсуждает исправления, которые произойдут "после" замораживания, но это полностью отрицается.
Мне было интересно, имел ли кто-либо еще подобный опыт или мог бы дать мне несколько советов о том, как лучше всего справиться с этой ситуацией. Я начинаю думать, что никто не замораживает их кодовую базу в тот день, когда они говорят, что собираются.
Мы планируем ветвление из ствола в subversion в день замораживания кода, чтобы удостовериться, что финальная версия продукта изолирована от ствола разработки, поэтому я не слишком беспокоюсь о проблемах изменений, влияющих на версию выпуска продукта.
Спасибо,
Айдос
РЕДАКТИРОВАТЬ: я полагаю, что лучший способ объяснить мышление моих менеджеров заключается в том, что на самом деле это не замораживание кода, а скорее замораживание функциональности, однако, поскольку вся функциональность была в продукте в течение некоторого времени, я думаю, что это грубое упрощение.
РЕДАКТИРОВАТЬ 2: Я хотел бы поблагодарить всех за их отличные ответы, к сожалению, я могу отметить только один как полезный, хотя до сих пор все 7 ответов были невероятно полезными.
7 ответов
Я думаю, что фактическое замораживание кода невозможно. Обычно, когда происходит замораживание кода, происходит более интенсивное тестирование. Тогда что? Все найденные проблемы - документы для следующего выпуска? Что если вы обнаружите проблему настолько плохой, что ключевая функция не будет работать?
У вас должен быть способ справиться с каждой проблемой / ошибкой по мере их появления. Поскольку большинство хороших разработчиков ленивы (мнение), ветвление \ тегирование и принуждение разработчика объединять или копировать свои изменения в 2 места остановят большинство из них попытки внести изменения, которые не являются необходимыми на 100%.
С этого момента вам нужно разобраться с каждой ошибкой / проблемой, когда они появятся. Каждому из них придется взвешиваться в соответствии с: какова проблема, какова проблема, сколько дней до окончательного выпуска для повторного тестирования. Соотношение затрат и выгод для каждой проблемы. Только тогда может быть принято разумное решение.
Это балансирование.
С одной стороны, приятно иметь период замораживания кода, но с другой стороны, никто не заинтересован в том, чтобы вы поставляли продукт с критическими проблемами, достаточно большими, чтобы заставить ваших клиентов уйти.
Если проблемы достаточно серьезные, никакое замораживание кода не помешало бы мне их исправить, если бы это был мой продукт.
Удачи!
В этой ситуации я мог бы думать о том, чтобы избежать проблем,
If bug not fixed
you will be in trouble;
if codefreeze === true
fix your local version;
update the dev version on SVN;
goto manager;
state the severity of the bugs;
follow her direction because she already got a plan;
Замораживание кода обычно означает, что все известные на данный момент ошибки не будут исправлены. (И, надеюсь, само собой разумеется, новые функции не добавляются). Если при замораживании обнаруживаются ошибки, они добавляют новую информацию, и, в зависимости от вида сортировки, может потребоваться временно "разморозить" код, чтобы исправить ошибку. Надеемся, что изменения, сделанные во время замораживания кода, будут тщательно проверены.
Предполагается, что каждое третье исправление ошибки вносит новую ошибку случайной серьезности. Замораживание кода дает вам время "преобразовать" неизвестные ошибки (переменной степени серьезности) в известные ошибки известной серьезности.
Истинное "замораживание кода", при котором ничего нельзя изменить, было бы бессмысленным - что, если вы нашли серьезную ошибку? Вы не могли просто проигнорировать это.
AFAIK "Code Freeze" на самом деле означает "New Code Freeze". Целью этого является стабильность для отладки, исправления ошибок не включаются в зависание, потому что они не являются новым кодом, но исправляют старый код.
Мы предпочитаем термин "вниз инструменты", когда вы действительно имеете в виду руки от кода.
В нашем случае мы разветвляемся, когда запускаем альфу (основная ветвь остается в неактивном состоянии некоторое время) и замораживаем код (больше не фиксируем) прямо перед первой отправкой клиенту, когда мы решили, что мы закончили исправление дефектов.
В прошлом я работал в компании, где замораживание кода действительно означало замораживание функций (больше никаких добавленных функций) и ветвление. Затем мы работали над дефектами.
Я бы не назвал то, что вы описываете замораживанием кода, а скорее создание ветки упаковки, где вы сгладите детали и подготовите свой код к выпуску.
Является ли ваше замораживание заморозкой кода или заморозкой функциональности? Это не на 100% ясно из вашего вопроса.
Сказав это, я бы согласился с приведенными выше комментариями о ветвлении и слиянии. Это позволяет вам и вашим разработчикам использовать ветку для исправления известных вам ошибок и ошибок, которые появятся в течение следующих нескольких недель. Затем он позволяет вам интегрировать любую критическую ошибку, исправленную обратно, в основную (замороженную) строку контролируемым образом.
Таким образом, можно надеяться исправить самые серьезные проблемы, не создавая слишком много новых дефектов. Интеграция и регрессионное тестирование здесь важны.