코드 분석의 목적은 무엇이며 언제 사용해야합니까?

Visual Studio의 코드 분석에 대해 들었지만 결코 사용하지 않았습니다. MSDN을 읽었 지만 여전히 코드 분석의 실제 사용을 이해하지 못합니다.

StyleCop과 동일하지 않습니까?

어딘가에 FxCop도 언급되었습니다. 코드 분석과의 차이점은 무엇입니까?

모든 프로젝트에 코드 분석을 사용해야합니까? 동료가 작성한 코드 검토가 충분하지 않습니까?

코드 분석이란 무엇입니까?

코드 분석 (이전의 FxCop)은 소스 코드에 문제가 있음을 나타내는 공통 패턴 을 검색 하는 정적 분석 도구입니다 . 예를 들어, 구현하는 클래스의 인스턴스가 올바르게 배치되지 않으면 코드 분석에서 경고가 발생합니다.IDisposable

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

이것은 이전 코드 조각의 올바른 구현입니다.

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

정적 분석 도구로서 코드 분석은 수동으로 찾기에 번거 롭거나 지루한 패턴을 찾기위한 것입니다. 예를 들어, 이전 예제에서 개발자가 자신이 사용하는 클래스가 구현되어 있는지 확인 IDisposable하거나 구현 하는 모든 .NET Framework 클래스를 기억 하는 것은 개발자에게 지루할 수 있습니다 .

어떤 프로젝트가 자격이 되나요?

정적 분석 도구로서 오탐 (false positive)이 발생할 수 있지만 일반적으로 억제 를 사용하지 않고 업무상 중요한 코드에 대해 제로 경고를 표적으로하는 것이 좋습니다 . Visual Studio 내에서 컴파일 타임에 코드 분석을 실행하도록 구성 할 수 있습니다. 프로젝트 설정에서 경고를 오류로 처리하도록 지정하면 코드 분석 규칙 위반이 눈에 띄지 않습니다.

정적 분석은 중간 규모 또는 대규모 프로젝트에 시간이 걸릴 수 있으므로 종종 개발자의 컴퓨터에서 TFS 빌드 서버로 옮기는 것이 좋습니다. 사전 커밋 중에 코드 분석을 실행 하는 것은 좋지 않지만 (StyleCop과 달리) 빌드시 실행되어 경고가 발견되면 실패 할 수 있습니다.

업무상 중요하지 않은 코드의 경우 Visual Studio 또는 명령 줄 에서 코드 분석을 수동으로 실행할 수 있습니다 . 프로젝트 속성에서 요구 사항에 맞게 확인 및 경고를 세분화 할 수 있습니다. 예를 들어 프로젝트를 현지화하지 않으려는 경우 세계화 경고 를 끌 수 있습니다.

StyleCop과 마찬가지로 프로젝트가 프로젝트 시작부터 코드 분석에서 제로 경고를 대상으로할지 여부를 결정해야합니다. 기존 프로젝트에 도입하면 너무 고통 스러울 수 있습니다.

StyleCop과 다른가요?

코드 분석은 StyleCop 과 동일하지 않습니다 . 첫 번째 차이점은 코드 분석은 컴파일 된 어셈블리에서 작동하고 StyleCop은 소스 자체에서 작동한다는 것입니다. 두 번째 (가장 중요한) 차이점은 코드 분석에서 버그를 나타낼 수있는 패턴을 검색하는 반면 StyleCop은 단순히 팀에서 사용하는 간단한 규칙 인 스타일 규칙을 시행한다는 것입니다.

코드 분석은 언어를 잘 모르는 초보자에게도 유용합니다. 종종 "Aha!"로 이어질 수 있기 때문입니다. 순간. 예를 들어, CA2105 : 배열 필드는 읽기 전용 이 아니어야합니다. 누군가 배열이 읽기 전용으로 표시되어 있어도 배열 내의 요소를 변경하는 것을 금지하는 것이 없기 때문에이를 변경할 수 없습니다. StyleCop은 발견으로 이어지지 않습니다. 필드가 소문자로 시작하거나 로컬 호출 앞에 접두사가 있어야한다는 사실은 흥미롭지 않습니다 this.

몇 가지 규칙이 모두 코드 분석 및 StyleCop에 의해 시행된다하더라도 (예 : CA1707 : 식별자는 밑줄이 포함되지 않아야 대 밑줄을 포함 할 수 없습니다 필드 이름 : SA1310을 ) 두 도구를 보완 하고 종종 나란히 사용.

우리는 이미 코드 리뷰를 가지고 있습니다

코드 검토가 있다고해서 코드 분석을 피할 수있는 것은 아닙니다. 코드 분석과 StyleCop은 모두 코드 검토 전에 자동으로 사물을 찾는 데 탁월 합니다. 자동으로 발견 될 수있는 스타일 문제 나 문제 패턴을 정확하게 지적하는 코드 검토를 소비하는 것보다 나쁘지 않습니다. 흥미로운 것들에 대한 코드 리뷰를 유지하십시오.

또 다른 측면은 인간 검토자가 코드 분석에서 발견 된 문제점을 발견하는 데 반드시 우수하지는 않다는 것입니다. 예를 들어, 클래스 구현의 인스턴스는 IDisposable한 위치에서 생성 된 다음 다른 위치에 배치 될 수 있습니다. 검토자가이를 찾는 데 시간이 걸리지 만 정적 분석 도구가이를 발견하는 데 몇 밀리 초가 걸립니다.