Стратегии разработки нескольких продуктов от одной кодовой базы
Существует большая разница между постфиксной и префиксной версиями ++.
В префиксной версии (то есть, ++i) значение i увеличивается, а значением выражения является новое значение i.
В постфиксной версии (то есть, i++) значение i увеличивается, но значением выражения является первоначальное значение i.
Давайте построчно проанализируем следующий код:
int i = 10; // (1)
int j = ++i; // (2)
int k = i++; // (3)
-
iустановлен в10(просто). - В этой строке две вещи:
-
iувеличивается до11. - Новое значение
iкопируется вj. Итак,jтеперь равно11.
-
- В этой строке также есть две вещи:
-
iувеличивается до12. - Исходное значение
i(то есть11) копируется вk. Итак,kтеперь равно11.
-
Таким образом, после запуска кода, i будет 12, но j и k будет 11.
То же самое относится и к постфиксным и префиксным версиям --.
3 ответа
Очень интересный вопрос. Мне нравится идея распространять все, а затем использовать лицензионный ключ для включения и отключения определенных функций. У вас есть веские основания полагать, что пройти через код и продолжать проверять, имеет ли пользователь лицензию на использование определенной функции, потребуется много работы. Это очень похоже на то, что вы работаете в java, поэтому я бы посоветовал вам изучить возможность использования ткача аспектов для вставки кода для проверки лицензии во время сборки. По-прежнему будет один объект, в который будут входить все запросы на проверку лицензии, но это не так уж и плохо, если вы используете аспект, я бы сказал, что это хорошая практика.
По большей части вам нужно читать только в том случае, если что-то лицензировано, и у вас будет небольшое количество компонентов, чтобы таблица могла всегда храниться в памяти, а поскольку она просто считывается, вам не следует ' у меня слишком много проблем с потоками.
В качестве альтернативы вы можете распространить несколько jar-файлов, по одному для каждого лицензированного компонента, и разрешить загрузку только лицензированных классов. Для этого вам придется подключиться к загрузчику классов.
Вы хотите сделать это через Subversion? Я бы использовал Subversion для поддержки различных выпусков (ветка для каждого выпуска, например, v1.0, v2.0 и т. Д.), Но я бы посмотрел на создание других выпусков (пробных / профессиональных и т. Д.) Из та же кодовая база .
Таким образом, вы просто включаете или отключаете различные функции через сборку, и вам не нужно беспокоиться о синхронизации разных веток. Если вы используете Subversion для управления разными выпусками и разными версиями, я могу увидеть бурный рост ветвей / тегов в ближайшем будущем.
Для переключения вы можете просто поддерживать проверенную базу кода и использовать svn switch , чтобы проверить разные версии. Это намного меньше времени, чем выполнение новых проверок для каждого коммутатора.
] Вы правы, что не запрыгиваете на тележку разветвления и слияния так быстро. Это PITA.
Единственная причина, по которой я хотел бы создать ветвь репозитория Subversion, - это если я хочу поделиться своим кодом с другим разработчиком. Например, если вы вместе работаете над функцией, а это еще не сделано, вам следует использовать ветку для связи. В противном случае я бы по возможности оставался в магистрали.
Я поддерживаю рекомендацию Брайана различать выпуски по сборке, а не по кодовой базе.