Выход из зоны боли - NDepend

Question

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

Что означает зона боли? Разве это не означает, что существует много связей, и вещи не могут измениться очень легко.

Недавно я удалил много интерфейсов и закрепил множество классов, так как я не хочу, чтобы пользователь расширил API (только в некоторых местах). Это .NET Wrapper для COM-объекта, поэтому пользователю не нужно ничего расширять.

Какие хорошие способы вывести меня из зоны боли?

Благодаря

Answer 1

Я думаю, что Скотт Hanselman написал довольно длинный пост о NDepend и его последствия зоны

http://www.hanselman.com/blog/ExitingTheZoneOfPainStaticAnalysisWithNDepend.aspx

Как он заявил, и я согласен, сборка зависания в зоне боли есть не обязательно плохой предмет. Тем не менее, это указывает на необходимые изменения с вашей стороны, когда в день принятия решения используется другой компонент (COM или иным образом) для выполнения того же уровня функциональности.

Вопрос, вероятно, заключается в том, «насколько вероятно, мы собираемся заменить этот слой для другого фреймворка/библиотеки?»

Answer 2

Идея зоны боли заключается в выявлении компонентов, как: -Вы бетон (т.е. их пользователи привязываться с классами вместо интерфейсов) -Вы популярные (т.е. они используются многими другими компонентами).

Популярные относится к понятию стабильности. Компонент стабилен, если при изменении он разбивает много других компонентов, которые его используют. Одним словом: Popular = Stable

Другая идея заключается в том, что интерфейсы менее подвержены изменениям, чем классы. Вот почему принято считать, что предпочтительнее использовать интерфейс вместо класса, у вас меньше шансов быть «статически» сломанным + у вас меньше шансов быть «семантически» сломанным, так как ваш код не должен быть связанные с любыми деталями реализации (которые сильно подвержены изменениям).

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

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