Непрерывные сборки и Гибкий по сравнению с фиксацией, часто [закрываемой]
Его полезное при создании собственного контейнера как объекты.
, Например, если необходимо было создать вектор. При резервировании пространства для большого количества объектов, Вы хотите выделить память с некоторым методом, который не вызывает конструктора объекта (как новый символ [sizeof (объект) * reserveSize]). Затем, когда люди начинают добавлять объекты в вектор, Вы используете размещение, новое для копирования их в выделенную память.
template<typename T>
class SillyVectorExample
{
public:
SillyVectorExample()
:reserved(10)
,size(0)
,data(new char[sizeof(T) * reserved])
{}
void push_back(T const& object)
{
if (size >= reserved)
{
// Do Somthing.
}
// Place a copy of the object into the data store.
new (data+(sizeof(T)*size)) T(object);
++size;
}
// Add other methods to make sure data is copied and dealllocated correctly.
private:
size_t reserved;
size_t size;
char* data;
};
пз. Я не рекомендую делать это. Это - просто упрощенный пример того, как могут работать контейнеры.
11 ответов
Что может быть менее гибким, чем табу на то, что что-то идет не так? Я бы сказал, что табу - оставить сборку сломанной, а не сломать сборку вообще. Случайные поломки сборки - это нормально. Именно поэтому вы запускаете непрерывные сборки и тесты. Сборка / тест CI определяет, когда сборка не работает, и, в идеале, кто ее сломал. Это гарантирует быстрое исправление. Если это случается время от времени, все в порядке. Если это происходит двадцать раз в день, у команды, вероятно, проблемы.
Табу - мешать другим людям выполнять свою работу. Когда вы прерываете сборку, они получают электронное письмо с сообщением: «Наша ветка исходного кода закрыта». Они не смогут интегрировать изменения других людей или их изменения в основную ветку, пока не получат полное электронное письмо. 1) Сохранение небольших команд. Обычно проблемы возникают после того, как в команду входит около 25 разработчиков. Вещи становятся хрупкими. Использование ветвей, компонентов или многоэтапных CI на уровне команды с потоками может помочь более крупным командам разбиться на более мелкие команды.
2) Выбор небольших единиц работы. Как правило, не должно быть конфликта между регулярной проверкой улучшений и отказом от всего. Коммиты должны выполняться при внесении небольших рабочих изменений. Новая функция может быть еще не открыта для пользователя, но если сделано согласованное изменение API, которое не нарушает тесты, отметьте его.
3) Быстрые и точные сборки. Есть много условий гонки, в которых команда, как правило, выигрывает чаще, когда сборка становится быстрее. Кроме того, воспроизводимые сборки гарантируют, что сборка, которую разработчик делает на своей собственной машине (что она успела сделать, потому что она была быстрой), достаточно точно предсказывает успех при фиксации.
Ветви / теги решают эту проблему в большинстве систем управления версиями.
Они позволяют вам пометить или просто «разветвить» (каламбур) сегмент / ревизию кода и обозначить это как ' стабильный выпуск ». Затем вы можете зафиксировать изменения в основной магистрали или ветке «патч», или с помощью других подходов.
Эти две концепции работают вместе.
Я рискну предположить, что «перемещение» действительно не существует, поэтому вам просто нужно будет найти «удалить», а затем пометить этот файл как тот, который может быть «возможно перемещен», а затем, если вы увидите «создать» для вскоре после этого, я полагаю, вы можете предположить, что вы правы.
У вас есть случай создания случайных файлов, влияющих на ваше обнаружение ходов?
Это может включать добавление проверенного кода (новый метод или объект) и его проверку перед компоновкой в остальной части кода.В целом, ваши модульные тесты должны выполняться ВСЕГДА. Я обычно запускаю тесты несколько раз в минуту и редко чаще, чем один раз в десять минут.
Небольшие шаги могут занять немного больше времени, но вы избежите тех 3-4-дневных сессий переписывания кода, где вы можете Не проводите никаких тестов и не проверяйте, это может быть жестокой и ОГРОМНОЙ тратой времени!
Используйте Git для легкого ветвления, слияния и перемещения.
Silky - это то, что нужно, ветвление / тегирование решает эту проблему (svn plug для этой функции).
Я часто являюсь большим поклонником коммитов, и лично я считаю, что это помогает предотвратить нарушение сборки, потому что я каждый раз тестирую меньшее количество кода.
Для значительного или большого изменения, которое может нарушить зависимые части кода, было бы целесообразно создать ветвь. В тот момент, когда вы хотите интегрировать это изменение и проверить его в магистрали или в какой-либо другой ветви интеграции, в которую вы собираетесь продвигать его, необходимо устранить поломки и обеспечить работоспособность всех тестов.
Я не думаю, что эти две вещи должны работать друг против друга. Использование ветвей или распределенного контроля версий упростило бы управление.
. Вам нужно будет проверить, какой вид истории имеет смысл во время слияния. Допустим, у вас есть программа, которая использует множество загружаемых модулей, может быть ядром ... веб-сервером, что угодно.
При написании одного модуля вы делаете 200 коммитов, когда вы объединяетесь с основным проектом, вам, вероятно, понадобится только один (хотя и большой) патч, возможно, два:
- Ввести модуль foo
- Обновить Makefiles для сборки foo
Это одна из причин, почему Git стал таким доминирующее присутствие в мире DVCS.
Ваш выбор частоты фиксации действительно не имеет отношения к тому, какой метод разработки программного обеспечения вы хотите использовать. Вы можете зафиксировать 200 хорошо протестированных ревизий или одну, если люди, извлекающие то, что вы нажимаете, не принимают токсичные ревизии или регрессии в своем коде, вызванные вашим собственным (если, конечно, ваш код не обнаруживает проблемы в их коде).
Мне (лично) нравится делать много небольших коммитов по тем же причинам, что и вы. Фактически, обычно идеально, если все работают в одном центральном филиале. Однако, если вы работаете над какой-либо подсистемой в течение 6 месяцев,
Я добавлю еще один ответ, потому что мне кажется, что некоторые из наиболее важных моментов не были упомянуты.
Мое понимание управления версиями это лучше делать часто, потому что тогда у вас есть история и возможность вернуться к предыдущим изменениям
Я полностью согласен с этим.
Мое понимание Agile и непрерывная сборка заключается в том, что ее нужно оказать давление на разработчиков, чтобы всегда иметь рабочий код.
Это не там, чтобы оказывать давление на разработчиков - я бы предпочел описать непрерывную интеграцию как дружественную страховочную сетку , которая помогает вам обнаруживать проблемы, как только вы их фиксируете, а исправить их обычно несложно. (Дополнительные сведения о преимуществах CI см. В основополагающей статье Мартина Фаулера .) важно, чтобы всегда был рабочий код, и именно здесь вступают в силу ветви управления версиями, как шелковистый указал . Но в отличие от традиционного сценария, который он описывает (и того, о чем говорит Фаулер: «Все переходят на основную ветку каждый день»), я бы порекомендовал противоположное: пусть ваш основной ствол будет стабильным, желательно всегда в готовом к выпуску виде, и делать все основные разработки в временные рабочие отделения.
Я ' мы подключили стабильную магистраль к SO здесь и здесь ; см. эти сообщения для обоснования и опыта использования этой модели. Кроме того, я настоятельно рекомендую эту статью, которая сильно повлияла на мое мышление: Контроль версий для нескольких Agile-команд от Хенрика Книберга.
Нарушение сборки в ветке разработки - это далеко не табу, хотя вы все равно должны постарайтесь, чтобы все скомпилировалось и все тесты прошли. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).
см. эти сообщения для обоснования и опыта использования этой модели. Кроме того, я настоятельно рекомендую эту статью, которая сильно повлияла на мое мышление: Контроль версий для нескольких Agile-команд от Хенрика Книберга.Нарушение сборки в ветке разработки - это далеко не табу, хотя вы все равно должны постарайтесь, чтобы все скомпилировалось и все тесты прошли. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).
см. эти сообщения для обоснования и опыта использования этой модели. Кроме того, я настоятельно рекомендую эту статью, которая сильно повлияла на мое мышление: Контроль версий для нескольких Agile-команд от Хенрика Книберга.Нарушение сборки в ветке разработки - это далеко не табу, хотя вы все равно должны постарайтесь, чтобы все компилируется и все тесты проходят. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).
Я горячо рекомендую эту статью, которая сильно повлияла на мое мышление: Контроль версий для нескольких Agile-команд от Хенрика Книберга.Нарушение сборки в ветке разработки - это далеко не табу, хотя вы все равно должны попытаться продолжайте компилировать все и все тесты проходят. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).
Я горячо рекомендую эту статью, которая сильно повлияла на мое мышление: Контроль версий для нескольких Agile-команд от Хенрика Книберга.Нарушение сборки в ветке разработки - это далеко не табу, хотя вы все равно должны пытаться продолжайте компилировать все и все тесты проходят. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).
хотя вы все равно должны стараться, чтобы все компилировалось и все тесты проходили. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком). хотя вы все равно должны стараться, чтобы все компилировалось и все тесты проходили. Нарушение сборки ствола в этом сценарии несколько серьезнее, но все же я бы не назвал это табу - такие вещи случаются время от времени, и вместо того, чтобы искать виноватых, это бесконечно более важно для команды просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком). Для команды гораздо важнее просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком). Для команды гораздо важнее просто исправить это (и быть счастливым, что проблема была обнаружена сейчас , а не намного позже, возможно, заказчиком).Если большое изменение кода происходит в отдельной ветви, это не обязательно нарушает сборку. Имея ответвление на себя, изменения сохраняются вне кода до тех пор, пока изменение не будет выполнено, а затем все это можно объединить обратно в магистраль или основную строку кода. Ключевым моментом является то, что пока идет непрерывная сборка, она не обязательно будет включать в себя вещи, которые не "готово".
Мне кажется, что Git решает эту проблему. Сохраняйте локальный репозиторий и выполняйте фиксацию на раннем этапе, часто выполняйте фиксацию, а затем, когда код достигает непревзойденной контрольной точки, отправляйте в основной общий репозиторий. Если вся команда использует Git, тогда вся история репозитория может сохраняться в репозитории всех остальных, когда они затем извлекают изменения. И все это без нарушения сборки.
А с ребазингом вам даже не нужно открывать всю локальную историю коммитов, когда вы выдвигаете контрольные точки.
Если вся команда использует Git, тогда вся история репозитория может сохраняться в репозитории всех остальных, когда они затем извлекают изменения. И все это без нарушения сборки.А с ребазингом вам даже не нужно открывать всю локальную историю коммитов, когда вы выдвигаете контрольные точки.
Если вся команда использует Git, тогда вся история репозитория может сохраняться в репозитории всех остальных, когда они затем извлекают изменения. И все это без нарушения сборки.А с ребазингом вам даже не нужно открывать всю локальную историю коммитов, когда вы выдвигаете контрольные точки.
TDD позволяет вам иметь и то, и другое
Одним из решений этого очевидного парадокса является практика гибкой разработки программного обеспечения Test Driven Design (TDD ). При правильной практике легко коммитить код, часто и имеют непрерывные сборки, которые редко ломаются из-за неработающего кода.
Сначала получите последний код из репозитория и запустите все тесты. (Если они не все проходят, выберите последнего, кто совершил фиксацию.) Напишите тест для небольшого фрагмента функциональности (, прежде чем вы реализовали функциональность), затем реализуйте функциональность и запустите все снова тесты.Обновите свой код из системы контроля версий на случай, если что-то изменилось во время вашей работы, снова запустите все тесты, и если все они пройдут, вы можете сразу выполнить фиксацию. Это «красно-зеленый» в гибкой концепции «красный-зеленый-рефакторинг». После этого проведите необходимый рефакторинг и снова запустите все тесты. Если вы все еще зеленый, вы можете снова совершить фиксацию.
У большинства гибких команд есть сервер непрерывной интеграции , который работает по регулярному графику (часто ежечасно или чаще) и имеет большой видимый индикатор (например, светофор), который показывает, прошла ли последняя сборка. , не удалось или находится в процессе.
Иметь локальную базу данных управления версиями, если это необходимо
Если вы абсолютно не можете избежать «значительных изменений кода», тогда используйте свой собственный локальный репозиторий управления версиями, используя что-то вроде git , как предлагает Гордон Поттер, и зафиксируйте, когда закончите с изменениями. Вы можете сделать это, даже если ваша команда использует другой продукт для контроля версий.