Переход на юникод 1: Поиск стратегии.

Обещанная статья о переводе большой программы с Delphi 6 на Delphi 2010 (для Delphi 2009 и Delphi XE (2011), ситуация будет аналогичной). Материала получилось довольно много, поэтому я разобью его на несколько постов.

Дано

Большое приложение, с большой базой данных и большой историей. Приложение, которое начали разрабатывать ещё на Delphi 3, потом портировали на Delphi 6. Теперь надо ввести поддержку юникода, и собрать в Delphi 2010. Приложение использует кучу пакетов как самописных, так и от сторонних производителей. Проект большой, комментариев в коде практически нет. Юнит-тесты написаны только для очень маленькой части кода общих библиотек.

Что надо получить?

Работающую версию программы с поддержкой юникода для D2010. Из-за большого числа клиентов, крайне желательно, чтобы обновлению программы (включая базу данных) с неюникодной версии на юникодную происходило по возможности безболезненно. В идеале сделать так, чтобы с одной и той же базой данных можно было работать как из уникодной версии программы так и из Ansi-версии.

Необходимо поддерживать и развивать существующую версию (на Delphi 6), исправляя найденные баги и расширяя функционал. А баги будут на сто процентов. Всё-таки баги в программах появляются также ожидаемо как глисты у собак летом.

Стратегии перехода

Стратегии для перехода на Юникод:

1. Сделать так, чтобы один и тот же код мог собираться как в Delphi 6, так и в Delphi 2010 и чтобы программа работала стабильно и без ошибок.
2. Начать проект с нуля только на Delphi 2010, частями перенося код из версии для D6.
3. Сделать копию стабильной версии проекта и вести работу по переходу на юникод на копии, оставляя нетронутой стабильную версию для Delphi 6.

Плюсы и минусы стратегий

Вариант 1. Общий код для Delphi 6 и Delphi 2010.

• + Одна база кода. Не придётся исправлять одну и ту же ошибку и Delphi 6 и в Delphi 2010.
• + Все нововведения, одновременно доступны как в версии для D6 так и в версии для D2010
• + Юнит-тесты достаточно написать один раз, а собирать и запускать их можно как в Delphi 6, так и в Delphi 2010.
• - Есть риск, что после какого-либо изменения, нестабильной окажется либо одна из веток программы
• - После каждого изменения кода необходимо собирать и тестировать программу в 2х вариантах. Без юникода и с. Впрочем, до релиза юникодной версии достаточно тщательно проверять только неюникодную версию.
• - Придётся обновить библиотеки, стабильно работавшие в Delphi 6, только для того, чтобы использующий их код можно было скомпилировать в Delphi 2010.
• - Сложности, если в версии для Delphi 6 и в версии для Delphi 2010 придётся использовать разные версии компонентов. Например, если в D6 в коде используется RxLib, а в Delphi 2010 вместо них JVCL. Придётся писать дополнительный код, для поддержания такой работы.
• - Придётся тащить с собой весь устаревший код или переписывать.

Вариант 2. Начать с нуля.

• + Можно избавится от устаревшего кода.
• + Можно не разбираться в неизвестном коде.
• - Придётся досконально разобраться в бизнес логике программы, которая, скорее всего, нигде не задокументирована.
• - Высок риск потерять большую часть функционала, из-за недостаточного понимания всех нюансов работы программы. Риск увеличивается, при частом использовании обработчиков событий.
• - Новый проект всегда будет работать не так как раньше.
• - Придётся вести 2 версии кода.

Вариант 3. Отдельные ветки для D6 и D2010.

• + Можно избавиться от устаревшего кода.
• + При переходе не придётся заботится об обратной совместимости с Delphi 6.
• + Не придётся обновлять библиотеки в версии для Delphi 6. Достаточно будет установить последние версии только для Delphi 2010.
• - Старые ошибки придётся исправлять в двух версиях программы. Как показывает практика, рано или поздно случается так, что какие-то из ошибок забывают исправить в одной из версий программы. И через какое-то время их приходится исправлять повторно.
• - Нововведения, придётся вводить также в двух разных версиях программ.

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

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

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

В следующем посте я подробнее остановлюсь на плане перехода и расскажу об опыте обновления сторонних библиотек.