답변:
그런 기본적인 것들에 대해 자신을 정당화해야한다면 더 큰 문제가 있습니다.
당신은 전문가이며, 팀은 어떤 관행을 사용할 것인지 결정해야합니다. 아마도 당신은 상사에게 그 매우 중요한 원칙을 확신시키기 시작해야 할 것입니다.
당신의 상사는 무엇 을해야하고 더 중요한 것은 왜 해야하는지 결정해야 합니다. 어떻게 구축 해야합니까
(그렇다고해서 회사에서 무엇을 왜해야하는지 제안 할 수는 없습니다). 훌륭한 상사는 직원들이 엔터프라이즈 전략에 참여하도록 장려해야합니다)
그러나 피어 코드 리뷰를 보는 방법은 다음과 같습니다.
프로그래밍은 매우 집중적 인 지적 작업이므로 한 사람이 모든 것을 완벽하게 보장 할 수는 없습니다. 따라서 코드 검토는 다음을 보장합니다.
모두가 직접 혜택을 받고 있습니다.
코드 검토를 통해 여러 개발자가 동일한 코드에 익숙해 질 수 있습니다. 이것은 좋은 일입니다. 원저자가 금연을 결정하면 나쁜 일이 생깁니다. 코드 검토가 정기적으로 수행되면 다른 사람들이 신속하게 인계받을 수 있습니다.
동료는 코드 검토 중에 잠재적 인 버그 나 성능 문제를 발견 할 수 있습니다. 이를 통해 QA 및 개발 노력이 줄어 듭니다. 이를 통해 코드 검토와 관련된 추가 비용을 보상 할 수 있습니다.
코드 검토는 지식 공유를 촉진합니다. 동료들은 더 나은 방법이나 다른 방법으로 일을 할 수 있습니다. 코드 검토를 통해 동료들로부터 많은 것을 배웠습니다.
코드 검토는 팀이 따르는 코딩 지침을 강화하는 데 도움이됩니다. 팀에 팀이 없으면 수정해야합니다. 코드는 한 번 작성하고 여러 번 읽도록되어 있습니다. 코딩 지침은 읽을 수있는 코드를 향한 단계입니다. 피어는 코드를 읽을 수 있어야합니다. 가독성을 보장하기 위해 코드 검토를하는 것보다 더 좋은 방법은 무엇입니까?
여기에 많은 좋은 답변이 있습니다. 내가 추가 할 것들 :
다른 사람에게 코드를 설명해야 할 때, 종종 설명 과정에서 개발자는 갑자기 자신에게 버그가 있음을 알 수 있습니다. 나는 개발자가 자신의 트랙에서 죽는 것을 멈추고 리뷰어가 버그를 볼 수있을만큼 충분히 이해하기 전에 "오, 그게 잘못 기다려"라고 말하는 것을 반복해서 보았다.
다른 사람이 코드를 검사한다는 사실을 알면 코딩 표준을 사용하거나 (유지 관리가 더 쉬워 지거나) 자신을 제외한 다른 사람이 이해하지 못하는 "카우보이"방법을 덜 사용하게됩니다. 다른 사람에게 코드를 보여줄 때 당황하지 않기를 원하기 때문에 처음부터 더 나은 작업을 수행 할 수 있습니다. 난처한 요인으로 인해 "이것이 왜 효과가 있는지 모르지만 엉망이되지는 않습니다."라는 주석이 덜 남습니다. 코드베이스에서.
보다 광범위한 감독 또는 교육이 필요한 개발자를 쉽게 식별 할 수 있습니다. 따라서 무능한 사람도 있습니다. 성능 문제를 빨리 찾아서 해결할 수있을수록 팀 전체가 향상되고 응용 프로그램의 품질이 향상됩니다. 교육이 필요한 새로운 직원을 고용하여 응용 프로그램에서 가장 어려운 부분에 할당하기 전에이 정보를 확인하는 것이 좋습니다.
때로는 다른 곳에서도 같은 실수를 저지르는 오해를 바로 잡는 문제 일뿐입니다. 예를 들어 최근에 복잡한 보고서에 대한 일부 SQL을 검토 한 결과 일부 새로운 개발자는 데이터베이스에서 특정 정보를 찾을 위치에 대해 동일한 오해가 있음을 발견했습니다. 또한 모든 보고서를 올바르게 작성하는 데 중요한 수정해야합니다. 작성한 첫 번째 보고서에서 문제점을 찾아서 수정함으로써 나머지 보고서에서 발생하는 것과 동일한 오류가 발생하지 않았습니다. 그리고 나이가 들지 않은 나이가 많은 개발자들은 설명이 필요하다고 생각하지 않는 데 익숙해졌습니다.
주니어는 시니어 (예 : 오류 트래핑 및 엣지 사례를 더 잘 이해하는 경향이 있음)가 작성한보다 정교한 코드를 통해 배울 수 있으며, 시니어는 아직 노출되지 않은 주니어가 사용하는 새로운 기술을 배울 수 있습니다.
때때로 응용 프로그램의 서로 다르지만 관련 부분에서 작업하는 사람들은 서로 다른 배타적 인 두 방향으로 가고 있다는 것을 알고 있습니다. 죄송합니다. 지금 쉽게 고칠 수 있습니다.
하드 코딩 된 값으로 몰래 들어가는 것은 쉽지 않습니다. 시간이 지남에 따라 지금 일을하기 위해 변경 될 것입니다. 이것은 매 회계 년도 초에 변경되는 것들과 같은 많은 미래 버그를 방지합니다.
때로는 무언가를 수행하는 방법에 갇혀 있었고 다른 사람의 물건을 검토하는 코드에서 원하는 새로운 기술을 배웠습니다.
팀의 다른 구성원이 어떻게 생각하는지 이해하면 (어떻게 코드를 검토하면 이해를 도울 수 있는지) 나중에 Joe가 어떻게 이런 종류의 접근 방식에 접근했는지 이해하기 시작하므로 문제를 해결하는 것이 더 쉬울 것입니다 문제.
코드 리뷰
단점
그것이 사실이라면 우리는 어떻게 같은 고객을 위해 항상 두세 번 일을 할 시간이있는 것처럼 보이지만 처음에는 제대로 할 시간이 없습니다.
두 팀이 병렬로 실행 한 데모 (1 주일 "미키 마우스"유형 프로젝트)를 실행하는 방법은 어떻습니까? 하나는 코드 검토를 사용하고 다른 하나는 그렇지 않습니다.
주말에 각 팀의 작업 품질을 평가하면 코드 검토자가 더 나아질 것이라고 확신합니다.
Steve Mcconnel의 Construx 에서 더 나은 소프트웨어 실행을위한 비즈니스 사례 및 소프트웨어 소프트웨어 개발의 LHF ( Low Hanging Fruit )가이를 해결합니다. 후자에서 "상급 경영진이 저항하지 않는 LHF"에는 점검이 나열되어 있습니다.
발표 할 때 더 큰 그림에 초점을 맞추십시오.
이점 (더 나은 코드, 적은 버그, 적은 재 작성 등) 을 나열하고 권장하는 기술 중 하나로 코드 검토를 언급 하십시오.
나는 그것을 소프트웨어 장인 정신의 더 큰 그림의 일부로 만들 것입니다
이러한 원칙을 홍보하는 데 많은 노력을 기울일 준비를하십시오.
가장 설득력있는 설득은 "한 번의 회의와 완료"일 것으로 예상되지 않습니다.
침착하고 일관되게 시간이 지남에 따라 사례를 구축해야합니다. 더 나은 기술로 해결 된 버그에 가장 화가 났을 때 지나치게 감정적이면서도 덜 합리적 일 가능성이 높기 때문에 최악의 경우입니다. 이것은 다소 반 인식적인 것처럼 보일 수 있지만 30 년 동안 프로그래밍을 통해 배운 것입니다. 분명히 ymmv.