По моему опыту, подавляющее большинство приложений предоставляют множество "неизвестных" функций. Ведь причина, по которой мы пишем программное обеспечение, состоит в том, чтобы помочь нам управлять информацией способами, которые неизмеримо превосходят наши способности как простые морали. Со временем размер и сложность нашего программного обеспечения растет, растет и растет до тех пор, пока оно не содержит огромное количество «неизвестных» функций. Неизвестная функциональность была, вероятно, известна и проверена как «правильная» когда-то, и она была детально отражена в исходном коде. Однако с течением времени никто полностью не помнит / не знает, что такое весь функционал или даже почему он «правильный». Полная функциональность только «запоминается / известна» из исходного кода, команды «проверяют, что они меняют», а все остальное считается правильным, если только проблема не обнаруживается. Это особенно верно для систем, которые были расширены и изменены многими людьми в течение многих лет. Конечно, это создает риск, и мы можем добиться большего успеха, такие процессы, как TDD и инструменты для автоматизации модульного тестирования, помогают, но для многих старых систем отсутствие понимания системы и неполное тестирование являются фактами жизни. Техническому идеалисту во мне это не нравится, но бизнес-реалист во мне это принимает.
Все это говорит о том, что это представляет серьезную проблему для групп миграции. Теоретически эти команды «все меняют». В миграции с VB6 на .NET «Проверить, что мы изменили» означает проверить все это. Уч. Кроме того, функциональные требования для миграции часто заключаются в том, чтобы «просто заставить ее делать то, что она делает сейчас, но на новой платформе». Не очень полезно, когда люди не знают / не запоминают все, что делает система, не говоря уже о том, как проверить, что она делает это правильно. Я работаю с несколькими заказчиками, у которых есть огромные приложения VB6, содержащие сотни тысяч LOC, организованных в сотни или формы и классы и несколько тысяч методов, свойств и обработчиков событий. Я уверен, что эти приложения содержат десятки тысяч функциональных точек. Я хотел бы спросить команды по миграции, сколько времени им потребуется, чтобы найти ошибку, если я зайду в VB6 и "сломаю" одну маленькую вещь где-нибудь. Я редко получаю ответ ...
Вот почему я рекомендую использовать методологию переписывания с помощью инструмента. Одним из наиболее важных входных данных для этого процесса является проверенный на производстве исходный код. Мы предполагаем, что этот код является «правильным», поскольку вы или ваши клиенты работают над этим. Исходный код является чрезвычайно подробным, формальным и полным ответом на вопрос: что делает система ? В нашем подходе группа миграции итеративно настраивает, калибрует и проверяет автоматический, систематический перевод и реинжиниринг источника VB6 в полный источник .NET. Мы переводим, тестируем, настраиваем и повторяем; каждый раз улучшая качество перевода с точки зрения функциональной корректности и соответствия стандартам кодирования .NET. Проверка и уточнение того, что делает инструмент, является центральной в методологии.
Для проверки качества кода мы используем обзоры кода и «параллельное» тестирование. Обзоры кода выполняются путем проверки кода .NET с использованием глаз и других инструментов, таких как компилятор .NET, FXCop, NDepends и т. Д. Мы также много сравниваем последовательные поколения переведенных кодов, используя такой продукт, как BeyondCompare, чтобы убедиться каждое изменение настройки перевода имеет желаемый эффект и не вызывает нежелательных побочных эффектов. Параллельное тестирование - это то, на что это похоже: общая идея - запустить устаревшие приложения и приложения .NET в среде параллельного тестирования и убедиться, что их результаты и поведение соответствуют. Здесь есть как минимум пара проблем:
- что вы делаете, когда запускаете приложение; и
- как убедиться, что результаты и поведение совпадают?
На первый вопрос обычно отвечают данные испытаний, варианты использования и автоматизированные модульные тесты; на второй вопрос дан ответ с точки зрения просмотра пользовательского интерфейса приложения и результатов (данных, веб-страниц, отчетов) обеих систем и сравнения (так называемое тестирование, основанное на утверждении). Конечно, инструменты тестирования могут иметь большое значение для повышения эффективности. Масштабная миграция - очень хорошее время для обсуждения начала использования инструментов тестирования.
Если вы планируете перенести большую сложную кодовую базу, вам нужно быть очень умным в тестировании. Если все сделано правильно, инструментальный подход очень эффективно доставляет готовый код, и это высвободит ресурсы для создания артефактов контроля качества и улучшения процессов контроля качества, которые будут существовать еще долго после миграции.
Отказ от ответственности: я работаю на Великих Миграций.