Блог

У нашей компании есть программное обеспечение, которое разрабатывается более 10 лет, так что там есть кое-что действительно устаревшее. Он по-прежнему довольно функционален и все такое, но я вижу новые функции в Delphi XE, и это вызывает у меня желание переключиться. Проблема в том, что сам исходный код содержит более 300 мб файлов .pas (всего 1 ГБ с компонентами и т.д.).

Мы используем пользовательские компоненты, старые материалы jvcl и последнюю версию devexpress.

Насколько сложно я могу ожидать, что все будет, если я решу перейти с Delphi 7 на Delphi XE?

Спасибо.

Единственная реальная проблема — это преобразование в Unicode. Вам следует узнать, как реализована поддержка Unicode в Delphi — начните с технического документа Марко Канту: Delphi и Unicode

Невозможно оценить объем работы, необходимый для обновления старых приложений до Unicode, не зная фактического кода. Если бы вы использовали строковые типы стандартным способом, преобразование было бы простым. Любые низкоуровневые трюки со строковыми типами (например, хранение двоичных данных в строках) теперь устарели, и соответствующий код следует переписать.

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

Однако, если ваша кодовая база настолько огромна, как вы объясняете, вам не следует полностью полагаться на то, что кто-либо здесь собирается вам сказать. Просто получите копию XE и загрузите код. Посмотрите, с какими проблемами вы столкнетесь, чтобы получить представление о том, каких усилий это потребует.

На данный момент я перенес весь свой код на XE (даже старые проекты). Я по возможности повторно использую одни и те же библиотеки, поэтому, как только я конвертировал большинство из них, «перенос» приложений с Delphi 7 на Unicode Delphi обычно был просто повторяющейся задачей либо для работы с обновленными интерфейсами в библиотеках, либо для исправления ошибок компилятора и предупреждений.

Наиболее распространенные ошибки, с которыми я сталкивался:

• Материал в Юникоде. Это займет 90% времени. Раздражает, если код выполняет много низкоуровневой обработки строк, но большинство проблем можно легко исправить, добавив несколько приведений типов.

• компилятор отказывает при использовании c in ['a'..'z'] . Предполагается, что вы используете CharInSet() для строк в юникоде.

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

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

Вы упомянули SQL в одном из ваших комментариев к ответу… Поддерживает ли ваша база данных Unicode? В противном случае вам может потребоваться много работы. Возможно, вам потребуется конвертировать базы данных «на лету» или создать инструмент преобразования для ваших пользователей. Возможно, вам потребуется обновить базу данных или даже переключиться на что-то другое. Например, DBISAM не поддерживает unicode, но поставщик создает ElevateDB, который поддерживает. Переход не является тривиальным. И некоторые другие библиотеки, такие как Hyperstring, написанные в основном на ассемблере, являются еще одним больным местом.

Я выполнил довольно много таких преобразований.

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

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

Наконец, есть менее важные, но потенциально очень трудоемкие аспекты:

• если вы используете BDE, самое время избавиться от него
• Delphi XE более строгий, чем Delphi 7
• версии библиотек сторонних разработчиков, которые расширяют довольно много версий и обычно гораздо менее совместимы с обратной связью, чем VCL

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

В моем проекте около миллиона строк кода, и я недавно перенес его с CB9 на XE. Чтобы сократить объем работы, я сначала многое переписал, чтобы больше не зависеть от пакетов компонентов сторонних производителей, затем тщательно просмотрел все, что связано со строками (unicode), и только после этого перешел на XE. Подготовка потребовала большой работы, фактический перенос был относительно простым.

Безусловно, выполнить эту МИГРАЦИЮ непросто. Но требуется хорошее ПЛАНИРОВАНИЕ!

Сначала нам нужно найти все возможные компоненты, которые также необходимо перенести вместе с кодом. Если в проекте Delphi7 используются сторонние компоненты, которые недоступны, то дальнейшее продвижение довольно сложно. Во-вторых, другое преобразование типов, связанное с Unicode, что довольно просто. И, наконец, конечно, нам нужно установить другие поддерживающие библиотеки, BDE и адаптеры баз данных.

Для расширенного пользовательского интерфейса можно использовать Delphi FireMonkey.

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