코드 검토는 누가해야합니까?


12

우리 회사에서는 주로 건축가가 코드 검토를 수행합니다. 그는 경험이 풍부하고 똑똑한 소프트웨어 전문가이므로 매우 능숙합니다. 개발자가 코드 검토를 할 때는 절반도하지 않습니다. 개발자에게 더 많은 코드 검토를하려고했지만 코드 검토의 품질이 좋지 않았습니다. 우리는 개발 방법론으로 Scrum을 사용합니다.

그러나 현재 시스템에는 두 가지 문제가 있습니다.

  1. 건축가가 병목이 됨

  2. 개발자는 코드의 품질과 아키텍처 (모든 종류의 문제를 야기)에 대해 책임을지지 않습니다.

이러한 문제를 어떻게 해결할 수 있습니까? 코드 검토 담당자를 변경해야합니까?



1
중복으로 보지 않습니다. 질문은 관련이 있지만 가능한 중복은 약간 다른 문제에 중점을 둡니다.
Bart van Ingen Schenau

'코드 검토 품질'이 의미하는 바를 확장 할 수 있습니까? 검토가 끝날 때 나타나는 코드의 품질을 의미합니까? 수용 가능한 품질의 코드를 생성 할 수있는 개발자가 한 명 뿐인 것 같습니다.이 경우 더 큰 문제가 있다고 말할 수 있습니다.
AakashM

답변:


15

개발자는 코드 검토를 수행해야합니다. 코드, 회사 스타일 표준 및 관행을 알아야하기 때문에 코드 검토를 수행해야합니다. 다른 사람이 코드 검토를하도록함으로써 개발자에게 코드가 회사 표준을 준수하는지 확인해야 할 책임이 없음을 알려줍니다.

코드 검토에 대한 교육이 필요하다고 생각되면이를 확인하십시오. 현재 상황에서 개발자는 코드 검토를 수행 한 다음 건축가가 주석을 달도록 할 수 있습니다. 개발자는 제출자에게 검토를 보내기 전에 검토를 건축가에게 제출하여 승인을 받아야합니다.


2
" 다른 사람이 코드 검토를하도록함으로써 개발자에게 코드가 회사 표준을 충족시키는 것은 자신의 책임이 아니라고 말하고 있습니다. "-예, 아니오. 또한 "귀하의 코드는 (필수적으로) 중요한 동료 검토 대상이 되므로 처음부터 올바르게 수행하는 것이 좋습니다."라고 말합니다.
JensG

@JensG : OP의 상황에서 검토를하는 동료는 아닙니다.
jmoreno

3
그래서 대담하게 만들었습니다.
JensG

8

이 상황에서 필요한 것은이 숙련 된 개발자의 지식이 나머지 팀의 성장을 돕는 것입니다. 팀의 품질은 최고의 개발자의 기술로 정의되지 않습니다. 그것은 최악의 기술에 의해 정의됩니다. 다음과 같은 것을 시도해 볼 수 있습니다.

  • 공동 검토. 이것은 마지막 팀에서 정말 훌륭했습니다. 우리는 전체 팀을 프로젝터가있는 방에 넣고 일부 항목을 검토하기 시작했습니다. 아마도 처음에는 건축가가 검토를 안내하는 건축가 일지 모르지만 몇 주 (금요일마다 1-2 시간을 예약 함)에 전체 팀이 현재 건축가 만 알고있는 주요 개념을 말하고 이해하기 시작합니다.

  • 페어 프로그래밍. 나에게 이것은 팀에 지식을 전파하는 데 가장 좋은 도구입니다.


페어 프로그래밍의 경우 +1 사실, 그 질문에 대한 나의 첫 번째는 "모두"였지만, 페어 프로그래밍은 그것을 더 잘 못 박았습니다. 품질 측면 외에 학습의 원천으로 삼 으면 최대한 활용할 수 있다고 생각합니다.
JensG

3

시스템 / 소프트웨어 아키텍트가 모든 변경 / 커밋을 사인하도록하는 요점을 알 수 있지만, 소프트웨어 개발자는 아키텍트를 포함하지 않고 중재를 제외하고 검토를 수행 할 수 있어야합니다.

내가 선호하는 [*] 검토 절차는 다음과 같습니다.

  • 요구 사항 / 문제별로 그룹 변경.
  • 모든 개발자, 소프트웨어 아키텍트 및 요구 사항 / 문제의 작성자를 검토하도록 초대하십시오. (모두 검토 할 필요 는 없습니다 .)
  • 다음과 같은 경우 검토가 완료된 것으로 간주하십시오.
    • 두 개발자가 검토했습니다.
    • 모든 의견에 답변합니다. 소프트웨어 설계자가 결정을 내릴 수 있습니다.
    • 추가 논의없이 하루의 근무일이 지났습니다 (또는 초대 된 모든 당사자가 검토했습니다).

그래서 귀하의 질문에 대한 짧은 대답은 다음과 같습니다 . 개발자는 리뷰를 변경해야합니다.

[*] 불행히도 이것이 내가 참여하는 프로젝트가 항상 운영되는 방식은 아닙니다.


지금 항상, 또는 하지 항상?
Martijn 2019

당신이 짐작했듯이 "항상 그런 것은 아니다". 그것을 찾아 주셔서 감사합니다. 답변을 수정했습니다.
Jacob Sparre Andersen 8:21에

3

나는 팀 전체가 건축가를 포함하는 때때로 팀 코드 검토를하는 것을 좋아하지만, 팀의 두세 명 사이의 많은 코드 검토가 필요합니다.

실제로 까다 롭거나 민감한 코드 인 경우 건축가 또는 팀의 선임 구성원을 모집하십시오.

솔직히 말해서, 건축가가 코드 검토를하는 것은 어리석은 소리입니다. 자신의 전문 지식을 공유하기 위해 비공식적으로 설계 검토 또는 간혹 코드 검토를 수행해야합니다. 엔지니어링 팀은 코드를 책임 져야합니다. 문제가 있으면 시간이 지남에 따라 더 좋아질 것입니다.


2

한 사람 만 리뷰를한다면 나머지 사람들은 아마도 "모르지만 작동하는 것 같지만 똑똑한 사람이 괜찮다면 알아낼 수 있도록"하겠다고 동의 할 것입니다. 나는 다음을 생각할 수 있습니다.

  • 모든 사람이 작업중인 내용을 볼 수 있도록 코드를 공개하십시오. 코드가 포함 된 각 파일의 시작 부분에 이름을 입력하십시오. 어쩌면 욕실에서 인쇄해서 눈에 띄는 곳이면
  • 페어 프로그래밍; 옆에 다른 두뇌가 있으면 변수의 이름을 짓기 전에 두 번 생각할 것입니다.i
  • 관리인을 데려와 상속이 어떻게 작동하는지 설명하십시오 (오, 그래요, 작동하지 않습니다). 다른 사람에게 코드를 설명하면 도움이됩니다. 아마도 컴파일되고, 올바른 일을하지만 어쩌면 그 이유를 이해하지 못했습니다. 지금은 기회입니다
  • 일련의 지침을 가지고 모든 사람이 지침을 따르도록하십시오. 지침이 무엇이든, 지침이없는 것보다 낫다
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.