효율적 코드 리뷰

개발 프로세스가 어느 정도 잘 잡혀있는 곳은 코드 리뷰하는 문화가 자리 잡혀있는 곳이 많다.

그런데 그 방식이나 정도는 회사, 조직마다 조금씩은 다르기 마련이다.

 

코드 리뷰를 이래 저래 몇 년째 해오고 있는데 이에 대한 생각을 좀 정리해보았다.

 

일단 내가 생각하기에 코드 리뷰의 목적은 다음 정도인 것 같다.

1. 이 변경 사항이 코드 베이스에 반영되어도 되는지, 목적에 대한 타당성 확인
2. 요구하는 기능을 수행하는 것이 맞는지, 로직의 오류를 사전에 찾아내기
3. 코드의 가독성, 컨벤션 등 유지보수하기 어렵게 작성되어 있지는 않은지
4. 코드 변경 사항 조직 내 공유되도록 하기

 

첫 번째 목적의 경우에는 코드 작성 이전에도 가능한 부분인데,

크지 않은 변경인 경우 코드 변경과 함께 동의를 얻어내는 것도 괜찮다고 생각한다.

(코드를 보면 이해가 더 쉬워진다.)

 

2, 3번의 경우 적정 수준에 맞게 진행하는게 효율적이라고 생각한다.

적정 수준이라는 것이 애매한데,

이것은 조직의 상황, 변경 사항의 영향도 등에 따라 유동적으로 정하면 된다고 생각한다.

 

조직의 목표가 일단 빠르게 동작하는 제품을 만들어 내는 것이냐 아니면,

견고하고 유지보수성이 높은 코드를 유지하는 것이냐 등으로 다를 것이기 때문이다.

 

그런데 효율성을 우선 시 한다면 (지속 가능한 일정 퀄리티 이상의 코드 리뷰를 유지하려면)

의심보다는 신뢰를 바탕으로 시작하는 것이 좋다고 생각한다.

 

의심을 기반으로 모든 라인에 대한 오류 가능성을 체크하고 테스트까지 해본다면

오류는 발생 안할지 모르지만 그렇게 계속 지속하기는 어렵다.

 

그런데 만약 그렇게 하기에는 문제가 너무 많이 발생한다면..??

조직의 역량을 저 수준까지 끌어올려야 하고 그 전까지는 속도와 견고함 중 하나를 포기해야하지 않을까 싶다.

 

나도 이 중에서 경력 중반까지는 2번 또는 3번에 집중을 많이했던 것 같고

무언가 문제를 찾아내지 못하고 Approve를 하는 것이 내 할 일을 다하지 못한 그런 느낌도 들었다.

그리고 3번 관련해서 그렇게 영양가 있지 않은 의견을 남기는 경우도 많았다.

 

그래서 요즘에는 1, 4번에 조금 더 비중을 두고 더 많은 리뷰를 하는 쪽으로 하려고 한다.

100% 코드에 대한 이해를 하지 못했더라도 큰 틀에서 문제가 없어보인다면 Approve를 한다. (동료에 대한 믿음 방관)

물론 꼼꼼히 볼 필요가 있는 상황에서는 꼼꼼히 본다.

 

끝.