코드 검토가 좋은 것으로 보스를 설득하는 팁 [닫기]


20

프로젝트에서 거의 협력하지 않는 개발자가 여러 명인 가상의 회사에서 근무하고 있으며 보스가 코드 검토가 시간과 비용이 가치가 있다고 생각하지 않았다고 가정 해 봅시다.

이 시나리오에서 코드 검토의 이점을 설명 할 수있는 다양한 주장은 무엇입니까? 또한 코드 검토에 대한 잠재적 인 주장은 무엇이며 어떻게 대응할 수 있습니까?

답변:


25

그런 기본적인 것들에 대해 자신을 정당화해야한다면 더 큰 문제가 있습니다.

당신은 전문가이며, 팀은 어떤 관행을 사용할 것인지 결정해야합니다. 아마도 당신은 상사에게 그 매우 중요한 원칙을 확신시키기 시작해야 할 것입니다.

당신의 상사는 무엇 을해야하고 더 중요한 것은 해야하는지 결정해야 합니다. 어떻게 구축 해야합니까

(그렇다고해서 회사에서 무엇을 왜해야하는지 제안 할 수는 없습니다). 훌륭한 상사는 직원들이 엔터프라이즈 전략에 참여하도록 장려해야합니다)

그러나 피어 코드 리뷰를 보는 방법은 다음과 같습니다.

프로그래밍은 매우 집중적 인 지적 작업이므로 한 사람이 모든 것을 완벽하게 보장 할 수는 없습니다. 따라서 코드 검토는 다음을 보장합니다.

  • 앱이 출시되기 전에 취약점 또는 버그가 발견되었습니다.
  • 개발자들 간의 지속적인 상호 교육 (거의 무료) 달성
  • 더 쉬운 앱 유지 관리를위한 코드 존중 표준
  • 요구 사항과 일치하는 코드

모두가 직접 혜택을 받고 있습니다.

  • 지식을 향상시키고 자신의 팀 동료에게 자신을 전달할 수있는 개발자
  • 버그가 적고 유지 보수 비용이 적은 고객 / 사용자
  • 더 많은 고객 / 사용자를 보유하고 교육 비용을 절감하는 상사

1
평균 65 %의 결함을 발견 할뿐만 아니라, 단위 테스트에서 일반적으로하지 않는 결함도 많이 포착합니다.
Spudd86

공유 할 연구 링크가 있습니까? 나중에 사용할 수 있습니까?

2
그는 "Bits of Evidence" 라는 Greg Wilson의 프레젠테이션의 슬라이드 21에서 "첫 번째 테스트를 실행하기 전에 엄격한 검사를 통해 오류의 60-90 %를 제거 할 수 있습니다."(Fagan 1975) 그는 큰 인용을 받았습니다. :)
Scott Whitlock

7

코드 검토를 통해 여러 개발자가 동일한 코드에 익숙해 질 수 있습니다. 이것은 좋은 일입니다. 원저자가 금연을 결정하면 나쁜 일이 생깁니다. 코드 검토가 정기적으로 수행되면 다른 사람들이 신속하게 인계받을 수 있습니다.

동료는 코드 검토 중에 잠재적 인 버그 나 성능 문제를 발견 할 수 있습니다. 이를 통해 QA 및 개발 노력이 줄어 듭니다. 이를 통해 코드 검토와 관련된 추가 비용을 보상 할 수 있습니다.

코드 검토는 지식 공유를 촉진합니다. 동료들은 더 나은 방법이나 다른 방법으로 일을 할 수 있습니다. 코드 검토를 통해 동료들로부터 많은 것을 배웠습니다.

코드 검토는 팀이 따르는 코딩 지침을 강화하는 데 도움이됩니다. 팀에 팀이 없으면 수정해야합니다. 코드는 한 번 작성하고 여러 번 읽도록되어 있습니다. 코딩 지침은 읽을 수있는 코드를 향한 단계입니다. 피어는 코드를 읽을 수 있어야합니다. 가독성을 보장하기 위해 코드 검토를하는 것보다 더 좋은 방법은 무엇입니까?


4

여기에 많은 좋은 답변이 있습니다. 내가 추가 할 것들 :

다른 사람에게 코드를 설명해야 할 때, 종종 설명 과정에서 개발자는 갑자기 자신에게 버그가 있음을 알 수 있습니다. 나는 개발자가 자신의 트랙에서 죽는 것을 멈추고 리뷰어가 버그를 볼 수있을만큼 충분히 이해하기 전에 "오, 그게 잘못 기다려"라고 말하는 것을 반복해서 보았다.

다른 사람이 코드를 검사한다는 사실을 알면 코딩 표준을 사용하거나 (유지 관리가 더 쉬워 지거나) 자신을 제외한 다른 사람이 이해하지 못하는 "카우보이"방법을 덜 사용하게됩니다. 다른 사람에게 코드를 보여줄 때 당황하지 않기를 원하기 때문에 처음부터 더 나은 작업을 수행 할 수 있습니다. 난처한 요인으로 인해 "이것이 왜 효과가 있는지 모르지만 엉망이되지는 않습니다."라는 주석이 덜 남습니다. 코드베이스에서.

보다 광범위한 감독 또는 교육이 필요한 개발자를 쉽게 식별 할 수 있습니다. 따라서 무능한 사람도 있습니다. 성능 문제를 빨리 찾아서 해결할 수있을수록 팀 전체가 향상되고 응용 프로그램의 품질이 향상됩니다. 교육이 필요한 새로운 직원을 고용하여 응용 프로그램에서 가장 어려운 부분에 할당하기 전에이 정보를 확인하는 것이 좋습니다.

