팀원에게 컴파일러 경고를 무시해서는 안된다는 것을 어떻게 확신시킬 수 있습니까?

나는 Eclipse를 사용하여 Java에서 거대한 프로젝트 (더 이상 의존성 관리로 인해 쉽게 분리 할 수는 없지만 다른 토론 인 수십 가지 미니 프로젝트의 얽힌 조합과 비슷합니다)와 관련이 있습니다. 우리는 이미 컴파일러 설정에서 많은 경고를 해제했으며 프로젝트에는 여전히 10,000 개가 넘는 경고가 있습니다.

나는 모든 경고를 해결하려고 노력하고 가능한 경우 모든 경고를 수정하며 안전하고 안전한 것으로 간주되는 경고를 억제하는 데 큰 지지자입니다. (구현 된 모든 방법을 @Override로 표시하는 것에 대한 종교적 강박 관념도 마찬가지입니다). 나의 가장 큰 주장은 일반적으로 경고는 컴파일 시간 동안 잠재적 인 버그를 찾는 데 도움이된다는 것입니다. 어쩌면 100 번 중 99 번이 경고는 중요하지 않지만 한 번만 주요 버그를 예방할 수 있다고 생각하는 머리를 긁으면 모든 가치가 있다고 생각합니다. (나의 다른 이유는 코드 정리가있는 명백한 OCD입니다.)

그러나 많은 팀원들은 신경 쓰지 않는 것 같습니다. 나는 때때로 그것들을 우연히 발견 할 때 경고를 수정합니다 (그러나 당신은 동료가 작성한 코드를 만질 때 까다 롭다는 것을 알고 있습니다). 클래스보다 문자 그대로 더 많은 경고가 발생하면 경고의 이점이 크게 최소화됩니다. 경고가 너무 흔한 경우 아무도 경고를 보지 않아도되기 때문입니다.

팀원 (또는 권한)이 경고를 해결해야하거나 완전히 조사 할 때 억제해야한다는 것을 어떻게 확신시킬 수 있습니까? 아니면 내가 미쳤다고 스스로를 설득해야합니까?

감사

(PS 나는 마지막 으로이 질문을 게시하라는 메시지가 언급 된 것을 잊어 버렸습니다. 나는 경고보다 느리게 경고를 수정하고 있음을 슬프게 알았습니다.)

두 가지를 할 수 있습니다.

1. 경고가 이유가 있다고 지적하십시오. 컴파일러 작가는 의미가 있기 때문에 그것들을 넣지 않습니다. 우리 업계의 사람들이 일반적으로 도움이됩니다. 많은 경고가 도움이됩니다.

2. 무시 된 경고에서 발생하는 화려한 실패의 역사를 모으십시오. "컴파일러 경고에주의"에 대한 웹 검색은 일부 일화를 반환합니다.

당신의 집착 @Override은 "집착"이 아닙니다. 그것은 좋은 것입니다. 메소드 이름을 잘못 입력 한 적이 있습니까?

관련 읽기는 여기 . C ++이지만 여전히 관련이 있습니다. 나는 특히이 예제를 좋아합니다 (코드 주석은 내 것입니다).

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

많은 경우 경고는 실제로 디자인 결함을 추적하여 수정하는 데 도움이되는 오류로 인한 응용 프로그램 충돌 ( 안전한 유형 변환 과 같은 ) 또는 응용 프로그램 가정을 가정 한 다음 실제로 잘못된 동작을 수행하는 것의 차이를 의미합니다. 또는 잘못된 방식 ( 안전하지 않은 타입 캐스팅 의 경우 ). 마찬가지로, 그들은 C ++에 대한 위의 예와 같이 코드 최적화로 간주되거나 테스트에서 나타날 수있는 설명되지 않은 사례 (제거 할 수없는 코드 블록, 사용되지 않은 변수)를 제거 할 수있는 크래프트 또는 데드 코드를 지적합니다. 이 예제는 Java에서 컴파일 타임 오류를 발생시킵니다.

따라서 경고를 수정하면 관리에 몇 가지 장점이 있습니다.

