Насколько зрела платформа Microsoft Code Contracts?

Microsoft недавно выпустила свою платформу Code Contracts на DevLabs с коммерческой лицензией. Мы заинтересованы в том, чтобы использовать их в нашем проекте (в основном C#, немного C++/CLI), чтобы постепенно заменить весь пользовательский код проверки, но мне интересно узнать об опыте, который другие люди получили с ним, прежде чем мы передадим его, в частности:

  • Считаете ли вы, что рамки достаточно зрелые для крупных и сложных коммерческих проектов?

  • С какими проблемами вы столкнулись при его использовании?

  • Какие преимущества вы получили от этого?

  • Это в настоящее время больше боли, чем стоит?

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

Должны ли мы начать использовать его в следующем месяце?

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

Источник

4 ответа

Решение

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

Контракты выглядят великолепно, когда вы работаете в полностью изолированной среде с вашим собственным кодом и примитивными типами, но как только вы начинаете использовать классы BCL (которые до.NET 4.0 не имеют своих собственных контрактов), верификатор не может проверить нарушат ли они какое-либо из требований / гарантий / инвариантов, и поэтому вы получите много предупреждений о потенциально неудовлетворенных ограничениях.

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

Так что я чувствую, что пока, потому что в 3.5 мы пытаемся построить фреймворк, который верификатор недостаточно понимает, что, вероятно, стоит подождать 4.0.

Источник

Последний зрелый ответ на это был в 2009 году, и вышла.NET 4. Я полагаю, что мы должны для обновления:

Контракты могут быть достаточно зрелыми для ваших релизов Debug.

Я понимаю, что это что-то вроде повышения "Безвредного" до "В основном безвредного".

Кодекс Контракты домашняя страница ссылки на довольно подробную документацию в формате PDF. Документация описывает руководство по использованию в разделе 5. Подводя итог, вы можете выбрать, насколько смело вы относитесь к Контрактным инструментам, переписывающим ваш IL в ваших сборках Release.

Мы используем режим "не переписывать мой Release IL".

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

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

будет выглядеть так:

Contract.Requires(arg != null);

Ваши функции короче. Ваше намерение яснее. И вам больше не нужно писать тест с именем ArgumentShouldNotBeNull только для того, чтобы достичь 100% покрытия.

Пока что я столкнулся с двумя проблемами:

  • У меня был модульный тест, который основывался на провале контракта. Вы можете утверждать, что существование теста было ошибкой, но я хотел задокументировать этот конкретный запрет в форме теста. Тест не прошел на моем сервере сборки, потому что у меня не было установленных инструментов. Решение: установить инструменты.

  • Мы используем два инструмента, которые переписывают IL: Code Contracts и PostSharp. Они не ладили слишком хорошо. PostSharp 2.0.8.1283 исправил проблему. Я бы осторожно оценил, как уживаются любые два инструмента переписывания IL.

Пока что преимущества перевешивают опасности.

Решение устаревших проблем, поднятых в других ответах:

  • Документация Code Contracts довольно полная, хотя, к сожалению, в формате PDF.
  • Существует по крайней мере один форум Code Contract, размещенный Microsoft.
  • Code Contracts Standard Edition предоставляется бесплатно, если у вас есть лицензия VS2010.
  • .NET 4 вышел. Я столкнулся с контрактами Microsoft при реализации универсальных интерфейсов сбора.
Источник

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

  • Наличие форума сообщества. Вам захочется обсуждать неизбежные проблемы, с которыми вы сталкиваетесь, с другими разработчиками, и вы хотите знать, что существует достаточно сильная база разработчиков для обсуждения решений.
  • Успешный релиз пилотного проекта. Как правило, когда Microsoft Research выпускает что-то, что, по их мнению, является достаточно зрелым для использования в коммерческом проекте, они будут работать с организацией, которая будет его пилотировать, а затем выпустят этот проект с открытым исходным кодом в качестве доказательства концепции и пробной эксплуатации. из всех основных функций. Это дало бы большую уверенность в том, что большинство общих сценариев контракта охвачены и работают.
  • Более полная документация. Просто и ясно, в какой-то момент вы захотите сделать что-то с контрактами, которые вы еще не можете сделать с помощью Microsoft Code Contracts. Вы хотите иметь возможность быстро и четко обосновать, что ваш сценарий еще не поддерживается. Текущая документация заставит вас гадать и пробовать разные вещи, хотя, на мой взгляд, это приведет к потере времени.
Источник

Это не достаточно зрелый.

Это произойдет, как только Microsoft выпустит его с доступными выпусками VS, но без статического анализа кода его вообще нельзя будет использовать.

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

Жаль, что Microsoft убила эту удивительную идею своей ценовой политикой. Я бы хотел, чтобы контракты по кодексу стали мейнстримом, но не будут.

Эпический провал.

Источник
Другие вопросы по тегам