때로는 다른 곳에서도 같은 실수를 저지르는 오해를 바로 잡는 문제 일뿐입니다. 예를 들어 최근에 복잡한 보고서에 대한 일부 SQL을 검토 한 결과 일부 새로운 개발자는 데이터베이스에서 특정 정보를 찾을 위치에 대해 동일한 오해가 있음을 발견했습니다. 또한 모든 보고서를 올바르게 작성하는 데 중요한 수정해야합니다. 작성한 첫 번째 보고서에서 문제점을 찾아서 수정함으로써 나머지 보고서에서 발생하는 것과 동일한 오류가 발생하지 않았습니다. 그리고 나이가 들지 않은 나이가 많은 개발자들은 설명이 필요하다고 생각하지 않는 데 익숙해졌습니다.

주니어는 시니어 (예 : 오류 트래핑 및 엣지 사례를 더 잘 이해하는 경향이 있음)가 작성한보다 정교한 코드를 통해 배울 수 있으며, 시니어는 아직 노출되지 않은 주니어가 사용하는 새로운 기술을 배울 수 있습니다.

때때로 응용 프로그램의 서로 다르지만 관련 부분에서 작업하는 사람들은 서로 다른 배타적 인 두 방향으로 가고 있다는 것을 알고 있습니다. 죄송합니다. 지금 쉽게 고칠 수 있습니다.

하드 코딩 된 값으로 몰래 들어가는 것은 쉽지 않습니다. 시간이 지남에 따라 지금 일을하기 위해 변경 될 것입니다. 이것은 매 회계 년도 초에 변경되는 것들과 같은 많은 미래 버그를 방지합니다.

때로는 무언가를 수행하는 방법에 갇혀 있었고 다른 사람의 물건을 검토하는 코드에서 원하는 새로운 기술을 배웠습니다.

팀의 다른 구성원이 어떻게 생각하는지 이해하면 (어떻게 코드를 검토하면 이해를 도울 수 있는지) 나중에 Joe가 어떻게 이런 종류의 접근 방식에 접근했는지 이해하기 시작하므로 문제를 해결하는 것이 더 쉬울 것입니다 문제.


2

다른 사람들이 언급 한 지식 공유뿐만 아니라 코드 검토 중에 발견 된 버그의 예를 찾아 수정하는 데 걸린 시간을 측정하십시오. 여기에는 문제를 조사하고 패치 된 버전을 릴리스하는 데 소요 된 시간이 포함됩니다. 버그 수정 실제 시간.

이 비용은 아마도 최소한 며칠의 노력이 필요하며 코드 검토 및 결과 수행에 소요 한 시간과 대조하십시오.

그러면 코드 검토에 비용이들 것입니다.


2

코드 리뷰

  • 공유 할 수있는 코드 라이브러리 개발로 연결
  • 변수, 상수, 데이터베이스 테이블에 대해 균일 한 이름 지정 규칙을 제공하십시오.
  • 프로세스 간소화
  • 발견 프로세스 및 요구 사항 수집을 검토 할 수도 있습니다.
  • 애플리케이션의 애드온으로 판매 할 수있는 위젯 개발로 이어집니다. ( 우리가 그것을 구현할 때마다 한 번 돈을 지불하십시오 )
  • 새로운 제품으로 연결

단점

  • 그럴 시간이 없어

그것이 사실이라면 우리는 어떻게 같은 고객을 위해 항상 두세 번 일을 할 시간이있는 것처럼 보이지만 처음에는 제대로 할 시간이 없습니다.


0

문서를 참조해야한다면 존경받는 "코드 완성"을 보지 않아도됩니다. 이 책에서는 단위 테스트와 동료 검토에서 발견되는 오류 수를 설명합니다. 놀랍습니다. 단위 테스트는 메모리가 제대로 작동하면 모든 버그의 ~ 30 % 만 잡는 반면 공식적인 동료 리뷰는 ~ 70 %를 잡습니다.

그 정보를 가지고 책에 그를 보여주고 그의 재정적 측면에 호소하십시오. 버그를 조기에 포착하는 것보다 버그를 허용하는 데 훨씬 오래 걸리고 훨씬 비쌉니다.


0

두 팀이 병렬로 실행 한 데모 (1 주일 "미키 마우스"유형 프로젝트)를 실행하는 방법은 어떻습니까? 하나는 코드 검토를 사용하고 다른 하나는 그렇지 않습니다.

주말에 각 팀의 작업 품질을 평가하면 코드 검토자가 더 나아질 것이라고 확신합니다.


각 팀의 4 명 = 8 명 = 2 개월 급여. 많은 조직에서 상당히 많은 설득력이 필요합니다. :)
Michael Durrant


0

발표 할 때 더 큰 그림에 초점을 맞추십시오.

이점 (더 나은 코드, 적은 버그, 적은 재 작성 등) 을 나열하고 권장하는 기술 중 하나로 코드 검토를 언급 하십시오.

나는 그것을 소프트웨어 장인 정신의 더 큰 그림의 일부로 만들 것입니다

  • 코드 리뷰
  • 테스트
  • 회고
  • 지식 공유
  • 교육
  • 서평
  • 점심 시간 강의

이러한 원칙을 홍보하는 데 많은 노력을 기울일 준비를하십시오.
가장 설득력있는 설득은 "한 번의 회의와 완료"일 것으로 예상되지 않습니다.
침착하고 일관되게 시간이 지남에 따라 사례를 구축해야합니다. 더 나은 기술로 해결 된 버그에 가장 화가 났을 때 지나치게 감정적이면서도 덜 합리적 일 가능성이 높기 때문에 최악의 경우입니다. 이것은 다소 반 인식적인 것처럼 보일 수 있지만 30 년 동안 프로그래밍을 통해 배운 것입니다. 분명히 ymmv.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.