Неправильное использование термина “Код Замораживания”, [закрытый]

Я не слишком разбираюсь в этом?

Да.

Ну, наверное. На самом деле, вам следует дважды подумать, прежде чем вносить какие-либо изменения в код после замораживания. Ошибки должны пройти некоторый тест на серьезность, тем более что исправление требует потенциально опасных изменений в кодовой базе или делает недействительным проведенное тестирование. Если вы не делаете то , то да, вы просто обманываете себя.

Но если вы не собираетесь исправлять какие-либо ошибки, то замораживание кода бессмысленно: просто соберите и отправьте его.

В конечном итоге важно то, что вы все понимаете, что подразумевается под ярлыком, а не сам ярлык. Один большой счастливый Шалтай-Болтай ...

На самом деле я думаю, что они более правильны в своей интерпретации. Для меня замораживание функций означало бы остановку внедрения новых функций, но функции, находящиеся в настоящее время в разработке, могут продолжаться, или вы можете запланировать некоторые работы по рефакторингу для устранения технического долга без создания новых функций. Замораживание кода останавливает все новые разработки, включая рефакторинг - единственный разрешенный новый код - это исправлять ошибки, обнаруженные во время QA. Последнее, похоже, и делает ваша команда.

Да, это переоценивается. Да, это неправильное название.

Если код не сломан / беспорядок, вы не трогаете его, а если это так, вы исправите его. Это точно такая же ситуация, как если бы вы не замораживали код. Да, антипаттернами являются «замораживание требований» или «разрыв интеграции». Это момент, когда следует прекратить включение новых функций в следующий выпуск, что имеет большое значение с точки зрения продаж / маркетинга / поддержки клиентов. Но им, наверное, стоит назвать это «пререлизом».

Что должно случиться, так это то, что всегда есть несколько выпускаемых версий системы в системе контроля версий, и компания выбирает одну для отправки.

Экономичное название для "замораживания кода" - " отходы "

Это надежно сообщит вам, пуст ли конкретный словарь:

function isEmptyDictionary(dict:Dictionary):Boolean
{
    for each(var obj:Object in dict)
    {
        if(obj != null)
        {
           return false
        }
    }
    return true;
 }

Обратите внимание, что вам нужно выполнить проверку obj! = Null - даже если вы установили myDictionary [key] = null , он по-прежнему будет повторяться как нулевой объект, поэтому обычный цикл for ... in в этом случае работать не будет. (Если вы всегда используете delete myDictionary [key] , все будет в порядке).

Следовательно, скраммеры или, по крайней мере, скрам-мастера и / или проекты динамика схватки требует от менеджеров / архитекторов модульности ... модульность недостаточно; но детализировать проект.

Вы должны детализировать ваши модули до нужного размера и предоставить спецификацию контрактного интерфейса для каждого, чтобы изменения в модуле управлялись внутри модуля. Если ваш модуль сам по себе или из-за зависимости других модулей не может удовлетворить контрактный интерфейс, вам необходимо заморозить код, чтобы вы могли транслировать версию 1 контрактного интерфейса, чтобы другие команды могли продолжить работу, хотя и с меньшими, чем ожидалось, функциями. в следующем общем выпуске продукта.

Замораживание кода - это замораживание кода.

Если ваш код зависает, это означает, что ваш мастер схватки и архитектор продукта не общаются или не выполняют свою работу должным образом. Возможно, нет смысла пытаться внушить или согласиться с вашим руководством, что они используют некую отраслевую причуду, называемую гибким программированием . Либо руководству необходимо нанять архитектора и мастера схватки, которые смогут разработать и детализировать проект в рамках навыков команды, а также ожиданий клиентов и технологических ограничений проекта.

Я думаю, что есть элементы управления и их мастера схватки, которые не осознают, насколько важен хороший архитектор даже для среды схваток, и отказываются его нанять. Хороший архитектор, который умеет слушать команду и работать с ней, неоценим для процесса схватки, потому что он / она должен постоянно адаптировать архитектуру к меняющейся гранулярности и ожиданиям.

