Использование FXCop в вашем проекте [закрыто]

Question

Много ли ИТ-магазинов используют FxCop для написания производственного кода? Если да, то каков был ваш общий опыт внедрения культурного сдвига, болевых точек и ощутимых преимуществ?

Я нахожусь в некоторой хаотичной среде и ищу инструменты, которые помогут нам стандартизировать наши усилия по разработке и вернуть нас домой в приличный час. Я хочу избежать появления яиц на лице, потому что я использую инструмент статического анализа только для того, чтобы он вышел из строя, потому что он & # 8217; s & # 8220; не практично & # 8221 ;. < - (Ожидаемый ответ руководства)

Answer 1

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

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

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

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

Answer 2

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

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

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