Нарушает ли codefreeze принципы непрерывной доставки?
На самом деле это не просто HashSet. Все реализации интерфейса Set в Java 6 основаны на базовом Map. Это не требование; это просто способ реализации. Вы можете убедиться сами, проверив документацию по различным реализациям Set .
Ваши основные вопросы:
Но почему он все еще используется? Есть ли причина использовать его, кроме упрощения ведения кодов?
Я предполагаю, что обслуживание кода является большим мотивирующим фактором. Таким образом, предотвращается дублирование и раздувание.
SetиMap- это аналогичные интерфейсы, поскольку дублирующиеся элементы не допускаются. (Я думаю, что единственныйSet, а не , поддерживаемыйMap, -CopyOnWriteArraySet, что является необычной коллекцией, потому что оно неизменное.)В частности:
Из документации
Set:Коллекция, которая не содержит повторяющихся элементов. Более формально множества не содержат пары элементов e1 и e2 таких, что e1.equals (e2) и не более одного нулевого элемента. Как показано в его названии, этот интерфейс моделирует абстрактную абстракцию математического набора.
Интерфейс Set устанавливает дополнительные условия, помимо тех, которые унаследованы из интерфейса Collection, в контрактах всех конструкторов и контрактах add, equals и hashCode. Объявления для других унаследованных методов также включены здесь для удобства. (Спецификации, прилагаемые к этим объявлениям, были адаптированы к интерфейсу Set, но они не содержат каких-либо дополнительных условий.)
. Дополнительная оговорка о конструкторах не удивительно, что все конструкторы должны создать набор, содержащий
И из
Map:Объект, который сопоставляет ключи со значениями , Карта не может содержать дубликаты ключей; каждый ключ может отображать не более одного значения.
Если вы можете реализовать свой
Sets с использованием существующего кода, любое преимущество (например, скорость), которое вы можете реализовать из существующего кода, начисляется на вашSet.Если вы решите реализовать
Setбез подставкиMap, вам придется дублировать код, предназначенный для предотвращения дублирования элементов. Ах, восхитительная ирония.Тем не менее, ничего не мешает вам реализовать ваш
Setпо-другому.
1 ответ
Да, я думаю, что такой подход значительно отличается от принципов КИ. Это, вероятно, попадает в сферу CI Theatre . А без CI нельзя говорить о CD.
Общая идея CI состоит в том, чтобы вся разработка была разбита на небольшие, постепенные изменения, разработанные как можно ближе к вершине ветви и немедленно интегрированные в ветку, чтобы максимизировать видимость и свести к минимуму сюрпризы. Только в таких условиях инструмент CI может эффективно указывать на большинство проблемных коммитов очень быстро.
Уход за боковую ветвь (замороженная или нет), пока ведущая ветвь продолжает двигаться, требует дополнительных усилий для объединения этой ветки с ведущей (в любом направлении), увеличивая сложность пропорционально сроку службы боковой ветви. Это потому, что слияние пытается объединить 2 больших комка: все коммиты из ветви и все коммиты, выполненные на master, так как ветка была извлечена / синхронизирована - больше не является инкрементным изменением. Возможность сразу определить ошибочный коммит теряется, это решение «все или ничего»: либо вы разрешаете объединение, принимая удар по качеству, либо отклоняете его. Вот почему ИМХО:
- разговоры о выполнении CI на ветвях почти сразу подозревают
- CI (как методология) в значительной степени синонимичны основанной на магистрали разработке (TBD) ) .
Ветви релизов немного отличаются от обычных веток, они могут иметь смысл в некоторых бизнес-случаях. Но только если они остаются верными CI, не подвергаясь слияниям. Смысл ветки релиза - это замораживание - изоляция его от разработки в стволе, которая продолжает эволюционировать к следующему выпуску. Слияние ветки релиза обратно в trunk не имеет большого смысла для меня: изменения для более старой версии не обязательно совместимы с более новой версией, такое объединение просто вызывает проблемы. Смотрите также мой ответ на Как избавиться от ветки разработки для упрощенного потока Git . Если в ветви релиза есть ценные коммиты (обычная причина для запроса такого слияния), они должны быть проверены на совместимость и дважды зафиксированы в транке как независимые изменения, подчиненные тем же критериям проверки, что и любые другие изменения транка.
Примечание: я не говорю, что стратегии без CI не будут работать - большинство из них работают (я работал с ними годами), но они сложнее, медленнее и дороже.