Является ли быстрая основная версия, свидетельствующая о плохом дизайне?

16

Я начал работать младшим программистом несколько месяцев назад. Система, над которой мы работаем, работает в течение ~ 2 лет. Я не участвовал в попрошайничестве системы и дизайна.

Одна вещь, которую я заметил, состоит в том, что основная версия системы уже 11.YZ Из моего опыта работы с другими системами и библиотеками я не припоминаю, чтобы продукт быстро обновлял основную версию. Есть продукты, которые годами выпускались в 1.XY и до сих пор получают функции и исправления.

Предполагая, что семантическое управление версиями используется должным образом, означает ли это, что система плохо спроектирована, так как она вносит серьезные изменения почти каждые четыре месяца?

user367035
источник
2
Этот вопрос будет зависеть от того, принесут ли эти серьезные перемены достаточные выгоды (и прибыль), которые оправдывают высокую скорость изменений.
Rwong
3
Если этот номер версии использует Semver, и если в системе имеется библиотека или другой API, от которого зависят другие группы или организации, то это большое старшее число означает, что возникли проблемы с принятием стабильного, расширяемого дизайна API. Это также означает, что ясное сообщение о несовместимости высоко ценится, и это хорошо. Для всего остального (например, маркетинговые названия, прикладные программы, номера не-Semver и т. Д.) Это число не имеет смысла и должно в значительной степени игнорироваться. Просто спросите об этом своих коллег, чтобы лучше узнать проект.
Амон
3
@amon Система используется внутри с общедоступными мобильными клиентами, связывающимися с системой через REST-подобный API. Версия как Semver, как я уже упоминал, а не маркетинговая версия.
user367035
Число не имеет значения, но я бы заподозрил, если идентификатор версии содержит какую-нибудь симпатичную аббревиатуру, например Windows NT или Windows ME или XP или что-то действительно Windows.
Джон Ву
1
@JohnWu: вопрос конкретно о количестве, так что да, число имеет значение. Точнее, речь идет о числе в контексте SemVer, где число не только имеет значение, но и имеет точно указанное значение.
Йорг Миттаг

Ответы:

14

Предполагая, что семантическое управление версиями используется должным образом, означает ли это, что система плохо спроектирована, так как она вносит серьезные изменения почти каждые четыре месяца?

Не обязательно.

Вы упомянули в комментариях, что это внутренний API. Взлом API - это плохо, потому что вы нарушаете код каждого. Но для внутреннего API «все» - это просто «вы», и вы вполне способны координировать такие изменения API с самим собой, поэтому боль, которая обычно связана с изменениями API, намного меньше.

Кроме того, среднее значение может быть в значительной степени вводящим в заблуждение: может быть, у них было 11 критических изменений API в первые пару дней ранней разработки, и с тех пор они были стабильными в течение 4 лет? SemVer позволяет вам вносить критические изменения, не увеличивая старшее число, если старшее число равно 0, но это не заставляет вас делать это. Может быть, они начали использовать SemVer с 0-го дня, даже на стадии прототипирования / исследования?

Йорг Миттаг
источник
5
Этот ответ, кажется, напрямую касается вопроса. Некоторые из других ответов были бы верны, если бы не допущение OP семантического управления версиями.
Joshp
Также примечательно, что критические изменения не всегда являются существенными. Иногда они действительно довольно маленькие (но важные). Таким образом, им может потребоваться очень мало изменений для пользователей. Кроме того, возможны довольно серьезные изменения в зависимости от того, как используется API. Например, иногда критические изменения не влияют на всех пользователей. Кроме того, исправления ошибок могут привести к серьезным изменениям, но лучше их исправить раньше, чем позже. А если API является внутренним, то с этими небольшими изменениями справиться намного проще.
Kat
1

Короткий ответ

нет

Длинный ответ

«Иногда число - это просто число»

Забудьте о «семантическом версионировании», «рациональности», «логике» в современном сумасшедшем мире

Почему Chrome так быстро поглощает номера версий?

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

Ленивый Барсук
источник
7
ОП сказал, что они используют семантическое управление версиями; почему вы тогда игнорируете это?
Йорг Миттаг
-3

При использовании семантического управления версиями все еще необходимо принять решение, какие изменения считаются «основными», а какие - «незначительными». Существуют различные причины, чтобы увеличить номер версии или не повышать его.

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

В других случаях у вас действительно есть график выпуска (например, ежеквартальные компакт-диски с обновлениями, рассылаемые клиентам), в которых имеет смысл изменить основной номер версии, чтобы вместо «Версия 3.4 / 16 октября» просто было указано «Версия 11.0». В настоящее время все больше и больше программного обеспечения выпускается через короткие промежутки времени, поэтому графики выпуска становятся менее веской причиной придерживаться определенной схемы управления версиями. Я видел это в больших складских системах, которые позволяют внутренним ИТ-отделам работать только один день в квартал (обычно в воскресенье). Этот день является днем ​​развертывания и каждый раз отмечается новой основной версией.

Некоторые программы имеют внешние зависимости, которые имеют первостепенное значение, потому что пользователь должен будет обновить оба одновременно. Если у вас есть надстройка Word, которая работает только с Word 2010, а другая - для Word 2013, вы можете синхронизировать основные номера версий с MS-Word. Здесь основные цифры так важны, потому что некоторые из ваших пользователей будут «отставать» от вашего обычного графика обновлений, поскольку они не обновились до самой последней версии Word (или любой другой, на которую вы полагаетесь: SAP, Dynamics, и т.д).

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

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

Hazzit
источник
3
«При использовании семантического управления версиями все еще необходимо принять решение, какие изменения считаются« основными », а какие« второстепенными »». - нет, нет; это точно определено в спецификации. «Существуют различные причины, чтобы поднять номер версии - или не поднять его». - нет, нет; Существует только одна причина для увеличения основного числа (о чем этот вопрос), и это определено именно в спецификации.
Йорг Миттаг
1
@ JörgWMittag Либо я читаю неправильно, либо спецификация специально говорит, когда вы ДОЛЖНЫ повышать номера версий, но ничего не говорит о том, когда вы МОЖЕТЕ.
Hazzit
-4

Концепция значений номеров версий действительно важна. Minor.revision.buildnumber

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

Однако в мире бизнеса могут быть и другие причины для увеличения номера основной версии. подобно

  • Продажи падают, клиенты / пользователи ждут следующего большого релиза перед обновлением.

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

  • Конкурент X был в игре немного дольше, поэтому его номер основной версии оказался выше, чем у вас. Это создает впечатление, что вы отстаете, вам нужно «наверстать упущенное».

Мартин Маат
источник
6
Вопрос помечен с семантическим версионированием , ОП упоминает семантическое версионирование в вопросе и еще раз подтвердил в комментариях, что они используют семантическое версионирование. Спецификация SemVer очень четко говорит, когда основные версии увеличиваются. Ни одна из ваших «других причин» не применима.
Йорг Миттаг