Microsoft 코드 계약 프레임워크는 얼마나 성숙합니까?

https://stackoverflow.com/questions/671809

21-08-2019
|

문제

마이크로소프트는 최근 자사의 제품을 출시했습니다. 코드 계약 상용 라이센스가 있는 DevLabs의 프레임워크입니다.우리는 프로젝트(주로 C#, 일부 C++/CLI)에서 이를 사용하여 모든 사용자 지정 유효성 검사 코드를 점진적으로 대체하는 데 관심이 있지만, 우리가 커밋하기 전에 다른 사람들이 이 코드를 사용하면서 겪은 경험에 대해 알고 싶습니다. 구체적으로:

크고 복잡한 상업 프로젝트를 위해 프레임워크가 충분히 성숙했다고 생각하시나요?
사용하면서 어떤 문제가 발생했나요?
그로부터 어떤 이점을 얻었나요?
현재 그 가치보다 더 큰 고통이 있습니까?

나는 이것이 의견이 필요하기 때문에 다소 주관적인 질문이라는 것을 알고 있지만 이 프레임워크는 .NET 4.0의 매우 중요한 부분이고 (잠재적으로) 우리 모두가 유효성 검사 코드를 작성하는 방식을 바꿀 것이므로 이 질문은 그대로 두기를 바랍니다. 구체적이고 답할 수 있는 질문에 대한 결정을 내리는 데 도움이 되는 주제에 대한 경험을 수집하기 위해 열려 있습니다.

다음 달부터 사용해볼까요?

우리는 코드 API를 제공하지 않고 웹 서비스만 제공하므로 대부분의 코드에서 발생하는 예외 유형과 관련된 호환성은 문제가 되지 않습니다.그러나 나뿐만 아니라 더 많은 사람들이 이 게시물과 답변으로부터 혜택을 받기를 바라기 때문에 이 분야에 대한 자세한 내용은 무엇이든 환영합니다.

해결책 2

나는 코드 계약을 통해 작지만 적당히 복잡한 독립형 프로젝트에서 일부 BCL 클래스에서 상속하고 다른 클래스를 사용해야합니다.

계약은 자신의 코드와 원시 유형만으로 완전히 고립 된 환경에서 작업 할 때 훌륭해 보이지만 BCL 클래스를 사용하기 시작하자마자 (.NET 4.0이 자체 계약이 없을 때까지) 검증자는 확인할 수 없습니다. 그들이 요구/보장/불변량을 위반하는지 여부는 잠재적으로 만족스럽지 않은 제약에 대해 많은 경고를받습니다.

반면에, 그것은 실제 버그가 될 수있는 유효하지 않거나 잠재적으로 불만족스러운 제약을 발견합니다. 그러나 소음이 너무 많아서 고칠 수있는 소음을 찾기가 어렵 기 때문에 이것을 찾기가 매우 어렵습니다. 가정 메커니즘을 사용하여 BCL 클래스의 경고를 억제 할 수는 있지만,이 클래스는 미래에 계약을 맺고 가정이 그 가치를 줄이기 때문에 다소 자기 방어됩니다.

그래서 내 감정은 현재 3.5에서 검증자가 충분히 이해하지 못하는 프레임 워크를 구축하려고 노력하고 있기 때문에 아마도 4.0을 기다릴 가치가 있다는 것입니다.

다른 팁

이에 대한 마지막 성숙한 반응은 2009 년에 있었고 .NET 4는 나왔습니다. 나는 우리가 업데이트를 할 예정이라고 생각합니다.

코드 계약은 디버그 릴리스에 충분히 성숙 할 수 있습니다.

나는 이것이 "무해한"것에서 "대부분 무해한"으로 업그레이드된다는 것을 알고 있습니다.

그만큼 코드 계약 홈페이지 PDF 형식의 매우 철저한 문서화 링크. 문서는 섹션 5의 사용 지침을 설명합니다. 요약하려면 당신은 당신이 얼마나 용감하게 느끼는지 선택할 수 있습니다 릴리스 빌드에서 IL을 다시 작성하는 계약 도구에 대해.

우리는 "내 릴리스 IL을 다시 작성하지 마십시오"모드를 사용하고 있습니다.

지금까지 나는이 예기치 않은 혜택을 가장 즐기고 있습니다. 코드가 적으므로 테스트 할 코드가 적습니다. 모든 가드 조항이 녹아 버립니다.

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

Contract.Requires(arg != null);

당신의 기능은 짧습니다. 당신의 의도는 더 명확합니다. 그리고 더 이상 100% 적용 범위에 도달하기 위해 ArgumentShouldNotBenull이라는 테스트를 작성할 필요가 없습니다.

지금까지 나는 두 가지 문제를 해결합니다.

계약 성공 실패에 의존하는 단위 테스트가있었습니다. 당신은 시험의 존재가 실수라고 주장 할 수 있지만, 나는이 특별한 금지를 시험 형태로 문서화하고 싶었다. 도구가 설치되지 않았기 때문에 빌드 서버에서 테스트가 실패했습니다. 해결책 : 도구를 설치하십시오.
우리는 IL을 다시 작성하는 두 가지 도구를 사용하고 있습니다. 코드 계약 그리고 포스트 쇼트. 그들은 너무 잘 지내지 못했습니다. PostSharp의 2.0.8.1283은 문제를 해결했습니다. 나는 조심스럽게 어떻게 평가했는지를 평가했다 어느 그래도 두 개의 IL- 레팅 도구가 진행됩니다.

지금까지 혜택은 위험보다 중요합니다.

다른 답변에서 제기 된 오래된 문제 해결 :

Code Contracts의 문서는 PDF에서 유감스럽게도 매우 철저합니다.
적어도 하나가 있습니다 코드 계약 포럼 Microsoft가 주최합니다.
Code Contracts Standard Edition은 VS2010 라이센스가있는 경우 무료입니다.
.NET 4가 나왔습니다. 일반 컬렉션 인터페이스를 구현할 때 Microsoft의 계약을 체결했습니다.

판단하여 이 스레드 엔터프라이즈 수준 프로젝트에 사용하기에는 충분히 성숙하지 않다고 말하고 싶습니다.나는 그것을 직접 사용하지 않았지만 계약에 중요한 프로젝트를 중단시키는 버그가 여전히 사람들에게 발생하고 있습니다.정말 훌륭한 프레임워크인 것 같고 그들이 제공한 예제 비디오는 흥미로웠지만 다음을 기다리고 싶습니다.

커뮤니티 포럼이 존재합니다. 당신은 다른 개발자들과 직면하게 되는 피할 수 없는 문제에 대해 논의할 수 있기를 원할 것이며, 솔루션을 논의할 수 있는 상당히 탄탄한 개발자 기반이 있다는 것을 알고 싶을 것입니다.
성공적인 파일럿 프로젝트 출시. 일반적으로 Microsoft Research에서는 상용 프로젝트에 사용할 수 있을 만큼 성숙하다고 생각되는 항목을 출시하면 조직과 협력하여 이를 시험한 다음 해당 프로젝트 오픈 소스를 개념 증명 및 시험판으로 출시합니다. 모든 주요 기능을 살펴보겠습니다.이는 대부분의 일반적인 계약 시나리오가 적용되고 작동한다는 많은 확신을 줄 것입니다.
더 완전한 문서. 간단하고 간단합니다. 어떤 시점에서는 Microsoft 코드 계약을 사용하여 아직 수행할 수 없는 계약 작업을 수행하고 싶을 것입니다.당신은 당신의 시나리오가 다음과 같다고 빠르고 명확하게 추론할 수 있기를 원합니다. 아직 지원되지 않습니다. 현재 문서에서는 계속해서 다양한 추측과 시도를 하게 될 것입니다. 하지만 제 생각에는 이로 인해 많은 시간이 낭비될 것입니다.

충분히 성숙하지 않습니다.

Microsoft가 Affordable Edition of VS로 출시 되 자마자, 정적 코드 분석이 없으면 전혀 사용할 수 없습니다.

VS의 판은 너무 비싸서 소수의 사람들만이 그것을 감당할 수있을 것입니다.

Microsoft가 가격 정책 으로이 놀라운 아이디어를 죽인 것은 부끄러운 일입니다. 코드 계약이 주류가되기를 바랍니다. 그러나 그들은 그렇지 않습니다.

서사시 실패.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow