주니어 소프트웨어 엔지니어 인 저는 항상 더 나은 코더가되는 법을 배우기 위해받은 코드 검토 주석을 읽었습니다. 그러나 첫 번째 코드 검토를 시도해야 할 시점이되었을 때, 내 경험으로 상대방이 될 준비가되지 않았다는 것을 깨달았습니다.
나는 다음과 같이 질문으로 나선형으로 진행되는 심각한 임 포스터 증후군 사례를 개발했다. 이 코드 라인에 대해 의견을 말해야합니까? 모든 의견을 뒷받침 할 기사를 찾아야합니까? 이것을 승인하면 사이트가 중단됩니까? 그들이 날 미워 할까? 좋아, 나는 나선을 매우 빨리 인정한다. 그러나 일부 동료들과 이야기를 나눈 후, 나는 혼자 걱정하지 않는다는 것을 알았습니다.
GitHub의 경험 엔지니어 인 제시카 러더 (Jessica Rudder)는 주니어 소프트웨어 엔지니어가“책을 읽는 방법을 알고 있으므로 책을 쓰는 방법을 알고있다”는 가정하에 코드를 검토 할 수있다.
코드 검토와 함께 제공되는 기대치가 있으며 프로세스가 신경을 쓰게 할 수 있습니다. 그래서 다른 소프트웨어 엔지니어 7 명과 인터뷰하여 리뷰 사고 방식을 만드는 방법에 대한 팁을 수집했습니다.
1. 전체적인 영향에 대해 생각
일반적으로 PR (Good Pull Request)은 코드베이스의 제한된 부분에만 영향을 미칩니다. 그러나 제한된 범위로 인해 더 큰 코드베이스의 컨텍스트 내에서 코드 변경에 대해 생각할 수는 없습니다.
Muse의 전 풀 스택 엔지니어이자 현재 프리랜서 소프트웨어 엔지니어 인 Nigel Munoz는 검토자가 "이 변경이 더 크고 작은 그림에 어떤 영향을 미치는지"에 대해 생각해 보도록 권장합니다. 더 큰 그림을 고려할 때는 기술적 부채 찾기 - 코드 찾기 이는 코드베이스의 아키텍처에 대한 수정 사항을 분석 할뿐만 아니라 반복되거나 비 모듈식이거나 최신 표준 규칙을 준수하지 않습니다.
Hudson River Trading의 핵심 개발자 인 Sam Donow는 다음과 같이 말합니다. 작은 개선에 대한 제안은 코드베이스의 여러 부분에서 더 큰 개선으로 이어질 수 있습니다.”
GitHub에 대한 PR 주석을 사용하여 긍정적 인 피드백을 제공 할뿐만 아니라 코드가 프레임 워크 React의 표준 규칙과 다른 위치를 지적 할 수 있습니다.
예를 들어, 내 코드 검토 중 하나에서 React 구성 요소의 특정 속성이 혼란 스럽다는 의견을 받았으며 구성 요소 사용 방법에 대한 더 많은 질문이 생겼습니다. 궁극적으로 원래 구성 요소에서 속성을 제거하고 각 구성 요소의 동작을 명확히하고 더 많은 장소에서 사용할 수 있도록 별도의 구성 요소를 만들었습니다.
2. 보안 고려
일부 변경 사항은 코드베이스 이상의 영향을 미칠 수 있습니다. Rudder는 사용자가 "이 기능을 사용하여 누군가를 괴롭 히거나 시스템을 악용 할 수 있는지"를 평가할 것을 권장합니다. 예를 들어, 풀 요청의 새로운 기능에 사용자 입력이 포함 된 경우 SQL 삽입, 데이터 액세스, 사이트 간 스크립팅 및 다른 보안 취약점.
3. 버그에 집중
동료의 코드 기고자들은 로봇의 모양에 관계없이 인간이며 인간은 기능을 잃거나 잊어 버릴 수 있습니다. 따라서 Teachers Pay Teachers의 기술 책임자 인 Abhishek Pillai는“다른 코드와 동일한 중요성으로 테스트를 검토하십시오. "그들은 새로운 버그를 예방하고 앞으로이 문제를 해결하는 다른 사람들에게 문서의 형태로 사용될 것입니다."
테스트를 읽으면 새 기능의 기능을 이해하고 그 기능이 도입 될 다양한 사례를 확인할 수 있으며 테스트를 분석하면 누락 된 사례를 지적하고이 PR에 포함되지 않은 기능을 찾을 수 있습니다. 코드 변경에 포함 된 테스트가없고 관련이있는 경우 검토 내에서 요청하는 것이 좋습니다.
그러나 테스트가 전부는 아닙니다. Donow는“시스템에 너무 많은 믿음을 두지 마십시오. "테스트가 실행되었다고해서 버그가 없다는 것은 아닙니다."
또한“앱을 로컬에서 실행하여 기능적으로 테스트하여 작동하는지 확인하고 싶을 수도 있습니다. 그래도 작동하지 않으면 더 이상 검토 할 필요가 없습니다.”라고 8th Light의 소프트웨어 개발자 Ryan Verner는 말합니다. 일부 검토 자들은 수동 테스트가 코드 검토 프로세스의 일부 여야한다고 생각하지 않지만 (일부 시간이 걸리기 때문에) Verner는 검토에 더 많은 시간을 투자해야하는지 여부를 줄이는 빠른 방법이 될 것이라고 생각합니다. 버그 백 로그의 성장.
4. 팀 플레이어가 되십시오
클리셰는 코드를 검토 할 때 새로운 의미를 갖습니다. “집단적 소유권”을지지하는 베르너는“모든 사람의 코드베이스이므로 검토 할 시간을 가지십시오”라고 말합니다. 검토 자로서 귀하는 버그를 줄이려는 목적으로 버그의 백 로그가 커지지 않도록 노력해야합니다 팀이 줄을 서서히 줄입니다
Pillai는 gif를 사용하여 팀원의 승인되고 병합 준비가 된 PR을 축하합니다.
동시에 The Muse의 기술 책임자 인 Charles Luxton은 검토자가 팀의 우선 순위를 이해하고 기억하도록 권장합니다. 빠르게 다가오는 마감일과 의견 불일치가 커짐에 따라 때때로 백 로그에 대한해야 할 일 항목을 작성하여 향후 개선이 이루어 지도록하고 문제의 코드에 대한 의견을 제시하는 것은 그 동안 필요한 반창고입니다. 팀을 행복하게하십시오.
마지막으로, 팀에 합류하여 처음 몇 주 내에 코드를 읽은 사람에게 코드가 적합한 지 자문 해 보면 코드를 읽고 이해하기 쉽게 유지할 수 있습니다.
5. 학습 및 지식 공유 프로세스 사용
검토 프로세스를 통해 참여한 모든 사람이 코드베이스, 언어, 프레임 워크 및 모범 사례에 대한 통찰력을 얻을 수 있습니다.
The Muse의 기술 책임자 인 Matt Jeffery는 검토 자에게 "변경 사항을 구조적으로 이해하도록 조언합니다. 한 가지 방법은 컨텍스트를 제공하는 데 도움이되므로 파일 이름을 읽는 것입니다. 예를 들어 데이터 액세스 계층의 변경을보고있는 경우 비즈니스 로직이나 UI를 다루지 않는다는 것을 알고 있습니다. "
GitHub의 PR 주석을 사용하여 문서를 공유 할 수 있습니다.
코드 변경을 통해 배우면 지식을 공유 할 수있는 기회도 있습니다. Luxton은“의견을 설명하고이를 문서화하여 백업하는 것이 가장 좋습니다. 증거 및 신뢰할 수있는 기사를 지원하기 위해 제공하는 링크는 검토 자와 코드 작성자가 최종 결정을 내릴 때 다양한 접근 방식을 탐색하는 데 도움이 될뿐만 아니라 프로그래밍에 대한 지식을 강화합니다.
이 요령을 명심하면서 검토는 사람들의 기술을 연습 할 때라는 점을 기억하십시오. Rudder는“사람들이 자신의 접근 방식에 대해 생각하고 방어 가능성을 없애려고 노력하면서 다른 가능성을 지적한다는 의심의 혜택을 제공합니다. "저는 전체적으로 의견을 남기고 마무리합니다. 여기에 무엇이 좋으며, 개선 할 수있는 것이 있으며, 병합하기 전에 변경해야 할 것이 있습니다."
이러한 접근 방식을 사용하면 기술 부채, 보안 위협 및 버그로부터 코드 기반을 보호 할뿐만 아니라 팀을 구성 할 수 있습니다.
