코드 리뷰

풀 리퀘스트를 검토하는 것은 일반적인 기여 유형입니다. 지속적인 통합(CI)을 통해 코드가 제대로 작동하도록 보장하지만 그것만으로는 충분하지 않습니다. 디자인, 코드 구조 및 아키텍처, 테스트 품질, 오타 등 자동화할 수 없는 기여 특성이 있습니다. 다음 섹션은 코드 검토 프로세스의 다양한 측면을 나타냅니다.

가독성

코드가 의도를 명확하게 표현하고 있나요? 코드가 무엇을 하는지 파악하는 데 많은 시간을 소비해야 한다면 코드 구현을 개선해야 합니다. 코드를 이해하기 쉬운 작은 추상화 단위로 분할하는 것이 좋습니다. 또는 마지막 리소스로서 그 이유를 설명하는 댓글을 추가할 수도 있습니다. 풀 리퀘스트 설명과 같은 주변 맥락 없이도 가까운 시일 내에 코드를 이해할 수 있는지 스스로에게 물어보세요.

소규모 풀 리퀘스트

큰 풀 리퀘스트는 검토하기 어렵고 세부 사항을 놓치기 쉽습니다. 풀 리퀘스트가 너무 커서 관리하기 힘들어지면 작성자에게 세분화할 것을 제안하세요.

EXCEPTIONS

변경 사항이 긴밀하게 연결되어 있어 분할할 수 없는 경우와 같이 풀 리퀘스트를 분할할 수 없는 시나리오는 거의 없습니다. 이러한 경우 작성자는 변경 사항과 그 이유에 대한 명확한 설명을 제공해야 합니다.

일관성

변경 사항이 프로젝트의 나머지 부분과 일관성을 유지하는 것이 중요합니다. 일관성이 없으면 유지 관리가 복잡해지므로 이를 피해야 합니다. 사용자에게 메시지를 출력하거나 오류를 보고하는 접근 방식이 있다면 그 방식을 고수해야 합니다. 작성자가 프로젝트의 표준에 동의하지 않는다면 이슈를 열어 더 논의할 수 있도록 제안하세요.

테스트

테스트를 통해 자신 있게 코드를 변경할 수 있습니다. 풀 리퀘스트의 코드는 테스트를 거쳐야 하며 모든 테스트가 통과되어야 합니다. 좋은 테스트는 일관되게 동일한 결과를 생성하고 이해하고 유지 관리하기 쉬운 테스트입니다. 검토자는 대부분의 검토 시간을 구현 코드에서 보내지만 테스트도 코드이기 때문에 똑같이 중요합니다.

속보 변경 사항

갑작스러운 변경은 Tuist 사용자에게 좋지 않은 사용자 경험을 제공합니다. 기여자는 꼭 필요한 경우가 아니라면 획기적인 변경을 도입하지 않아야 합니다. 획기적인 변경 없이도 Tuist의 인터페이스를 발전시키기 위해 활용할 수 있는 언어 기능이 많이 있습니다. 변경이 획기적인지 여부는 명확하지 않을 수 있습니다. 변경 사항이 깨지는지 확인하는 방법은 수정 디렉토리의 수정 프로젝트에 대해 Tuist를 실행하는 것입니다. 이를 위해서는 사용자의 입장이 되어 변경 사항이 사용자에게 어떤 영향을 미칠지 상상해 보아야 합니다.