외부 코드에서 임의의 함수 / 클래스에 대한 호출 금지

시스템에서 부정적인 결과를 방지하기 위해 외부 라이브러리 및 프레임 워크의 API에 대한 액세스를 제한하는 것이 가치가있는 경우를 경험했습니다.

예를 들어, SharePoint 응용 프로그램에서는 spList.Items.GetItemById큰 성능 문제가 발생할 수 있다는 사실을 모르면 루프에서 목록 항목을 가져 오기 위해 호출 하는 것이 자연스럽게 보일 수 있습니다.

또한 테스트 환경에서 모든 이메일을 제대로 프록시하고 조롱 할 수 있도록 모든 사람이 자신의 클래스를 사용하여 이메일을 보내도록하려면 SmtpClient 사용을 금지해야 할 수도 있습니다.

자체 코드의 특정 위치를 제외하고 외부 코드에 대해 이러한 제약 조건을 달성 할 수있는 신뢰할 수 있고 합리적인 방법이 있습니까? 모든 상황에서 이러한 방법 / 클래스에 대한 접근을 완전히 막을 필요는 없습니다. 예를 들어 반영 또는 일종의 비활성화로 인해 사용해서는 안된다는 엄격한 경고 여야합니다. 바람직하게는 프로그래머가 가능하다면 / 필요할 경우 이러한 제약을 무시하는 조치를 적극적으로 취하도록 강요한다.

자체 코드의 특정 위치를 제외하고 외부 코드에 대해 이러한 제약 조건을 달성 할 수있는 신뢰할 수 있고 합리적인 방법이 있습니까?

특히 C #에 대한 질문이므로 이러한 규칙을 적용하기 위해 여기에서 사용할 수있는 컴파일러 기반 솔루션이 있습니다 : Roslyn Analyzers . 특정 API에 대한 액세스를 컴파일 오류 또는 경고로보고하는 자체 분석기를 작성할 수 있습니다.

직접 작성하여 많은 예제 코드를 제공하는 예제 분석기 세트는 C #의 기존 StyleCop 기능을 대체 하는 StyleCop Analyzer 입니다.

그럼에도 불구하고, 그러한 자동 수표는 항상 "규칙을 어기겠다"고 결심 한 사람들이 해결할 수 있습니다. 따라서이 방법은 Karl Bielefeldt의 답변에서 논의 된 코드 검토를 대체하지 않습니다. 그러한 검토를 지원할 수 있지만이를 대체해서는 안됩니다.

외부 API 주위에 래퍼를 작성하는 등 시간이 많이 걸리는 작업을 수행 할 수 있지만 원하지 않는 작업은 생략하지만 교육이나 코드 검토를 능가하는 것은 없습니다. .

예를 들어 스칼라로 작성된 여러 서비스가 있으며 코드 검토시 요청하는 사항 중 하나는 불변성에 대한 것이지만 종종이를 제거하는 것으로 의사 소통합니다 vars. 다른 날 누군가 val x : ListBuffer [Boolean] 을 사용하여 단일 가변 변수를 목록의 유일한 항목으로 유지했습니다. ListBufferx에 다른 것을 할당 할 수는 없지만 원하는만큼 목록의 항목을 교체 할 수 있습니다. 을 사용하는 것만 큼 var좋지만 몰래 사용하십시오.

다시 말해, 사람들이 기술 솔루션을 둘러보고 있는지 확인해야합니다. 이러한 기술 솔루션이 비용이 많이 들고 복잡성이 추가되는 경우 솔루션이 올바르게 코딩되고 있는지 확인할 수도 있습니다.

칼의 대답은 100 % 정확합니다. 적합성을 보장 할 방법이 없습니다. 그러나 교육 및 코드 검토 외에도 정적 분석 도구를 사용하여 규정을 준수하는지 확인하십시오. (참고 : 칼이 말한 것과 똑같은 방식으로 그것들을 우회 할 수 있기 때문에 나는 "추가로"라고 말했다.

정적 분석 도구를 사용하면 "IEnumerable을 여러 번 사용"하거나 지금보고있는주의 성능 문제 (또는 적어도 항상 느끼고 있음)를 찾는 지루한 휴먼 코드 분석을 제거 할 수 있다는 장점이 있습니다. 보고). 이를 통해 코드 검토 및 교육을 통해보다 "흥미로운"문제에 집중할 수 있습니다.

C #의 경우 특히 아래에 몇 가지 제안 사항이 포함되어 있습니다. 이것을 빌드 환경에 연결하면 좋습니다. 그러나 일반적으로 어떤 언어를 사용하든 어딘가에 정적 분석 도구가 있습니다.

