긴급상황

때로는 전체 코드 리뷰 프로세스를 가능한 한 빨리 통과해야 하는 긴급한 코드 변경사항이 있습니다.

긴급상황은 무엇일까?

긴급한 코드 변경사항(CL)은 작은 변경사항일 수 있습니다. 예를 들면, 롤백 대신 주요 출시 시점을 맞출 때, 사용자에게 큰 영향을 미치는 버그를 수정할 때, 긴급한 법적 문제를 처리할 때, 중대한 보안 이슈를 해결할 때 등입니다.

긴급상황에서는 리뷰어의 응답 속도뿐만 아니라 전체 코드 리뷰 프로세스의 속도를 중요하게 생각합니다. 이 경우에만 리뷰어는 리뷰 속도와 코드의 정확성(실제로 긴급상황을 해결하는지?)에 대해 무엇보다 더 신경써야 합니다. 또한 다른 모든 리뷰보다 더 우선적으로 리뷰되어야 합니다.

하지만 긴급상황이 해결된 후에는 다시 살펴보고 더 철저한 리뷰 를 해야 합니다.

긴급상황이 아닌 때는?

분명하게, 다음과 같은 경우는 긴급상황이 아닙니다.

• 다음 주가 아닌 이번 주에 출시하기를 원한다.(파트너 계약과 같은 실제 출시 기한이 없는 한)
• 개발자가 오랫동안 작업한 기능이며 실제로 서비스에 반영하고 싶을 때
• 다른 시간대에 있는 리뷰어가 외부에 있거나 야간일 때
• 금요일이라서 주말 전에 반영하고 싶을 때
• 매니저가 변경할 수 있는 마감기한 때문에 오늘 리뷰를 완료시킬 때
• 테스트가 실패하거나 빌드 실패를 유발하는 코드 변경사항을 롤백할 때

기타 등등

엄격한 마감기한은 무엇일까?

엄격한 마감기한은 그것을 놓쳤을 때 참사가 일어날 수 있다. 예를 들면,

• 계약상 의무사항을 위해서는 특정일까지 코드 변경사항을 반영해야 한다.
• 특정 날짜까지 출시되지 않으면 시장에서 완전히 실패할 수 있다.
• 일부 하드웨어 제조업체는 1년에 한 번만 새로운 하드웨어를 출시한다. 만약 코드 제출 마감을 놓치면, 코드 유형에 따라 참사가 발생할 수 있습니다.

출시를 1주 미루는 것은 큰 문제가 아닐 수 있습니다. 중요한 컨퍼런스를 놓치는 것도 종종 그렇다. 대부분의 마감기한은 유연하게 변경 가능하다. 중요하지만 마감기한을 지키기 위해서 코드 품질을 포기해서는 안됩니다.

제품의 출시 주기가 긴(몇 주) 경우 다음 주기 전에 반영시키고자 코드 품질을 뒤로 미루고 싶은 유혹을 받을 수 있습니다. 그러나 이러한 경우가 반복되면, 감당할 수 없는 기술부채를 만들게 됩니다. 개발자의 코드 변경사항이 매번 출시 주기가 끝날 때쯤 제출되는 경우, 프로세스 초기에 변경 사항이 발생하고, 충분한 리뷰 시간을 가질 수 있도록 프로세스를 수정해야 합니다.