코드 리뷰

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

가독성#

코드가 의도를 명확하게 표현하고 있나요? 코드가 무엇을 하는지 이해하는 데 많은 시간을 써야 한다면, 코드 구현을 개선해야 합니다. 코드를 더 쉽게 이해할 수 있는 작은 추상화로 분리할 것을 제안하세요. 대안으로, 최후의 수단으로 그 배경에 대한 이유를 설명하는 주석을 추가할 수 있습니다. 풀 리퀘스트 설명과 같은 주변 맥락 없이도 가까운 미래에 코드를 이해할 수 있을지 자문해 보세요.

작은 풀 리퀘스트#

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

일관성#

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

테스트#

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

호환성 중단 변경#

호환성 중단 변경은 Tuist 사용자에게 나쁜 사용자 경험을 제공합니다. 엄격히 필요한 경우가 아니면 호환성 중단 변경을 도입하지 않도록 해야 합니다. Tuist의 인터페이스를 진화시키면서 호환성 중단 변경에 의존하지 않고 활용할 수 있는 많은 언어 기능이 있습니다. 변경이 호환성을 중단하는지 여부는 명확하지 않을 수 있습니다. 변경이 호환성을 중단하는지 확인하는 방법 중 하나는 fixtures 디렉터리의 픽스처 프로젝트에서 Tuist를 실행하는 것입니다. 이는 사용자의 입장이 되어 변경 사항이 사용자에게 어떤 영향을 미칠지 상상해야 합니다.