Рефакторинг и параллельные ответвления разработки
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
14 ответов
Я считал бы обязанностью разработчика обслуживания ответвления объединить соответствующее изменение в текущее состояние соединительной линии. Существует несколько возможностей:
- код в соединительной линии не изменился, и патч применяется без конфликта.
- код в соединительной линии изменился, и патч применяется, но с ручным необходимым слиянием.
- код в соединительной линии полностью изменился, и патч не может применяться. Разработчик должен оценить, существует ли тот же дефект в соединительной линии, и примените эквивалентную фиксацию в случае необходимости.
Случаи 1 и 2 являются обычными путями разработки обслуживания. Случай 3 имеет место, Вы рассматриваете, где междугородный код не может принять патч обслуживания ни в какой форме. Если разработчик не может самостоятельно определить, могла ли та же проблема существовать в соединительной линии, то он должен ввести проблему в систему отслеживания задач. Эта проблема направила бы магистральных разработчиков для рассмотрения причины патча в ответвлении обслуживания и мог ли тот же дефект все еще существовать. При вводе новой проблемы для возможный дефект в соединительной линии должен быть последним средством для разработчика обслуживания.
Одно преимущество наличия разработчиков обслуживания пытается применяться, патчи к обновленной соединительной линии должен увеличить их знакомство с новой кодовой базой. В конечном счете они исчерпают работы по техническому обслуживанию и должны будут работать с новой соединительной линией. Наличие, по крайней мере, базового уровня знакомства будет иметь большую выгоду.
Вы имеете к [1 110], имеют что много ответвлений, работающий на?
Была работа над соединительной линией, только запущенной, когда она сделала, потому что в плане проекта было сказано, что текущий выпуск будет готов поставляться, поэтому она была поставлена?
Вы получили много ответвлений обслуживания, потому что клиенты отказываются обновлять до последнего выпуска по некоторым причинам? Раз так обратитесь к причине.
у Вас есть слишком много старых выпусков, потому что разрыв перед следующим основным выпуском является слишком большим?
Вы заряжаете клиентов, которые не обновят больше для обслуживания, поскольку оно стоило Вам больше?
Ответ на комментарий:
Microsoft все еще поддерживает Windows XP даже при том, что Vista отсутствует
, очень верно, Однако Microsoft все еще не поддерживает Window XP SP1 даже при том, что XP SP3 отсутствует.
Это не черно и бело, даже если Вы, can’t прекращают поддерживать старую версию, можно быть в состоянии сократить количество старых версий, которые Вы поддерживаете. Проблема состоит в том, что Продажам/Поддержке нравится говорить да, но разработка страдает от боли, таким образом, необходимо получить людей продаж/поддержки на стороне.
В нашем проекте мы, прежде всего, не фиксируем изменения в ответвлениях обслуживания версии. Если существует ошибка, и
- она происходит и в соединительной линии и в основном ответвлении, мы фиксируем ее в соединительной линии и затем объединяем изменение в ответвлении обслуживания (который может einther происходить чисто или требовать большего количества работы, в этом случае мы решаем, не является ли не лучше, чтобы зафиксировать ошибку только в более новом выпуске).
- это находится только в ответвлении обслуживания, существует, вероятно, некоторый король фиксации в соединительной линии, и мы переходим к scenation номеру один.
Я думаю, что Ваш наилучший вариант состоит в том, чтобы иметь повторяющийся рефакторинг. Вместо того, чтобы делать весь рефакторинг в одной важной шишке на частном ответвлении, сделайте это одна фаза за один раз. Сделайте несколько наборов изменений на ответвлении и затем когда Вы знаете, что они стабильны, объединяют их с соединительной линией. Разработчики, работающие над другими ответвлениями, были бы ответственны за то, что постоянно совершенствовали их ответвление соединительной линии.
Слияние маленького набора изменений очень часто будет намного менее рабочим, чем слияние большие ответвления, которые отличаются вполне немного. Чем чаще Вы объединяетесь, тем меньше работы Вы будете иметь, чтобы сделать в конце.
Я могу только повторить, какие другие сказали при выделении реальной боли в $ a$, что очереди патча могут стать.
, Если у Вас есть предопределенный (и одетое железо) окно слияния, у Вас должно только быть две недели ада для контакта с.
Это может быть очень работа интенсивное предложение, но первая вещь, которая приходит на ум для меня, объединяет все назад с соединительной линией. Общие изменения становятся объединенными назад с соединительной линией, копируют и сохраняют их всех вместе. Затем осуществите рефакторинг на соединительной линии однако, Вы хотите. Теперь у Вас есть рабочая соединительная линия со всеми соединенными мерами.
, К сожалению, это означало бы, что любой фиксирует в ответвлениях maintainance, должен был бы быть брошен вместе и в центральную соединительную линию. Я понимаю, что это было бы большой работой, но я думаю, что это позволило бы всему быть пересмотренным, и любые улучшения ответвлений maintainance будут принадлежать основного ответвления. Я могу быть наивным об этом, но я действительно не работал над производственным проектом и также не знаю точно, что находится на ответвлениях maintainance. Я полагаю, что это сделало бы соединительную линию полностью обновленной, и все Ваши maintainance улучшения будут интегрированы в соединительную линию.
я изображаю выполнение его, этот путь максимизировал бы качество всех Ваших ответвлений и имел бы Ваш рефакторинг, распространенный по всем ответвлениям, Вы перейдете после рефакторинга. Это было бы хорошим способом объединить Вашу команду для всего слияния, также.
Я вижу два отдельных способа заняться этим:
1.
Существенные изменения к соединительной линии (как основной рефакторинг) не должны быть сделаны в соединительной линии. Они должны быть сделаны в ответвлении и объединились назад в соединительную линию, когда они достаточно стабильны.
Периодически изменения в соединительной линии должны быть объединены с другими ответвлениями обслуживания. Причина того, чтобы только объединить рефакторинг в соединительную линию, когда это стабильно, состоит в том, потому что они будут тогда объединены в ответвления обслуживания. Если бы однако нет никакой возможности делать эти изменения стабильными тогда, опция 2 была бы лучше.
После того, как изменения в ответвлениях обслуживания были внесены, они могут тогда быть объединены назад в соединительную линию.
2.
Создают ответвление ответвлений обслуживания (одно ответвление для каждого). Это будет использоваться для слияния соединительной линии с каждым ответвлением обслуживания. (Обратите внимание, что использование внешнего облика SVN или эквивалента должно использоваться для ограничения количества ответвлений обслуживания).
Делают весь Ваш рефакторинг в соединительной линии и объединяют это в ответвления ответвлений обслуживания. Когда Вы выпускаете или думаете, что соединительная линия стабильна, тогда объединяют эти ответвления корректировочных версий назад в их соответствующие ответвления. Они могут тогда в свою очередь быть объединены назад в соединительную линию.
В действительности каждое ответвление обслуживания становится "sub соединительная линия".
Примечание, что этот сценарий выделяет компромисс между будущим обслуживанием и первичным обслуживанием. Чем больше ответвлений и различий Вы имеете в своем коде, тем более первичное обслуживание требуется. Хорошая часть - то, что возрастающее обслуживание намного легче.
В точке, что Ваши ответвления обслуживания больше не совместимы с основной соединительной линией, было бы пора создать новые ответвления с этой целью. Таким образом, в начале большого проекта Вы удостоверяетесь, что все Ваши разработчики знают, что новая функциональность прибывает в основную соединительную линию, так, чтобы они могли сделать лучший выбор того, где реализовать, фиксирует. По-видимому, если изменения кода, происходящие в основной соединительной линии, являются столь значительными, что представляют неприемлемое обслуживание, то обслуживание должно быть включено в основную соединительную линию.
Учитывая, что много стоимости исправления ошибки воспроизводит проблему и тестирует фиксацию. Можно ли записать автоматизированный тест, который будет работать во всех ответвлениях, даже если код зафиксирует, должен быть сделан по-другому для каждого ответвления?
Единственный ответ, который я смог придумать, должен создать ответвление соединительной линии обслуживания непосредственно перед тем, как Вы начинаете осуществлять рефакторинг. Вы поддерживаете это новое ответвление, как будто это была соединительная линия, объединяя изменения в и от ответвлений выпуска как нормальные. При продвижении затем необходимо быть осторожны относительно смешивания изменений от старых и новых исходных оснований.
другая альтернатива должна попробовать что-то как MolhadoRef ( статья блога о MolhadoRef и Осведомленном о рефакторинге SCM), если можно найти готовую к производству эквивалентную систему, которая удовлетворяет потребности. Это, в теории, осведомленном о рефакторинге управлении исходным кодом. Я не изучил его в некоторое время, но в последний раз я вспоминаю, что это было все еще довольно далеко от того, чтобы быть чем-то большим чем научно-исследовательской работой и подтверждением концепции.
На практике Вам, вероятно, придется сделать дополнительную работу для внесения новых изменений назад совместимыми.
-
Шаг 1: Начните осуществлять рефакторинг компонент. С каждым шагом имейте в наличии старый интерфейс, но имейте его, перемещают вызовы в новую реализацию. Обратите внимание, что это может быть сделано в несколько этапов, поскольку новый интерфейс/API создается. Модульные тесты должны смочь проверить, что миграция от старого до новых работ правильно, но этот шаг, скорее всего, все еще подвергнется тестированию/QA наверху.
-
Шаг 2: новая версия активна в производстве; удостоверьтесь, что все знают об этом. На данном этапе никакие новые возможности не добавляются к старой версии и всем новым (или изменяются), вызывающие стороны используют новую версию.
-
Шаг 3: Найдите все (используйте инструменты, чтобы сделать это), который называет старый интерфейс, и измените все для вызова нового интерфейса. Это, вероятно, подвергается большому тестированию/QA наверху, также. Каждая вызывающая сторона может фиксироваться/выпускаться по одному, все же.
-
Шаг 4: На данном этапе новая версия активна, и нет никаких вызывающих сторон, оставленных тот доступ старая версия. Удалите его безопасно.
Примечание, что, где API общедоступен и Вы не управляете людьми, которые называют его (компании как Microsoft, например), Вы никогда не могли бы мочь пойти мимо шага № 2.
, Этот процесс может быть медленным, и требуется большая дисциплина, связь и тестирование. Но в случаях, где альтернатива играет захват/интеграцию навсегда, это могла бы быть разумная опция.
Это - в конечном счете вопрос о коммуникации команды, а не простой переходящий/объединяющий вопрос.
первый шаг, как во всех таких случаях, понимает, что у Вас есть проблема. Это - что-то, что Вы сделали.
Затем необходимо предупредить целую команду к проблеме.
, После того как Вы сделали это, я думаю, что существует два различных пути:
-
, Если ответвления обслуживания нечасто используются, скажите, что выпущенный код является довольно сформировавшимся и без ошибок, можно выбрать замораживание кода. Каждый разработчик должен закончить то, что он продолжает работать 32 Octember, и объединитесь, они возвращаются в соединительную линию. Ответвления должны затем быть или закрыты или заморожены. Затем работа может продолжиться в соединительной линии, и новое программное обеспечение может быть выпущено.
-
, Если существуют частые или срочные изменения и фиксируют в ответвлениях, эта проблема более сложна. Там все еще потребности быть замораживанием кода или соединительной линией будут ударены многократно. Но здесь, разработчики все еще должны починить вещи тем временем и вывести их клиентам. Я предлагаю, чтобы каждое изменение в ответвлениях после замораживания междугородного кода было зарегистрировано в базе данных отслеживания ошибок (необходимость в каждой ситуации) со специальным признаком, что это было зафиксировано в ответвлении N, но еще не объединилось с соединительной линией. Это требует тщательного входа так, чтобы каждую соответствующую деталь помнили.
После того, как соединительная линия пересмотрена, но прежде чем она будет чиститься, полироваться, отмечаться и выпускаться, рассмотрите базу данных ошибки, особенно объекты, зафиксированные в ответвлениях, но не соединительной линии. Они все еще релевантны? Теперь время для изменения кода снова, при необходимости. Это может означать двойную работу в течение короткого времени, но надо надеяться код намного более удобен в сопровождении теперь.
, После того как все известные проблемы устраняются, новая версия может быть выпущена, и старые ответвления могут быть закрыты.
Создайте ответвление обслуживания и имейте его действие как буфер между соединительной линией и ответвлениями версии.
Изменения в ответвлениях версии входят в ответвление обслуживания, и затем propegate в соединительную линию, только если они могут и наоборот.
я не думаю, что существует серебряная пуля, все же. Поскольку ответвления отличаются все больше, они станут несовместимыми и таким образом, необходимо будет рассмотреть, как долго Вы будете поддерживать их. Иначе Вы могли бы закончить тем, что исправили ошибки несколько раз, но немного по-другому для различных ответвлений.
As Greg pointed there are several possible scenarios.
I'd add a case (2.5) where manual merge is required, but since you've moved a method away from its original location and then applied some changes, it becomes hard to merge, specially if the "base" code was also modified in the "maintenance" branch. This is not as uncommon as it sounds, in fact moving a method to a different location and applying a small fix is pretty common.
We've developed a tool called Xmerge (cross-merge) which is a first step towards refactor-aware merging. It's not yet automatic, but it helps dealing with tough merges involving moved code. It's described here and is already integrated in Plastic SCM 2.7.
We're working on: automatic move detection and also being able to "cross merge" towards multiple destination files (you move code to another file, which is also pretty common).