Диагностика .NET Legacy

Ответ 1

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

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

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

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

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

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

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

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

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

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

3. Испытания

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

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

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

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

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

Просто быстрый просмотр дерева зависимостей приложения даст вам огромное количество информации о том, насколько хорошо приложение разработано. Большинство худших дизайнов против шаблонов - Большой шар грязи, Циркуляр Зависимости, Код спагетта, Объекты Бога - будут видны почти сразу же с высоты птичьего полета над зависимостями.

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

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

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

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

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

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

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

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

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

Ответ 2

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

• Доволен ли пользователь этим?
• Является ли он стабильным?
• Является ли он надежным?
• Быстро ли это?
• Является ли срок хранения памяти стабильным в течение длительного времени и что я ожидаю?

Если ответ на все 5 из этих вопросов да, то у вас есть здоровое приложение. Я бы сказал, что 1-3 действительно самые важные. Это может быть не очень красиво внутри, и, возможно, прямое прикладом уродливое, но оно здорово, если оно соответствует этим спецификациям и должно навсегда оставаться в унаследованном режиме (то есть небольшие исправления)

Ответ 3

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

Еще одна приятная вещь - запустить стандартные задачи через ANTs Profiler из RedGate или dotTrace от Jetbrains. Он расскажет вам, что нужно потратить время и сколько раз оно было запущено, что означает, что вы можете увидеть, где можно оптимизировать/кэшировать.

Если вы используете NHibernate, тогда NHProf отлично (или я думаю, что Ayende выпустил UberProf, который охватывает больше стратегий доступа к БД). Это предупредит вас любой глупый доступ к БД продолжается. В противном случае с помощью профилировщика SQL Server может появиться запрос на повторную загрузку одних и тех же данных, но потребуется больше усилий, отфильтровывая мусор. Если вы в конечном итоге используете это, вы можете сохранить его в таблице DB, которую вы затем можете запросить более интеллектуальным способом.

Если вы ищете надежность, хорошо использовать стратегию ведения журнала - поймайте все исключения и запишите их. Это достаточно просто настроить с помощью log4net. Также регистрируйтесь, если вы нажмете определенные моменты, на которые вы слегка подозрительны. Затем выполните это на сервере (я использую kiwi syslog server, который легко настроить и достаточно мощный), который может писать в БД, и вы можете запустить анализ результатов. Я бы рекомендовал против ADO.NET appender для log4net, так как это не async, и поэтому замедлит ваше приложение.

Наконец, в зависимости от того, что такое приложение, если вы действительно очень заинтересованы в том, чтобы потратить некоторое время на тестирование своего здоровья, вы можете использовать WaTIN или эквивалент Winforms для тестирования внешний интерфейс. Это может быть даже длительным испытанием, наблюдающим за использованием памяти/процессора приложения во время его использования. Если вас это не волнует, то анализатор производительности Windows позволит вам смотреть на различные аспекты приложения во время его использования. Всегда полезно, но вам нужно действительно сориентироваться, чтобы получить полезные показатели.

Надеюсь, что это поможет.

Ответ 4

Первые два больших элемента, которые я бы рассмотрел, были бы следующими:

• Добавление глобальной обработки исключений с протоколированием, а также поиск любой обработки исключений, которая может быть "глотанием" исключений, скрывая проблемы с вашим приложением (я думаю, что есть также счетчик производительности Windows, который будет показывать количество исключений в секунду которые бросают ваше приложение). Это может помочь выявить любые потенциальные проблемы согласованности данных в вашем приложении.
• Добавить мониторинг производительности и протоколирование любых зависимостей сохранения данных и/или внешних сетевых сервисов, которые могут использоваться приложением, например, ведение журнала запросов к базе данных или вызовов веб-сервисов, которые занимают больше времени, чем X. >

Ответ 5

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

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