Як оцінити процес 64-бітної міграції Сі / Сі + + додатків?, Різне, Програмування, статті

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

Анотація


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


Введення


Фразою “не за горами той день, коли всі розробники повинні будуть випустити 64-бітові версії своїх програм” я починаю багато свої статті ще з 2006 року, хоча на момент написання статті добігає кінця рік 2009. Життя показало, що я не прав. Той день “за горами”. До сих пір дуже багато компаній так і не випустили 64-бітових версій продуктів. Частково цьому сприяє політика компанії Microsoft, яка однаково успішно заробляє гроші як на продажу 32-бітових версій Windows, так і 64-бітних. Частково – тим, що далеко не всім додаткам дійсно необхідно мати 64-бітові версії.


Однак з мого досвіду спілкування з людьми, відповідальними за прийняття рішень про необхідність розробки 64-бітових версій додатків, я зрозумів, що головним стримуючим фактором є дуже проста річ. Багато людей просто не знають, як оцінити час і вартість процесу міграції додатки на 64-бітову архітектуру. Відповідно, це незнання змушує їх відкладати процес перенесення коду на максимально можливий термін.


У даній статті я розповім про один із способів, які дозволяє оцінити цей процес до початку міграції. Адже точно сказати, скільки часу займає міграція конкретного додатка, можна тільки після того, як ця міграція виконана.


Стаття основа на досвіді співробітників компанії ТОВ “СіПроВер” як з перенесення різних додатків на 64-бітові системи, так і з практики застосування аналізатора коду PVS-Studio.


“Х’юстон, Х’юстон. Дозвольте старт!”


Ця стаття присвячена оцінці процесу міграції, а не самого процесу міграції. Тому бажаючим більш детально вивчити таке питання буде цікавіше прочитати статтю “7 кроків по перенесенню програми на 64-бітну систему “[2]. Тим не менш, тут я використовую деякі положення з тієї статті. Перш ніж оцінювати нюанси міграції, треба мати чіткі відповіді на наступні питання:



  1. Чи необхідно виконувати саме міграцію коду на 64-бітові системи або ж достатньо, щоб 32-бітне додаток працювало на 64-бітної операційної системи?

  2. Чи підтримує використовуване в проекті засіб розробки генерацію 64-бітного коду?

  3. Чи існують 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-бітна конфігурація. А ось оцінити, скільки буде потрібно часу для розбору повідомлень від аналізатора коду, цілком можливо.


Для отримання оцінки часу рекомендую поступити наступним чином:



  1. Виконати аналіз 32-бітної конфігурації проекту за допомогою PVS-Studio.

  2. Протягом одного дня програміст, що розуміє проблеми 64-бітного коду, переглядає повідомлення аналізатора коду і приймає рішення про те, чи актуальна ця помилка для даного проекту чи ні.

  3. Загальна кількість повідомлень від аналізатора коду ділиться на кількість проаналізованих та оброблених програмістом повідомлень за день.

  4. Отримане число – це кількість людино-днів, необхідне для міграції коду програми на 64-бітну платформу.

Зрозуміло, в даному алгоритмі оцінки процесу міграції є слабке місце – це програміст, який буде протягом одного дня розбирати повідомлення від аналізатора коду. Тому я рекомендую дуже серйозно підійти до призначення програміста, відповідального за оцінку.


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



  1. Він повинен бути досвідченим програмістом зі стажем роботи не менше трьох років і бажано зі знанням конкретного проекту, який буде портувати.

  2. Він повинен бути знайомий з проблемами 64-бітного коду. Згадувана вже раніше стаття “20 пасток перенесення Сі + + – коду на 64-бітну платформу” [4] – хороше джерело інформації по темі.

  3. Бажано, щоб він розумів принципи роботи зі статичними аналізаторами коду. Це необов’язкове вимога, але розуміння технології статичного аналізу коду робить оцінку процесу міграції більш адекватною.

Дотримання цих рекомендацій дозволить отримати адекватну оцінку вартості і часу процесу 64-бітної міграції додатків.


Висновок


Для кращого розуміння цієї статті слід враховувати кілька моментів:



  1. Жоден інструмент (у тому числі і PVS-Studio) не може видавати будь-яких оцінок. Оцінку завжди видає людина. Іноді із застосуванням інструментів, іноді – без них.

  2. Аналізатор коду PVS-Studio не призначений для оцінки процесу 64-бітної міграції, він не видає оцінки в годинах (днях, місяцях). Це інструмент, що виявляє потенційні помилки в 64-бітному коді. Але на основі такої інформації (при перевірці 32-бітного проекту) людина вже може давати оцінки трудозатрат по перенесенню проекту.

  3. Якість оцінки залежить від людини.

Бажаю успішної оцінки 64-бітної міграції коду і сподіваюся, що інструмент PVS-Studio вам в цьому допоможе.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*