공식 코드 검토를 수행 할 때 도움이되는 사고 방식

Google 팀은 최근 각 체크인에 대해 코드 검토를 시작했습니다.

팀 리더로서 나는 너무 많은 제안을 제공하고, 개발자를 성가 시게하고 팀 출력을 줄이며, 다르게 작성했을 코드를 놓는 것 사이의 균형을 찾으려고 노력하고 있습니다.

유용한 접근 방식을 제안하는 잘 알려진 출처의 증거, 연구 또는 지침이 있습니까?

가장 중요한 목표를 명심하십시오 : 결국, 작동하는 소프트웨어 만 중요합니다

동료 검토 및 체크인 코드 검토는 품질 향상을 목표로 합니다 . 그러나 품질이 저하 된 개발자보다 더 나쁜 것은 없습니다. 팀 리더로서 여러분의 역할은 코드를 자신이 작성할 수있는 것으로 보증하는 것이 아니라 팀워크를 홍보하고 전반적인 결과를 보장하는 것입니다.

검토를위한 명확한 범위 설정

명심하십시오 : 그것은 당신의 코드가 아니라 팀의 코드입니다. 따라서 잘못된 결과를 초래할 수있는 것에 집중하십시오.

• 작동하지 않을 것이라고 확신하지 않는 한 개발자가 요구 사항을 충족하도록 선택한 방식에 도전하지 마십시오 (그러나 이미 테스트에 실패한 것입니까?).

• 문제의 위치를 ​​보여주는 조치가 없다면 성능 저하에 도전하지 마십시오. 조기 최적화는 모든 악의 근원입니다 ;-)

• 도전 할 디자인이나 소프트웨어 구조를 찾은 경우, 왜 앞서 붙 잡히지 않았는지 스스로에게 물어보십시오! 이미 작성된 코드는 다시 작성하는 데 비용이 많이 듭니다. 이 경우 최소한 코드만큼 소프트웨어 개발 및 팀워크 관행을 검토해야합니다.

• 확립 된 코딩 표준 준수를 해결합니다. 리뷰어와 리뷰어 모두에게 토론하는 것이 가장 성가신 주제입니다. 모두가 팀에서 대문자로 된 클래스 이름을 사용하기로 동의하고 한 남자가 클래스가없는 경우 맛의 문제입니까? 아니면 팀워크의 효과와 위험?

그런데 코딩 표준에 대해 논의 할 가치가 없다고 생각되면 표준에서 제거하고 시간과 에너지를 낭비하지 마십시오.

리더십 개발 : 검토의 인간적 측면

팀 리더는 품질 관리의 형식을 넘어 자신과 팀을 개발할 수있는 기회를 여기에서 찾을 수 있습니다.

• 진정한 교환이 있다면 코드 검토는 모든 사람에게 훨씬 더 즐겁습니다. 개발자에게 자신의 기술을 보여줄 수있는 기회를 제공하십시오 (그리고 아마도 새로운 것을 배울 수도 있습니다).
• 디자인 선택 또는 기존 표준에 대한 비판에 귀를 기울입니다. 때때로 사람들은 그것에 대해 이야기 할 수 있기 때문에 그러한 좌절에 더 잘 대처할 수 있습니다.
• 후배 코치 : 주저하지 말고 다음 번 반복을 위해 조언을하거나 방향을 리팩토링하십시오. 선배들과 함께하지 마십시오. 다른 세계에서는 각자의 역할이 바뀔 수 있습니다.

다른 관행 활용

코드 검토에서 피할 수있는 몇 가지 사항이 있습니다.

• 빌드 체인에서 정적 코드 분석기를 사용 하면 동료 검토 이전 에 일반적인 버그 또는 이식성이없는 구성 요소를 자동으로 찾을 수 있습니다 . 일부 도구는 일부 코딩 표준을 확인할 수도 있습니다. .
• 코드 레이아웃에 대한 표준이있는 경우 사전 커밋 프리티 프린트 또는 유사한 포맷터를 사용하십시오. 를 사용하여 필요에 따라 코드를 자동으로 포맷하십시오. 소프트웨어가 더 잘하고 당신을 위해 할 수있는 일에 시간을 보내지 마십시오 :-)
• 마지막으로, 품질은 검토뿐만 아니라 테스트를 통해서도 보장됩니다. 아직 TDD를 사용하지 않으면 코드 검토와 독립적으로 생각하십시오.