1. 회사 이미지에 대한 우려가 높고 고객 데이터를 처리하는 방법에 대해서는 사용자 입력 데이터에서 코드가 부적절하게 작동 할 가능성이 적으므로 Big Deal (tm)이어야합니다. 사용자가 어리석은 짓을하지 못하게하는 충돌은 충돌하지 않고하는 것보다 낫습니다.
2. 직원을 재편성하려는 사람들은 경고없는 코드베이스로 들어올 수 있습니다. 어쩌면 이것은 프로젝트 X에 대한 X 팀의 기여의 유지 가능성 또는 품질에 대한 의견 또는 진행되는 불평의 양을 줄일 것입니다.
3. 컴파일러 경고를 제거하여 실행 시간을 크게 개선하지 않으면 서 코드를 최적화하면 테스트 할 때 수많은 점수가 향상됩니다.
   • 모든 코드 범위 점수가 증가 할 것입니다.
   • 테스트 경계 및 유효하지 않은 테스트 사례는 다른 것들 중에서도 위에서 언급 한 안전한 타입 캐스팅 으로 인해 더 자주 성공할 것입니다.
   • 테스트 사례가 실패하면 해당 소스 파일의 컴파일러 경고 중 하나로 인한 것인지 생각할 필요가 없습니다.
   • 제로 컴파일러 경고가 수천보다 낫다는 것은 쉽게 논쟁의 여지가 있습니다. 코드의 품질에 대해 경고 나 오류가 발생하지 않으므로 코드 품질이 더 적은 경고를 개선한다고 주장 할 수 있습니다.
4. 컴파일러 경고가없고 하나 이상이 소개 된 경우 누가 코드베이스에 경고를 표시했는지 알기가 훨씬 쉽습니다. "경고 없음"정책이 있다면, 제대로 업무를 수행하지 않는 사람들을 식별하는 데 도움이 될 것입니다. 코드 작성은 무언가를 만드는 것이 아니라 잘 작동하는 것 입니다.

나는 여전히 프로젝트 관리에 대해 거의 아는 주니어 개발자 일뿐입니다. 잘못 말한 경우 내 생각을 수정하고 저를 존재에서 제외시키기 전에 편집 할 수있는 기회를주십시오 :)

나는 과거에 비슷한 특성을 가진 프로젝트를 수행했습니다. 이것은 특히 Java 1.4로 작성되었습니다. 제네릭이 포함 된 Java 5가 나오면 Collections API를 사용할 때마다 컴파일러에서 발생하는 경고 수를 상상할 수 있습니다.

제네릭을 사용하기 시작하면 모든 경고를 제거하는 데 어느 정도 시간이 걸렸을 것입니다. 그것은 고려해야 할 요소이지만, 누군가 (특히 관리자)에게 수정이 필요하다는 것을 확신시켜야 할 때는 다음과 같은 하드 데이터가 필요합니다.

피할 수 있었던 레거시 또는 비표준 호환 코드 (표준은 프로젝트의 코딩 표준)의 버그에 소요 된 시간입니다.

"확실한"경고를 무시하여 시간과 돈을 잃어 버리는 방법을 보여주는 청구서를 계속 제시하면 누군가 아이디어를 얻을 수 있습니다. 중요한 부분은 모든 경고가 최소한 즉시 볼 가치가있는 것은 아니라는 것입니다. 간단히 말하면 즉시 해결해야하는 경고의 우선 순위를 설정해야합니다. 우선 프로젝트에서보고있는 버그와 관련된 버그를 고려하십시오.

버그를 고칠 때 경고를 무시하지 않고 (또는 CI 또는 빌드 시스템이있는 경우 PMD 또는 FindBugs를 실행하여) 버그를 피할 수 있었다는 것을 버그 추적기에 메모 할 수도 있습니다. 컴파일러 경고에주의를 기울여 해결할 수있는 버그가 충분하면 컴파일러 경고를 보는 데 도움이됩니다. 그렇지 않으면, 그것은 비즈니스 결정이며, 일반적으로이 전투에 맞서 싸울 시간이 아닙니다.

성공하고 팀이 경고를 준수하기로 결정한 경우 단계적으로 접근해야합니다. 아무도 한 번에 10000 개의 경고를 할 수 없으며 할 것입니다. 따라서 가장 중요한 버그 (확률이 높은 버그)를 선택하고 덜 중요한 버그를 비활성화 할 수 있습니다. 수정 된 경우 경고 레벨을 다시 늘리십시오. 또한 거의 항상 버그 인 코드에 대해 경고하는 FindBugs로 시작할 수 있습니다.

컴파일 경고를 최대한 정리하는 것이 가장 좋습니다. 팀에서 Eclipse를 개발 도구로 사용한다고 언급했습니다. Eclipse는 코드를 정리하고 코드 스타일을 일관성있게 유지하는 데 도움이되는 매우 유용한 도구입니다.

