Как оценить процесс 64-битной миграции Си/Си++ приложений?

Источник: realcoding

Статья посвящена вопросу оценки сложности и стоимости переноса приложений на 64-битные платформы. Рассматриваются такие аспекты, как доступность тех или иных компонентов приложения, библиотек, средств разработки. Приводится пример использования программного продукта PVS-Studio для оценки миграции. Хотя упомянутый продукт PVS-Studio ориентирован на Си и Си++ приложения в системе Windows, статья также будет полезна разработчикам под Unix и другими системами.

Аннотация

Введение

Фразой "не за горами тот день, когда все разработчики должны будут выпустить 64-битные версии своих приложений" я начинаю многие свои статьи еще с 2006 года, хотя на момент написания статьи подходит к концу год 2009. Жизнь показала, что я не прав. Тот день "за горами". До сих пор очень многие компании так и не выпустили 64-битных версий продуктов. Отчасти этому способствует политика компании Microsoft, которая одинаково успешно зарабатывает деньги как на продаже 32-битных версий Windows, так и 64-битных. Отчасти - тем, что далеко не всем приложениям действительно необходимо иметь 64-битные версии.

Однако по моему опыту общения с людьми, ответственными за принятие решений о необходимости разработки 64-битных версий приложений, я понял, что главным сдерживающим фактором является очень простая вещь. Многие люди просто не знают, как оценить время и стоимость процесса миграции приложения на 64-битную архитектуру. Соответственно, это незнание заставляет их откладывать процесс переноса кода на максимально возможный срок.

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

Статья основа на опыте сотрудников компании ООО "СиПроВер" как по переносу различных приложений на 64-битные системы, так и по практике применения анализатора кода PVS-Studio.

"Хьюстон, Хьюстон. Разрешите старт!"

Настоящая статья посвящена оценке процесса миграции, а не самому процессу миграции. Поэтому желающим более детально изучить такой вопрос будет интереснее ознакомиться со статьей "7 шагов по переносу программы на 64-битную систему" [2]. Тем не менее, здесь я использую некоторые положения из той статьи. Прежде чем оценивать нюансы миграции, надо иметь четкие ответы на следующие вопросы:

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

Если вы ответили на все эти вопросы "да", то перед вами встает основной вопрос, вынесенный в заголовок статьи.

"Как же оценить процесс 64-битной миграции?"

Итак, у вас есть несколько (десятков) мегабайт исходного кода, готового к миграции. Конфигурации для сборки 64-битного кода пока нет, ни одного компилирующегося в 64-битном режиме модуля, соответственно, тоже. Но прочитав статью "20 ловушек переноса Си++ - кода на 64-битную платформу" [4], вы понимаете, что процесс поиска всех скрытых в коде ошибок будет непростым.

Для того чтобы понять, насколько непростым будет поиск всех ошибок, можно использовать статический анализ кода. Существуют разные анализаторы кода (сравнение анализаторов кода [3]), которые можно использовать при поиске проблем в 64-битном коде, но в моей статье я остановлюсь на анализаторе кода PVS-Studio, поскольку именно его разрабатывает наша компания.

Итак, в PVS-Studio 3.30 появилась возможность обнаружения проблем 64-битного кода даже в 32-битных проектах. Именно эта возможность и позволить оценить сложность миграции ДО этапа создания 64-битной конфигурации проекта. Ранее анализатор PVS-Studio позволял проверять проекты только в 64-битной конфигурации.

Я хочу обратить внимание читателей на то, как работает проверка кода в 32-битном режиме. Прежде всего, вы должны понимать, что эта проверка, конечно же, не может считаться полноценной проверкой, и исправление даже всех обнаруженных проблем не является гарантией работоспособности кода в 64-битном режиме. Ведь в коде любого серьезного приложения будут подобные фрагменты:

Естественно, при проверке в 32-битном режиме подобный код будет пропущен. Вернее будет сказать так: на момент, когда 64-битной конфигурации пока еще нет, такого кода в приложении может не быть. А когда он появится, его могут "забыть" проверить.

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

Однако сильно ли будут различаться эти результаты? По результатам экспериментов, проведенных в нашей компании, мы получили следующие данные: списки диагностических сообщений от анализатора кода PVS-Studio при проверке проектов в 32-битном и в 64-битном режимах совпадают на 95-97%! Это означает, что отличаются не более 5% диагностических сообщений. Эти результаты были получены следующим образом: мы взяли код реальных проектов, проверили его в 32-битном режиме, сохранили список обнаруженных проблем. Затем проверили код этих же проектов в 64-битном режиме, сохранили список обнаруженных проблем. После чего сравнили полученные списки и определили, сколько процентов диагностических сообщений совпало. Поскольку вся процедура делалась в автоматизированном режиме, то количество проанализированных проектов было достаточным (больше 20 проектов с объемом кода в несколько мегабайт каждый). Следовательно, эти цифры внушают доверие.

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

Для получения оценки времени рекомендую поступить следующим образом:

Выполнить анализ 32-битной конфигурации проекта с помощью PVS-Studio.
В течение одного дня программист, понимающий проблемы 64-битного кода, просматривает сообщения анализатора кода и принимает решение о том, актуальна ли данная ошибка для данного проекта или нет.
Общее количество сообщений от анализатора кода делится на количество проанализированных и обработанных программистом сообщений за день.
Полученное число - это количество человеко-дней, необходимое для миграции кода приложения на 64-битную платформу.

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

Вот несколько рекомендаций по выбору такого программиста:

Он должен быть опытным программистом со стажем работы не менее трех лет и желательно со знанием конкретного проекта, который будет портироваться.
Он должен быть знаком с проблемами 64-битного кода. Упоминавшаяся уже ранее статья "20 ловушек переноса Си++ - кода на 64-битную платформу" [4] - хороший источник информации по теме.
Желательно, чтобы он понимал принципы работы со статическими анализаторами кода. Это необязательное требование, но понимание технологии статического анализа кода делает оценку процесса миграции более адекватной.

Соблюдение этих рекомендаций позволит получить адекватную оценку стоимости и времени процесса 64-битной миграции приложений.

Заключение

Для лучшего понимания этой статьи следует учитывать несколько моментов:

Ни один инструмент (в том числе и PVS-Studio) не может выдавать каких-либо оценок. Оценку всегда выдает человек. Иногда с применением инструментов, иногда - без них.
Анализатор кода PVS-Studio не предназначен для оценки процесса 64-битной миграции, он не выдает оценки в часах (днях, месяцах). Это инструмент, выявляющий потенциальные ошибки в 64-битном коде. Но на основе такой информации (при проверке 32-битного проекта) человек уже может давать оценки трудозатрат по переносу проекта.
Качество оценки зависит от человека.

Желаю успешной оценки 64-битной миграции кода и надеюсь, что инструмент PVS-Studio вам в этом поможет.

Ссылки по теме