Я также думаю, что есть элементы управления и их мастера схватки, которые принадлежит к другому спектру вселенной программирования из-за неудачного опыта с более длинными циклами разработки, такими как водопад, которые поэтому думают, что scrum предназначен для создания продукта в течение месяца, и поэтому тщательное изучение эффектов кросс-модулей на самом деле не требуется. Они садятся, мочат пальцы в воздухе и делают отличный спринт.

Если ваша команда испытывает частое оттаивание кода, зависает, вам, ребята, может потребоваться заморозить код всего проекта и переосмыслить свою стратегию, чтобы увидеть, что причина кроется в вашем отказе определять контракты модулей, которые соответствуют степени детализации модулей. Или вы, ребята, вообще определяете контракты модулей для того, чтобы функции застрявшего модуля могли быть в настоящее время разрежены, чтобы позволить другим командам или модулям продолжить работу.

У вас есть стратегия UML, которая помогает в обнаружении предполагаемых функций проекта release и позволяет вам увидеть эффекты зависшего модуля, а затем увидеть, на каком модуле нужно сосредоточиться, чтобы достичь желаемого уровня выпуска продукта? Посещаете ли вы схватки и спринты, и у вас нет изображения UML, чтобы показать, насколько вы продвинуты или опаздываете, так что вы просто идете вперед, счастливо или вслепую? Или ваш скрам-мастер сказал бы комнате «да» или «нет», хм ... этот модуль кажется важным - на самом деле не имея четкого представления о том, какие модули являются наиболее связанными с выпуском продукта.

Замораживание кода выпуска продукта достигается постепенным замораживанием модулей. Как только модуль завершен, проводится тестирование продукта, чтобы убедиться, что модуль удовлетворяет условиям контракта и этот модуль заморожен, например, версия 2.1. Несмотря на то, что работа над этим модулем для 2.2 продолжается, проект в целом должен зависеть не от 2.2, а от 2.1. Стратегия состоит в том, чтобы свести к минимуму количество модулей, контракты которых необходимо разморозить при тестировании выпуска продукта, и если выпуск продукта должен уменьшить его функции. Если прогрессивное модульное замораживание не помогает вашей команде разработчиков ...

, когда мы кодируем замораживание, репо заблокировано, надеюсь, все исправлены ошибки, которые вы намеревались исправить, и вы, тестировщики, пройдете еще один этап тестирования перед тем, как переходить и собирать в производственную среду. если для этой итерации запланированы какие-либо нерешенные ошибки, лиды будут дышать вам в шею, пока она не будет закрыта или не будет сочтена некритичной и отложить итерацию. так что да, он действительно заморожен.

Хотя «Замораживание кода» может иметь туманное значение и, как уже упоминалось, более уместно «Замораживание функций» при рассмотрении отдельных проектов / выпусков, оно ДЕЙСТВИТЕЛЬНО имеет место в более крупном, интегрированное развертывание, при котором другой объект отвечает за упаковку и / или развертывание нескольких выпусков программного обеспечения от разных команд. «Заморозка кода» дает им время, чтобы убедиться, что среды выровнены и все пакеты учтены. «Заморозка кода» также означает, что ничего, кроме «остановки показа» изменений, не происходит. Все остальное будет обработано в следующем выпуске обслуживания.

В идеальном мире тестирование по сценарию было бы завершено до этого момента, и это было бы время, отведенное для развертывания любых последних исправлений и повторного тестирования. Я еще не видел, чтобы это происходило ни в одной "глобо-корпорации". Тестировщики (бизнес) тестируют до и даже после развертывания, и «замораживание кода» становится для них сигналом, чтобы активизировать свои усилия и регистрировать все, на чем они сидели. В некоторых случаях для них это сигнал НАЧАТЬ тестирование.

На самом деле, «Code Freeze» - это просто деловой разговор, означающий «Вот и Тигерс». ; -)