Comments on TDelphi: будни Delphi блоггера: Переход на юникод 1: Поиск стратегии.

cemick: > потому что новая версия задаро...

2011-06-16T17:56:34.284+03:00

cemick:
> потому что новая версия задаром клиенту слишком жирно
Ага. =)

Сколько раз я ни пробовал работать в SVN с ветками, столько раз сталкивался с тем, что не всегда получается корректно перенести изменения из одной ветки в другую (часто случаются такие конфликты, что намного проще скопировать код руками, чем резолвить конфликты). Я сейчас говорю о случае, когда обе ветки редактируются независимо друг от друга. Особенно, если код был подвергнут жёсткому рефакторингу и были затронуты несколько модулей. Ещё хуже дело обстоит если по ходу дела менялись dfm-ки. Но это так... устаревшие впечталения, пары лет тому назад.

Анонимный:
Вариант с переходом на TNT вообще не рассматривался. По причине того, что в проекте используется слишком много сторонних библиотек. Я так понимаю, их пришлось бы переводить самим, лезть в исходный код и заменять стандартные классы на TNT аналоги. Это было бы слишком трудозатратно. Да и править чужой код всё ещё развивающихся продуктов - это заранее подписать отказ от всех возможных обновлений.

Если я правильно понял постановку задачи (переход ...

2011-06-11T20:24:56.335+03:00

Если я правильно понял постановку задачи (переход на юникод, а не на Дельфи ХЕ), то могу предложить еще один вариант стратегии - оставаясь в Д-6, сделать юнкод в существующем проекте подключая дополнительные пакеты компонент.
Например TNT unicode components
http://www.yunqa.de/delphi/doku.php/products/tntunicodecontrols/index?DokuWiki=4d2c3soj4qnetmsg8ba8s71fv6

>И через год может вясниться, что какая-то мело...

2011-06-07T00:17:29.892+03:00

>И через год может вясниться, что какая-то мелочь делает работу с программой невозможной.

Дак заморозка stable не создает не возможность какого то допиливания. Просто это будет проходит в отдельном бранче. Ну и как бы я за третий вариант, и как мне видится оба минуса нивелируется системой контроля версий, при правильном использование: http://www.gnuman.ru/stuff/svn_strateg/. У нас такая же специфика, баг часто обнаруживается спустя год после выпуска фичи, и править нужно именно в предыдущей версии компонента, потому что новая версия задаром клиенту слишком жирно, или просто нет возможно апгрейда. Плюс переход наверняка принесет кучу багов, и какое то продолжительное время не будет стабильной юникодной версии, тогда бы хотелось иметь всегда возможность добавить фичу или пофиксить баг в проверенной стабильной версии.

> а текущая версия на D6 замораживается на sta...

2011-06-06T20:06:43.366+03:00

> а текущая версия на D6 замораживается на stable.

Я конечно за, но к сожалению невозможно заморозить версию на 100%. В силу организационных моментов. Что-то всё-равно придётся дописывать и в старой версии, хотя бы просто для того, что с новой фичей удастся сэкономить кучу человекочасов коллег. Просто для того, чтобы клиент был удовлетворён. Это корпоративный сектор. Здесь между моментом покупки и моментом внедрения может пройти год. И через год может вясниться, что какая-то мелочь делает работу с программой невозможной. И эту мелочь придётся исправлять или даже переделывать. Просто для того, чтобы клиент был доволен тем за что выложил кучу денег и не ушёл к конкурентам. Как-то так я это вижу.

>>Но со временем придётся всё чаще исправлят...

2011-06-06T19:54:18.130+03:00

>>Но со временем придётся всё чаще исправлять одни и те же ошибки в двух разных местах. Этот вариант даёт возможность получить результат раньше. Но в случае необходимости сопровождать и развивать и старый и новый код, начнёт требовать в 2 раза больше

Для этого и есть различные CVS. Все равно же переход выполняется в новом бранче, а текущая версия на D6 замораживается на stable. Ни каких копипастов, старая версия только фиксы багов.

2 Анонимный: > 1-й - это Ад. Слишком тру...

2011-06-05T13:58:30.356+03:00

2 Анонимный:
> 1-й - это Ад. Слишком трудоёмкий.
Вот не соглашёсь. Самое трудоёмкое - это заставить код программы одинаково работать с разными библиотеками в разных версиях. И то, самая трудоёмкая часть - это написать свою прокладку для общения с такими библиотеками, создав иерархию абстрактных базовых классов и сделав конкретную реализацию для конкретной библиотеки. Для меня 1й вариант, выглядит намного проще чем, предложенный вами, 4й вариант.

>3-й ничё так, куча Копипастов, куча ошибок...
Копипасты, ошибки. И старая версия отстаёт в развитии, так как ей уделяется всё меньше и меньше внимания.

> Я бы Вам предложил 4-й вариант (что-то между 2 и 3).
> Вы берёте свой большой проект, и делите на логич.блоки: A,Б,В1,В2, ...

Разумеется мы рассуждаем об абстрактном. Но я вообще не представляю как такой подход можно применить в моём конкретном приложении. Слишком много лет его писали разные люди. Слишком много зависимостей внутри кода. Для нормальной работы в таком духе придётся разделить между приложениями кучу внутренних настроек, подключение к БД, транзакции, открытые датасеты. Возможно даже основные формы.
И сама идея отказа от MDI вызывает у меня ужас. Просто потому, что всё-равно придётся что-то подобное реализовывать самому.

В этом плане, 1й вариант, выглядит намного проще в реализации.

Bozhko
> Выпуск юникодовой версии означает отказ от сопровождения неюникодовой. Тот же MS как-то не сильно сопровождает Win98..
MS сопровождал свою Win98 ещё лет 5 или 8 после выпуска.
Ведь есть такая вещь, как гарантия на сопровождение купленной версии. В случае отказа от сопровождения старой версии, клиентам имеющим действующую гарантию на старую версию, придётся предоставлять новую. Слишком щедрый подарок.

Выпуск юникодовой версии означает отказ от сопрово...

2011-06-05T09:00:39.154+03:00

Выпуск юникодовой версии означает отказ от сопровождения неюникодовой. Тот же MS как-то не сильно сопровождает Win98...

Так, что, ИМХО, разумно пойти по третьему варианту и затем потихоньку свернуть старую версию...

1-й - это Ад. Слишком трудоёмкий. Либо программист...

2011-06-05T01:16:58.878+03:00

1-й - это Ад. Слишком трудоёмкий. Либо программист должен быть фанатичный.
2-й как верно подметили тупиковый, не у каждого бизнеса(заказчика) хватит терпения ждать без результатов. Из моего опыта они не доходят до конца, и в итоге через время, у вас 2 проекта новый не работает, старый морально отстал, из-за недостатка внимания.
3-й ничё так, куча Копипастов, куча ошибок...

Я бы Вам предложил 4-й вариант (что-то между 2 и 3).
Правда придётся кой чем пожертвовать..
Начать разрабатывать с 0 новый exe. Но работать они будут одновременно. (не EXE и DLL а 2 EXE)

-на 1 клиента 2 коннекта к базе, ...
-придётся написать некую подсистему взаимо-понимания.
-если MDI интерфейс, придётся о нём забыть
+В случае неудачи, Ваши риски малы, у вас всегда рабочая система
+всё остальное

Вы берёте свой большой проект, и делите на логич.блоки: A,Б,В1,В2, ... Далее прорабатывайте приоритеты и зависимости. Далее реализовывайте в новом A, в старом удаляете(не заглушки, прям юниты из проекта, чтоб контролировать зависимости) А, реализовывайте Б, в старом удаляете Б, ... . пока старый не помрёт.

По поводу взаимодействия:
* ShellExecute с параметрами
* CreateProcess, WaitForSingleObject
* CreateFileMapping, MapViewOfFile
* RegisterWindowMessage, SendMessage

(пример EMS МенеджСтудио, раз. блоки вызывают(запускают) другие, у них общие настройки, реестр,...)

> Переписывание "с нуля" - всегда туп...

2011-06-04T23:54:55.346+03:00

> Переписывание "с нуля" - всегда тупиковый вариант.
Не всегда. Для небольших приложений, при 100% пониманию того, как всё должно работать и излишне замудрённом исходном коде иногда проще переписать заново. Но, согласен, в крупных программах это путь в тупик.

> Какая Пользователю разница - д6 или д2010?
Разница в том, что в одной версии есть юникод, а в другой нет. А получить юникодную могут только те пользователи, кто заплатили за апгрейд. Остальные же, при наличии подписки на сопровождение могут требовать только исправления ошибок в приобретённой версии.

Пара комментариев. Первый - по предмету статьи. ...

2011-06-04T19:46:11.566+03:00

Пара комментариев.

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

Второе - не совсем уверен в смысле существования двух параллельных версий. Какая Пользователю разница - д6 или д2010? Для него это при любом раскладе будет win32 приложение! Мы же не говорим о разных платформах - мак, iOS, etc.