1. 형식화 코드, 사용하지 않는 로컬 변수, 가져 오기 구성과 같은 각 Java 프로젝트에 대해 '저장 조치'를 정의하십시오 (아무도 그러한 종류의 정리에 반대하는 사람이 없다고 생각합니다).
2. 각 프로젝트에 대한 프로젝트 특정 컴파일 옵션을 정의하십시오. 예를 들어, 컴파일 수준 (일반과 관련된 경고를 정리하기 위해 코드가 1.4와 호환되어야하는 경우), 할당은 영향을 미치지 않습니다 (예 : 'x = x'). 귀하와 귀하의 팀원은 해당 항목에 대해 계약을 체결 할 수 있으며, Eclipse는 컴파일 오류에 대한 동의가 있으면 개발 단계에서 해당 항목을 '오류'로보고합니다.

Eclipse는 .settings 폴더 아래에 해당 환경 설정에 대한 일부 특성 파일을 작성하고이를 다른 Java 프로젝트로 복사 한 후 소스 코드의 일부로 SCM에 체크인 할 수 있습니다.

Eclipse 코드를 확인하여 Eclipse 개발자가 수행하는 방식을 확인할 수 있습니다.

모든 경고를 제거하는 두 가지 방법이 있습니다 (미묘한 버그를 숨길 수 있음에 동의합니다).

1. 전체 팀에게 이것이 최선의 방법임을 설득하고 해결하도록하십시오.
2. 상사에게 이것이 최선의 일임을 설득하고 의무화하십시오. 그런 다음 수정해야합니다.

나는 당신의 경우 1이 더 이상 실현 가능하지 않다고 생각합니다. 또한 이것은 생산성 결과에 표시되는 경고의 수로 인해 시간이 오래 걸리므로 관리자는 어쨌든 알아야합니다.

그래서 제 제안은 : 상사와 함께이 폭탄을 확인하고 공식 정책을 세우도록하십시오.

나는 그들 중 대부분이 중요하지 않은 경고라고 말하고 목록에서 제거해야합니다. 우리는 그것이 일어날 때 군중의 진정한 경고를 놓치지 않을 것입니다!

페어 프로그래밍을 할 때 경고를 제거하면 다른 사람들이 습관을 습득하는 데 도움이 될 것입니다. 효과적인 Java '항목 24 : 확인되지 않은 경고 제거'(일반 수집의 경우)를 읽도록 제안하십시오. 사람들이 당신의 조언을 따르지 않을 때 아마도 많은 사례를 무시하십시오.)

여기서 효과적인 접근 방식 은 프로젝트를 자동으로 빌드하고 누구나 코드를 체크인 할 때마다 테스트를 실행 하는 Continuous Integration 서버 를 설정하는 것 입니다. 아직 이것을 사용하고 있지 않다면, 그렇게해야한다는 이점을 다른 사람들에게 납득시키는 것은 그리 어렵지 않습니다.

1. 관리 / 팀이이 작업의 이점을 확신시킵니다 (불량한 빌드가 배포되는 것을 방지하고, 특히 소프트웨어의 다른 부분에 실수로 영향을 미치는 버그를 조기에 발견하거나, 회귀 테스트를 유지 관리하고, 조기에 자주 테스트하는 등) 버그를 예방합니다)

2. 모든 테스트를 통과 한 CI 서버를 설치합니다 (테스트가없는 경우 통과하는 빠른 서버를 작성하여 모든 사람이 녹색으로 표시됨).

3. 각 빌드 상태에 대한 이메일 또는 기타 알림을 설정하십시오. 코드를 체크인 한 사람, 변경 내용 (또는 커밋에 대한 링크) 및 빌드의 상태 + 출력을 포함시키는 것이 중요합니다. 성공과 실패 모두에 대한 팀 전체의 가시성을 유발하므로 중요한 단계입니다.

4. 경고가있는 경우 테스트가 실패하도록 CI 서버를 업데이트하십시오. 이것은 경영진과 팀장이 볼 때 체계적인 방식으로 팀의 규율을 높이는 것으로 볼 수 있으며, 모든 실패 이메일에 대해 책임을지지 않으려는 사람은 없습니다.

5. (선택 사항) 빌드 상태와 누가 파산 / 고쳤는지 표시하기 위해 대시 보드, 용암 램프, 깜박이는 등을 추가하여 멋지고 괴짜를 얻습니다.