Диагностирование наследия.NET

1. Восприятие пользователей

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

Я бы хотел задать такие вопросы, как:

• Работает ли он плавно?
• Легко ли им пользоваться?
• Когда вы его используете, чувствуете ли вы уверенно , что это Делаете то, что ожидаете?
• Это BMW, Civic или Pinto?

Ответы будут субъективными. Это нормально. На данный момент мы просто ищем общие тенденции. Если подавляющее количество пользователей говорит, что он постоянно дает сбой или что они боятся выполнять базовые задачи, то у вас проблемы.

Если приложение порождает суеверие , и вы слышите такие вещи, как «кажется, что в четверг утром оно не работает» или «Я не знаю, что делает эта кнопка, но она не работает, если я щелкни сначала ", беги в холмы.

2.Документация

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

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

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

3. Тесты

Нет лучшего способа оценить работоспособность приложения, чем его собственные тесты, если они доступны. Модульные тесты, покрытие кода, интеграционные тесты, даже ручные тесты - здесь работает все, что угодно. Чем полнее набор тестов, тем больше шансов на исправность системы.

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

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

4. Статический анализ

Некоторые из вас, вероятно, сразу же подумали «FxCop». Еще нет. Первое, что я сделаю, это выделю NDepend .

Просто беглый взгляд на дерево зависимостей приложения даст вам огромный объем информации о том, насколько хорошо разработано приложение. Большинство худших антипаттернов дизайна - Big Ball of Mud , Circular Dependencies , Spaghetti Code , God Objects - будут видно почти сразу с высоты птичьего полета зависимостей.

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

После я убедился, что общий дизайн / архитектура не является полным мусором, затем я бы посмотрел на FxCop . Я не воспринимаю его вывод как евангелие, но меня особенно интересуют Предупреждения о проектировании и Предупреждения об использовании (предупреждения безопасности также являются красным флажком, но очень редко).

5.Анализ времени выполнения

На этом этапе я уже удовлетворен тем, что приложение на высоком уровне не является огромной грудой отстой. Этот этап может немного отличаться в зависимости от конкретного приложения под микроскопом, но можно сделать несколько полезных вещей:

• Сначала записать все -случайные исключения при нормальном запуске. Это поможет измерить надежность приложения, чтобы увидеть, не проглатывается ли слишком много исключений или используются ли исключения для управления потоком. Если вы видите много экземпляров верхнего уровня Exception или SystemException производных, будьте осторожны.

• Запустите его через профилировщик, например EQATEC . Это должно помочь вам довольно легко определить любые серьезные проблемы с производительностью. Если приложение использует серверную часть SQL, используйте инструмент профилирования SQL для отслеживания запросов. (На самом деле есть отдельные шаги для проверки работоспособности базы данных, что является важной частью тестирования приложения, основанного на ней, но я не хочу уходить слишком далеко от темы).

• Понаблюдайте за несколькими пользователями - особенно обратите внимание на «ритуалы», то, что они делают без всякой причины. Обычно они являются признаком того, что у вас остались жуки и тикают бомбы замедленного действия. Также посмотрите, не генерирует ли он много сообщений об ошибках, не блокирует ли пользовательский интерфейс на длительные периоды времени, «думая», и так далее. По сути, все, что вы лично не хотели бы видеть в качестве пользователя.

• Стресс-тесты. Опять же, конкретные инструменты зависят от приложения, но это особенно применимо к серверным приложениям. Посмотрите, может ли приложение работать при большой нагрузке. Если тайм-аут начинается около предельного значения, это нормально; если он начинает генерировать странное сообщение об ошибке или, что еще хуже, кажется, что данные или состояние повреждены, это очень плохой знак.

И это все, о чем я могу сейчас думать. Я обновлю, если еще что-нибудь придет в голову.