우리는 개발자로서 사고 방식은 항상 개방적이고 회의적인 태도를 유지해야합니다.

개발자가 언제 우리를 놀라게 할 지 알지 못하기 때문에 개방적입니다. 소프트웨어 엔지니어링에는 솔루션을 구현할 수있는 올바른 방법이 하나도 없다는 사실을 종종 잊어 버리기 때문에 자신의 아이디어에 회의적입니다. 솔루션의 배후에있는 이론적 근거는 우리에게는 합리적이며 다른 사람들에게는 적합하지 않습니다. 코드 냄새 뒤에는 좋은 아이디어가있을 수 있습니다. 아마도 개발자가 제대로 표현할 방법을 찾지 못했을 수도 있습니다.

우리 (인간)는 의사 소통에 끔찍하고, 잘못된 가정을하지 말고, 코드 소유자에게 검토중인 코드에 대해 기꺼이 물어보십시오. 회사의 표준에 따라 아이디어를 코딩하는 데 실패한 경우 리드 개발자가 기꺼이 안내 할 것입니다.

여기 주관적인 접근. 객관적인 접근 방식, IMO 는이 질문에 잘 설명 되어 있습니다. 있습니다.

위의 링크 외에도, 달성해야 할 목표 (유지 관리 성, 가독성, 이식성, 높은 응집력, 느슨한 결합 등)가 반드시 십계명 일 필요는 없습니다. 귀하 (팀)는 이러한 목표를 품질과 생산성 사이의 균형이 작업을 편안하고 "개발자가 거주 할 수있는"지점으로 만들 수 있어야합니다.

이러한 목표에 따라 품질 진행률을 측정하기 위해 정적 코드 분석 도구를 사용하는 것이 좋습니다. SonarQube와 같은 도구는 우선 순위에 따라 사용자 정의 할 수있는 품질 게이트 및 품질 프로파일을 제공합니다. 또한 개발자가 코드 냄새, 버그, 의심스러운 관행 등과 관련된 문제를 대상으로 할 수있는 문제 추적기를 제공합니다.

이런 종류의 도구는 좋은 출발점이 될 수 있지만 내가 말한 것처럼 스스로를 의심하십시오. Sonar에서 일부 규칙은 무의미 할 수 있으므로 무시하거나 품질 프로필에서 제거하십시오.

외관 변화에 대한 개발자 코드를 다루는 것은 개발자에게 동기를 부여하지만 절대적인 상황에서는 수행해야합니다. 리드는 유용한 코드 검토 제공 과 사소한 단점을 극복 할 수있는 학습 간의 균형을 찾아야합니다 . https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

명심해야 할 사항 :

1. 그것은 기술에 관한 것뿐만 아니라 심리학에 관한 것이므로 황금률은 없습니다.
2. 사람들에 관한 것은 지식뿐만 아니라 계층 구조와 문화에 관한 것입니다.
3. 이것이 "긴"게임 (안정적이고 설립 된 회사)이라면 사람들이 서로를 신뢰하는 잘 통합 된 팀은 일반적으로 검토중인 코드보다 더 높은 가치를 갖습니다. 절대로 진행하지 않아도되는 것을 강제하는 데 사용해서는 안됩니다. 악마는 세부 사항에 있습니다 ...
4. 이것이 "짧은"게임 (사이드 프로젝트, R & D, 그룹의 많은 프리랜서)이라면 CR 비용은 종종 그로 인한 출현을 극복합니다. 그리고 태도는 "그냥 깨워 야"

중요한 것은 두 가지뿐입니다.

1. 모든 요구 사항에 대한 자동화 된 테스트가 있습니까?
2. 그들은 모두 통과합니까?

다른 모든 것은 화장품이며 게이트로 시행하기보다는 맥주에 대해 논쟁해야합니다.

이보기를 따르면 좁은 초점 영역으로 제한됩니다.

요구 사항이 양호합니까? 작업을 시작하기 전에 성능, 보안 등을 모두 알고 있어야합니다.

테스트는 좋은 테스트입니까? 누락 된 엣지 사례는 요구 사항을 잘 테스트하고 있습니까? 궁극적으로 : 기존 요구 사항에 대한 테스트를 작성할 수는 있지만 실패 할 수 있습니까?