범위 확대 방지

"범위 확대"는 단일 기여로 해결되는 문제 목록이나 구현되는 기능이 작업 시작 시 의도했던 범위를 크게 벗어날 때 발생합니다. 간단한 이슈로 시작했는데, 밀접하게 관련된 문제를 발견하고 그 수정도 포함하기로 결정합니다. 그러다 세 번째 문제가… 어느새 5개의 이슈를 해결하고 3개의 새 기능을 추가하며 수십 개의 파일을 포함하는 풀 리퀘스트가 완성됩니다.

범위 확대는 누구에게나 발생합니다. 이는 노련한 개발자들에게 너무나도 익숙한 개념입니다. 우리 모두 여러 번 경험했고, 그로 인해 발생하는 모든 문제점도 겪어봤습니다.

범위 확대를 피해야 하는 매우 실용적인 이유가 있습니다. 기여물이 커질수록 작업하기가 더 어려워집니다. 경계 사례나 잠재적 문제를 식별하기가 더 어려워지므로, 기여물의 전반적인 품질이 저하될 수 있습니다. 리뷰어들이 서로 관련성이 없을 수 있는 여러 맥락을 처리해야 할 때 리뷰 작업도 더 어려워집니다. 기여 규모가 커질수록 리뷰 코멘트도 증가하며, 기여자로서 여러 리뷰 스레드를 추적하기 어려워질 수 있습니다. GitHub 사용 경험도 저하됩니다. PR 규모가 커질수록 GitHub UI가 느려져, GitHub 인터페이스를 통해 파일을 탐색하거나 리뷰 코멘트를 남기기가 점점 더 어려워집니다.

원본 제안서나 버그 보고서에 명시적으로 포함되지 않은 내용을 기여물에 추가할 이유가 생길 때마다, 범위 확대(scope creep)로 이어질 수 있는지 고려해야 합니다. 두 가지 별개의 기능을 분리하여 구현할 수 있는가? 알려진 제한사항이나 버그를 감수하고 기능을 구현한 후, 후속 풀 리퀘스트에서 해당 버그를 수정할 수 있는가? 버그 수정 작업의 일부가 다른 부분과 독립적으로 수행될 수 있는가? 변경 사항의 일부를 제외해도 원래 기여물에 영향을 미치지 않는다면, 그 부분은 제외하는 것이 바람직하다.

소프트웨어 개발은 항상 점진적인 개선의 과정입니다. 각 개별 기여는 병합 결과 코드 베이스가 더 나은 상태가 되어야 하지만, 버그나 기능의 일부를 향후 개선을 위한 과제로 남겨두는 것은 완전히 허용됩니다. 이는 풀 리퀘스트를 독립적으로 검토할 수 있는 여러 부분으로 나누거나, 다른 사람이 문제를 조사하고 해결할 수 있도록 이슈를 등록하는 것을 의미할 수 있습니다.

각 기여의 범위를 제한하는 것은 여러분을 포함한 모든 관련자에게 도움이 됩니다. 검토자분들, 심지어 여러분 스스로도 이를 높이 평가할 것입니다.