긴급 상황

긴급한 상황일때는 CL을 더 신속하게 리뷰를 통과시켜야 한다.

긴급 상황이란?

긴급 리뷰가 허용되는 상황은 다음과 같다. 롤백을 하지 않고 중요한 출시 시점을 맞추려고 할 때, 실 사용자들에게 큰 영향이 있는 버그 수정이 필요할 때, 시급한 법적 이슈를 해결할 때, 중대한 보안 허점을 해결할 때 등이 있다.

긴급 상황에서는 리뷰어의 응답 속도보다는 실제 리뷰가 통과되는 시간을 빠르게 해야한다. CL이 정말 문제를 해결하는지, 그리고 리뷰가 얼마나 빨리 통과할 수 있는지를 중요하게 여긴다. 그리고 당연히 다른 리뷰보다 우선시 되어야 한다. 하지만 긴급 상황이 해소되고 나면 해당 CL은 다시 한번 엄격한 리뷰를 거친다.

긴급 상황이 아닌 때는?

다음의 경우는 긴급 상황이 아니다.

• 단순히 출시일을 일주일 앞당기고 싶을 때 (계약서 상으로 강제되는 것이 아닐 때)
• 오랫동안 작업했던 기능이라 이제는 리뷰 승인을 받고 싶을 때
• 다른 시간대에 있는 리뷰어가 근무 중이 아니거나 출장 중일 때
• 오늘이 금요일 저녁이라 주말 전에 머지시키면 좋겠다는 생각이 들 때
• 과거에 정한 마감 기한(soft deadline)을 지키기 위해 매니저가 강요할 때
• 테스트 실패나 빌드 실패를 유발하는 CL을 되돌릴 때

등등

엄격한 마감 기한(hard deadline)이란?

엄격한 마감 기한은 놓쳤을 때 절망적인 일이 일어나는 경우를 뜻한다. 예를 들어,

• 계약서상의 의무를 지켜야 할 때
• 특정 시점까지 시장에 출시하지 못하면 완전히 망할 때
• 어떤 하드웨어 제조사들은 제품 출시일이 일년에 한번이다. 만약 이때까지 코드를 보내지 못하면 재앙 같은 사태가 벌어질 때

출시를 일주일 미루거나 중요한 컨퍼런스를 놓치는 일은 그렇게 심각한 사건이 아니다. 대부분의 마감 기한은 soft deadline이다. 중요하긴 하지만 코드 품질을 포기해야 할 정도는 아니다. 또한 제품의 출시 간격이 길면 개발자가 몇 주를 더 기다리기 싫어 리뷰를 빨리 끝내고 싶겠지만 이런 일이 반복되면 기술 부채가 감당할 수 없을 만큼 커진다. 또한 마감 기한에 가까워져서야 개발자들이 CL이 제출하여 충분히 리뷰를 할 시간이 매번 부족하다면 개발 프로세스를 재정비하도록 한다.