Мир разработки программного обеспечения наполнен тем, что я называю дебатами «Coke-Pepsi». Вот как мой мозг классифицирует споры о предпочтениях, которые почти полностью субъективны. Нет правильного или неправильного ответа на вопрос «что лучше кока-кола или пепси?» Ответ: «Какой вам больше нравится».

Примеров в мире программного обеспечения предостаточно. Должны ли вы использовать тяжеловесную IDE или легковесный текстовый редактор? Какой ООП-язык «лучший»? И, говоря об ООП, следует ли вообще использовать ООП-язык или использовать функциональный? Корпус паскаль или верблюжий? Список можно продолжать, но такие вещи обычно сводятся к комфорту и предпочтениям человека или команды.

Было бы заманчиво нарисовать этой кистью NDepend Standalone по сравнению с плагином NDepend Visual Studio. И хотя я думаю, что вы могли бы привести довольно законные доводы в пользу того, что это тоже просто вопрос предпочтений, сегодня я хотел бы провести мысленное упражнение, в котором я выступаю в пользу интеграционного подхода. На мой взгляд, есть достаточно преимуществ, чтобы я мог украсть это из царства кока-колы против пепси.

Какая разница?

Прежде всего, я, вероятно, должен объяснить немного больше о разнице. Автономное приложение NDepend работает как любое стандартное настольное приложение Windows. Чтобы использовать его, вы должны запустить его и использовать для запросов к своей кодовой базе, запуска отчетов, визуализации вашей архитектуры и т. д. Если вы хотите изменить свой код и использовать NDepend одновременно, у вас будет два открытых окна, которые вы бы Alt-Tab между.

В качестве подключаемого модуля NDepend работает так, как если бы он был частью самой Visual Studio. Visual Studio имеет архитектуру с поддержкой подключаемых модулей, которая позволяет сторонним авторам инструментов создавать подключаемые модули, которые ведут себя таким образом. Для пользователей плагинов интеграция абсолютно беспроблемна. Таким образом, во всех смыслах и целях плагин NDepend для Visual Studio делает NDepend первоклассной частью Visual Studio. Таким образом, все, что вы делаете с NDepend, и весь ваш код происходит в одном месте: Visual Studio.

Почему лучше интегрироваться с Visual Studio?

Я полагаю, что первое, что приходит вам в голову, — это отсутствие необходимости переключаться между двумя окнами. И я утверждаю, что на самом деле это преимущество, хотя это преимущество только поверхностное. С точки зрения логистики при использовании меньше трения, когда вам не нужно постоянно переключаться между двумя окнами. И даже если вы предпочитаете разделять задачи на несколько окон (скажем, если у вас несколько мониторов), вы все равно можете сделать это внутри Visual Studio.

Но преимущества кроются глубже и тоньше. Трение, возникающее при переключении контекста, — это не просто пустая трата мозгового цикла и времени. Это также создает естественное препятствие для использования функциональности. Микрорешение «нет, оно того не стоит» может быть ответом на вопрос «должен ли я открыть NDepend, чтобы проверить, есть ли у этого класса какие-либо проблемы, связанные с анализом?» То же самое решение могло бы быть «да, я сделаю это», если бы NDepend был интегрирован в Visual Studio, и вы могли бы сделать это нажатием клавиши. В совокупности за много времени человек с плагином получит гораздо больше пользы от инструмента, что сделает его более рентабельным.

Также следует учитывать влияние обратной связи внутри самой среды. Люди, которые пишут свой код в Visual Studio, привыкли смотреть на панель вывода и панель с предупреждениями и ошибками компилятора, чтобы получить обратную связь о том, что они делают. Плагин NDepend предоставляет обратную связь в знакомой форме. И предупреждения, и результаты запроса кода отображаются в привычных для разработчиков панелях. Совсем несложно добавить «проверить предупреждения кода NDepend» к «проверке предупреждений компилятора».

И, наконец, добавление NDepend в Visual Studio передает важную информацию о статическом анализе кода. Если у вас есть отчет сборки о качестве кода или вы используете какой-либо внешний инструмент для анализа кода, это предполагает, что анализ — это то, что вы делаете с кодом постфактум. Но при внедрении в Visual Studio разработчики понимают, что статический анализ кода — это первоклассная часть опыта разработки программного обеспечения.

Не случайно, что с каждым новым выпуском Visual Studio и других IDE, таких как Eclipse, все больше и больше инструментов статического анализа поставляется с ним из коробки. Эксперты, создающие IDE, признают ценность этого инструментария. Я призываю вас сделать то же самое.

Чтобы было ясно, если вы используете статический анализ для повышения качества кода, вы значительно опережаете игру независимо от того, интегрируете ли вы Visual Studio или нет. Статический анализ должен быть неотъемлемой частью вашего подхода к коду, и если вы используете для этого автономный NDepend, то отлично! Я пишу это просто потому, что думаю, что вы могли бы получить немного больше пользы от своих инвестиций, если бы вы выбрали полную интеграцию с Visual Studio. Может быть, это как кока-кола против пепси, но я склонен думать, что это больше похоже на полный стакан газировки, чем наполовину.

Попробуйте интеграцию сегодня. Нажмите, чтобы получить 14-дневную бесплатную пробную версию NDepend и кодируйте с полным стаканом.

Первоначально опубликовано на сайте blog.ndepend.com 4 февраля 2016 г.