Wikipedia 페이지에서 바로 복사 / 붙여 넣기, 가장 최신 정보 및 링크는 Wiki 페이지를 사용하십시오. https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET

• .NET 컴파일러 플랫폼 (코드 명 Roslyn) – Microsoft .NET에서 개발 한 C # 및 Visual Basic .NET 용 오픈 소스 컴파일러 프레임 워크. 구문을 분석하고 조작하기위한 API를 제공합니다.
• CodeIt.Right – 정적 코드 분석 및 자동 리팩토링을 모범 사례에 결합하여 코드 오류 및 위반을 자동으로 수정할 수 있습니다. C # 및 VB.NET을 지원합니다.
• CodeRush – 모범 사례 위반을 사용자에게 경고하는 Visual Studio 용 플러그인입니다.
• FxCop – CIL로 컴파일되는 Microsoft .NET 프로그램에 대한 무료 정적 분석. 독립형이며 일부 Microsoft Visual Studio 버전에 통합되어 있습니다. Microsoft에 의해.
• NDepend – 코드 종속성을 분석 및 시각화하고, 설계 규칙을 정의하고, 영향 분석을 수행하고, 여러 버전의 코드를 비교하여 복잡한 .NET 코드 기반 관리를 단순화합니다. Visual Studio에 통합합니다.
• Parasoft dotTEST – Visual Studio 용 정적 분석, 단위 테스트 및 코드 검토 플러그인. C #, VB.NET, ASP.NET 및 Managed C ++를 포함한 Microsoft .NET Framework 및 .NET Compact Framework 언어와 호환됩니다.
• Sonargraph – 종속성 분석, 자동화 된 아키텍처 확인, 메트릭 및 사용자 지정 메트릭 및 코드 검사기 추가 기능에 중점을 둔 C #, Java 및 C / C ++를 지원합니다.
• StyleCop – C # 소스 코드를 분석하여 일련의 스타일 및 일관성 규칙을 시행합니다. Microsoft Visual Studio 내부에서 실행하거나 MSBuild 프로젝트에 통합 할 수 있습니다.

다른 답변에서 제기 된 "훈련 및 코드 검토"제안에 대해 자세히 설명하려면 : 금지하려는 코드가 합법적 인 코드이기 때문에 컴파일러가이를 방지 할 수 없으므로 나중에 처리해야하는 프로세스가 필요합니다. 검토.

여기에는 수동 검토 단계와 자동 검토 단계가 모두 포함될 수 있습니다.

• 알려진 문제에 대한 점검 목록을 준비하고 수동 코드 검토에서 하나씩 해결하십시오. 점검 목록을 검토하고 업데이트하기 위해 되풀이 모임을 갖습니다. 불쾌한 버그가 발견되어 분석 될 때마다 점검 목록에 추가하십시오.

• 알려진 패턴을 찾기 위해 체크인 규칙을 추가하십시오. 작성하기가 복잡 할 수 있지만 시간이 지남에 따라 대규모 프로젝트의 경우 유용 할 수 있습니다. TFS를 사용하면 C #으로 규칙을 작성할 수 있으며 다른 빌드 시스템에는 자체 후크가 있습니다. 게이트 된 빌드를 사용하여 패턴과 일치하는 체크인을 거부하십시오. 예, 개발 속도가 느리지 만 특정 프로젝트 크기와 복잡성 후에 개발자 속도를 늦추는 것이 좋습니다.

컴파일러가 원치 않는 호출을 잡는 데 도움을 줄 수 있습니다.

외부 lib 클라이언트가 사용하지 않아야하는 자신의 lib에서 클래스 / 코드의 이름을 바꾸십시오. 또는 클래스 / 메소드를 내부적으로 만들거나 해당 클래스를 사용할 수있는 클래스에 내부를 추가 할 수 있습니다.

외부 lib 사용자는 컴파일 오류 메소드 / 클래스를 찾을 수 없습니다.

공공 도서관에서 금지 된 클래스 / 메소드 : lib에서 동일한 네임 스페이스 / 클래스 / 메소드를 작성하십시오.

중복 클래스가 발견되어 외부 lib 사용자에게 컴파일 오류가 발생합니다.

[최신 정보]

모든 상황에서 이러한 메소드 / 클래스에 대한 액세스를 예를 들어 반성 또는 일종의 비활성화 등으로 절대 막을 필요는 없습니다.

프로그래머 (... lib의 클라이언트 ...)가 가능하거나 필요한 경우 이러한 제약 조건을 무시하는 조치를 적극적으로 취하도록 강요합니다.