Разработка программного обеспечения различных версий

Вопросы по программированию, не подходящие в другие разделы.

Модераторы: Naeel Maqsudov, C_O_D_E

Ответить
Аватара пользователя
Oscar
Сообщения: 963
Зарегистрирован: 29 май 2004, 13:44
Откуда: Мюнхен (рожден в Киеве)
Контактная информация:

Здравствуйте, уважаемые (и не очень ;-) ).

В процессе создания программного продукта наша группа разработчиков дошла до точки, когда нужно наконец-то исправлять накопившиеся за долгие годы написания глупого кода ошибки :lol:

не, не так.

Мы тут программу пишем: Java + Eclipse + CVS
а они там её продают по лицензиям


И по сему поводу есть два вопроса:

1. Хотелось бы иметь одну стабильную версию и другую, над которой можно работать.

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

Для достижения стабильности руководством проэкта было предложено следующее:
в какой-то момент программа разделяется на две "ветки",
новые куски кода идут только в одну из них,
а исправление ошибок (bugfixing) идёт в обе.
Таким образом работа над проэктом не замирает, но через какое-то время в "замороженной" ветке достигается стабильность.

Я слышал, что в CVS есть возможность создавать "branches" и судя по названию это именно то, что нужно, но могу ведь и ошибаться.

потому вопросы:

1.1. Правильно я понимаю суть "branches" в CVS ? Если нет - в какую сторону смотреть?

1.2. Существует ли автоматизированная возможность вносить изменения (bugfixing) одновременно в обе ветки, или же прийдётся каждый раз вручную менять обе ветки?

1.3. Где об этом можно почитать детальнее (по каким словам искать) ?


2. Программа, как я уже упомянул выше, на продажу. С различными лицензиями и ограничениями, связанными с этим.
Как правильно реализовать различный уровень доступа к возможностям программы, в зависимости от лицензии (по сути - колличества денег) ?

Я вижу такие варианты:

2.1. Повсюду в программе повставлять if-then-else (меня просто воротит от мысли о том, как "красиво" после этого будет выглядеть код)

2.2. ВырезАть "с мясом" куски программы, не подлежащие лицензии ещё в процессе компиляции.

2.3. А может CVS в этом тоже может помочь?..

Может кто-то знает варианты получше?

Примечание: Программа может распространяться с веб-сервера (где происходит checkout последней стабильной версии с CVS и можно "вЫрезать" не оговорённые в лицензии куски кода до компиляции) или же отсылаться по емейлу или на CD (собственно всё равно берётся с веб-сервера).

2.1. Преимущество if-then-else в том, что стоит пользователю приобрести лицензию более высокого уровня, как он тут же получит новую функциональность и ему не прийдётся скачивать новую версию самой программы (но программа не большая по обьёму и вряд ли это будет так уж существенно, кроме того весьма вероятно, что в новой версии будут присутствовать уже новые полезные фичи).

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

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

Вот только тут есть один бооольшой Недостаток: никто из нас понятия не имеет, как это реализовать на практике :D

Мною был предложен следующий метод:
В код программы в виде комментариев вставляются метки/тэги, которые выглядят приблизительно так:
[syntax:2a67aedffb="java"]menu.add(new JMenuItem("something"));
/* begin not for all */
menu.add(new JMenuItem("additional"));
/* end not for all */
[/syntax:2a67aedffb]

По этим меткам скрипт на сервере (Perl/PHP, да хоть та же Java) при помощи регулярных выражений вырезает внутренний кусок, после чего код компилируется, пакуется в JAR и проганяется через uglifier.

И это работает! НО ..

Синтаксические ошибки внутри комментариев невозможно отловить на стадии компиляции программы (в процессе её разработки в IDE), максимум, что можно делать, - читать логи скрипта на сервере.
Как результат, - неправильное написание метки приводит к семантической ошибке, которую весьма просто можно и не заметить.

По большому счёту, необходим аналог такого понятия, как pragma в C++

[syntax:2a67aedffb="cpp"]// #define not_for_all_version
#define standart_version

// menu.add(new JMenuItem("something"));
#ifdef not_for_all_version
// menu.add(new JMenuItem("additional"));
#endif[/syntax:2a67aedffb]

Но Java прагмы не поддерживает, насколько мне известно.

Потому вопросы:
2.1. Существуют ли стандартные решения данной проблемы в Java?
2.2. Если нет, - может кому известны "third part" программы/библиотеки для решения такого рода задач?
2.3. Знает ли кто-нибудь общие пути решения, ведь наша группа - далеко не первые, кто сталкнулись с такой ситуацией ?


Спасибо всем, кто дочитал это сообщение до конца
и надеюсь на вашу помощь.

Заранее благодарен,

Олег.
Аватара пользователя
AiK
Сообщения: 2287
Зарегистрирован: 13 фев 2004, 18:14
Откуда: СПб
Контактная информация:

Олег, готовых решений я не знаю (точнее не помню), но в Java есть куча способов, чтобы сделать один и тот же код разнофункциональным. Во-первых, банальный ООП.
Во-вторых, ООП не банальный :) Не помню как оно называется, но из области [object]factory...
Вот ты недавно по созданию XML документа постил. Там как раз DocumentBuilderFactory использовалась..., а для того, чтобы использовать другую имплементацию парсера тебе нужно изменить только одну константу...

В самом простом случае, твой модуль лицензирования устанавливает переменную окружения, которая говорит всем фабрикам, что нужно создавать продвинутые объекты. В более замороченных случаях юзаются Class loader'ы, а лицензия собственно содержит в закриптованном виде имена классов, которые нужно подгружать... а иногда и методы, которые нужно вызывать. Т.е. скачав триальную лицензию, ты используешь одни имплементации классов, а закачав платную - совсем другие, и никаких if'ов :) Как не трудно догадаться, с платной лицензией можно выдавать и дополнительный jar...

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

А бранчи ты помоему правильно понимаешь. Вот тебе пара ссылочке для старта :)
https://eclipse-tutorial.dev.java.net/e ... part2.html
http://www.eclipse.org/articles/Article ... ranch.html
Даже самый дурацкий замысел можно воплотить мастерски
Аватара пользователя
Oscar
Сообщения: 963
Зарегистрирован: 29 май 2004, 13:44
Откуда: Мюнхен (рожден в Киеве)
Контактная информация:

AiK, большое спасибо за быстрый и полезный ответ.

Про branches я почитал, как и думал, подойдёт.
Правда там есть такое понятие, как "слияние" (merge), а у нас и с банальным мерджем уже бывали проблемы,
так что сливать пару версий в одну - это может быть не просто ... но, думаю, разберёмся.
Ещё немного не понятно, какая разница между branches и versions, но тоже постараюсь разобраться.

Что касается Фабрик - то это очень хорошая идея, обязательно поговорю на ближайшей встрече с ребятами об этом.
Но ... ведь если взять примитивный случай, что я привёл (удалить один пункт из меню), то либо прийдётся вставлять в фабрике тот же if-else, либо же писать два метода создания полных меню с различием в одну строку ... как-то корявенько всё это мне представляется.

К тому же если выносить все версионные зависимости в один класс, - получится, что основная суть программы не то, что она должна делать, а то, как она должна продаваться ... А мне бы очень не хотелось делать нашу программу "рабом" лицензирования ...

JLock - криптирование, это то, что я писал под названием "uglifier" ? У нас уже есть какой-то (тоже платный, но не дорогой и в общем-то мы довольны), так что в этом проблемы нет.


Мне было бы интересно услышать мнения других участников форума, может у кого-то есть другой опыт решения данной (второй) задачи?
Аватара пользователя
AiK
Сообщения: 2287
Зарегистрирован: 13 фев 2004, 18:14
Откуда: СПб
Контактная информация:

Судя по названию (найти не могу), uglifier - это обычный обфускатор. Т.е. это несколько из другой оперы.
JLock - он первый в Гугле, описание почитай тут: http://www.jbitsoftware.com/JBitSoftware/jlockinfo.html
Там написано, чем он от обфускатора отличается.

Что же касается сокрытия пунктов меню, то это неправильная политика выпуска триальных версий.
Как правило человек принимает решение о покупке продукта именно на основании работы т.н. дополнительных фич. Грубо говоря, если меня не устраивает сортировка пузырьком, а других сортировок в триальной версии ты не предоставляешь, то у меня выбор только один - купить, а потом понять нужно мне это было или нет... А правильный вариант - дать возможность пользователю посортировать всеми методами, да только на тестовых, а не реальных данных :) Ну или по времени/количеству запусков ограничить.
А мне бы очень не хотелось делать нашу программу "рабом" лицензирования ...
Мысль здравая. Стоимость разработки защиты не должна превышать стоимости разработки программы :) Однако, сюда можно дополнительную функциональность навесить - апдейты/bugfixing малой кровью -высылаешь jar, который содержит только изменившийся класс и программа начинает использовать его взамен старого... Впрочем, ты говорил, что программа не большая и это не критично.
Даже самый дурацкий замысел можно воплотить мастерски
Аватара пользователя
Oscar
Сообщения: 963
Зарегистрирован: 29 май 2004, 13:44
Откуда: Мюнхен (рожден в Киеве)
Контактная информация:

да, я имел ввиду обфускатор.
потому про JLock обязательно почитаю.

второй пункт, наша особенность заключается в том, что нам не нужны тривиальные лицензии,
нам нужны мультилицензии: один editor и 10 viewer_ов (например).

То есть конечно же триал не помешал бы, но это не самая важна задача,
программа занимает (и рискну предположить, что довольно таки уверенно в своей области) определённую специфическую нишу
и реклама происходит скорее на выставках, через личные контакты, бесплатное распространение полнофункциональной версии (с большой надписью "scholar" на лбу) в ВУЗах (в частности MTI).

Ну а апгрейд - один новый файл раз в пол года или много миниатюрных каждый месяц - это не суть важно пока что.
Ответить