혹시 여러분을 힘들게 했던 기억나는 코드리뷰 있으신가요? 분명 더 좋은 품질의 코드를 만드려고, 더 협업을 잘 해보려고 하는 코드 리뷰인데, 생산성이 계속 떨어지고, 아무도 관심도 안 가져서 잊혀져 가는 PR 보신적 있지 않으신가요? 이러한 잘 이루어지지 않는 PR의 배경에는 엔지니어링 워크플로우의 4가지 근본적인 문제가 있다고 합니다. 1. PR의 리뷰어를 할당받는 공식적인 절차가 없다. 2. PR 크기에 대한 표준화 또는 모범사례가 없다. 3. 모든 PR의 중요도가 모두 같다. 4. PR 컨텍스트에 대한 설명이 부족하거나 리뷰 시간이 너무 부족하다. 그렇다면 이러한 환경에 있을 때 어떤 안좋은 모습의 풀 리퀘스트들이 생겨날까요? 1. 문서 작업과 같은 너무나도 사소한 PR - 다른 영향이 없기 때문에 그냥 나가도 되는데 작업 시간만 길어짐. 2. 오래된 코드가 포함된 PR - 더 이상 사용하지 않는 코드 작업하여 리뷰 요청. 지금 시스템 현 상태에 대한 싱크가 제대로 이루어 지고 있지 않음. 3. 적절한 작업 문서를 첨부해 주지 않는 PR : 관련 위키나 기획서가 빠져있으면 문맥을 알기 어렵다. 4. 영향도는 큰데, 한명에게만 리뷰 요청하는 PR 5. dependency가 줄줄이 있는 PR : 하나가 밀리면 뒤에까지 계속 기다려야하는 리뷰이면 뒷 작업까지 영향을 줄 수 있음. 6. 명확하지 않은 PR : 목적이 분명치 않거나 한번에 여러 문제를 해결하려는 PR은 제대로 된 리뷰를 방해할 수 있다. 7. 보안 위험이 그대로 들어나는 PR : 민감한 정보를 다루는 코드인데 보안 팀의 리뷰를 요청 안하는 경우 8. 도메인 전문가가 봐야 하는데 리뷰 요청 안하는 PR 9. 테스트 없는 PR 10. 컨택스트가 없어서 조사해야하는 PR 11. 기존 코드를 삭제하는 PR : 코드를 삭제하는 작업은 알기 어려운 사이드 이펙트를 만들 수 있으므로 각별한 주의가 필요하다. 이러한 악성 풀 리퀘스트를 막으려면 어떻게 해야할까요? 1. 페어 프로그래밍 : 두 명의 개발자의 리소스를 사용하지만 결과적으로는 코드의 결함률을 낮추어 주고 2. Continous Merge : 자동화된 테스트와 코드 분석을 통과하면 자동으로 계속 머지되도록 하는 방법 - 리뷰어를 자동으로 할당 (예상 검토 시간 포함) - 리파지토리의 중요도/위험도에 따라 PR 분류 - 위험도가 낮은 PR에 대해서는 자동 승인 아직 PR로 리뷰를 꼭 받고 main 브랜치에 머지되어야 한다는 고정관념(?) 때문에 continous merge 개념이 좀 생소하기는 한데요. 점점 더 빠르게 기능을 구현해야하는 현대 개발 문화에서 post merge code review 역시 한번쯤 고려해볼만 하지 않을까 하는 생각이 드네요! https://devinterrupted.substack.com/p/the-11-types-of-toxic-pull-requests