좋은 리뷰란?

오래전에 올린 영상이지만 지금 또 한번 공유하면

좋은 아이디어가 나올 가능성도 있을 것 같고.. ㅎ

당시에 코드리뷰에 대한 논쟁이 많았습니다.

제가 평소 생각하는 가장 적절한 코드리뷰 방법이 있었는데요.

5명의 팀원이 있을 때였는데 한번 실험해보고 싶었습니다.

딱 5일동안 만든 SW입니다.

데이터는 간단합니다. 프로젝트별로 *.his라는 파일이 있습니다.

txt파일입니다. 하루에 한줄 기입합니다.

내가 A프로젝트에 오늘 일을 했다면 A/A.his를 열어서

[2024-06-25-gbh] xml리소스의 바이너리화 1/3

이렇게 기입합니다. (1/3은 33%정도란 예상으로 일이 커지면 내일은 2/5가 될 수도..)

그리고 소스코드의 중요위치에 주석을 답니다.

// 2024-06-25-gbh : 아래 순서에 따라 수정

모두가 그렇게 his와 주석을 점점 추가하면

위 동영상과 같은 분석이 언제든지 도출되어 나옵니다.

저 SW는 코드리뷰툴로써 서로 상대방의 코드에 별점을 추가할 수 있는 시스템입니다.

내가 일을 하며 주석을 추가해 놓으면 상대방이 주기적으로 코드리뷰를 할 때

별점을 줄 수 있는 새로운 주석이 등장합니다. 주석 하나당 별점은 2개까지만 가능.

별을 많이 받으면 이번달 별점왕이 됩니다. 돈이나 문화상품권을 받습니다.

동기는 이렇습니다. 별점을 더 받기 위하여 자랑이 될만한 코드를

나 스스로 주석을 많이 달고 싶게 됩니다.

자기 입장에서는 다른 팀원을 주석을 확인조차 하지 않았다는 것은 기록됩니다.

즉, 모두 봐야 한다. 처음에는 별점을 많이 받으려고 자랑하는 코드에

주석을 달겠지만 나중에는 무조건 회람되는 주석을 통해 내 코드의 책임을

나누기 위하여 주석을 달기도 할 것입니다.

즉, 주석화의 동기도 획득했고 모두가 회람함으로써

잠정적인 오류코드의 책임 분산효과가 생겼습니다.

오류가 난 코드에 주석조차 달지 않았다면? 작업자의 책임이죠.

주석을 달았는데 모두가 회람했음에도 오류가 고쳐지지 않았다면

모두의 책임입니다.

소스코드만 다함께 보면 실력자는 모든 것을 알 수가 있다?

그렇지가 않습니다. 장기간의 점진적 리팩토링을 위한 리소스포맷변경등

하나만 봐서는 알 수 없는 것들도 많습니다.

또한 코드만 보고 이해하기 위한 가독성을 위해서

A) int count = value + 10; // 리스트에는 기본적으로 10개가 탑재

B) int BaseItemCount = 10;

int MergedListCount = UserSelectedValue + BaseItemCount;

A가 좋습니까? B가 좋습니까?

저는 A가 좋습니다. 변수나 함수명에 이해를 돕고자 아무리 길게 쓴 B도

결국 오해를 불러일으키는 약어에 불과합니다.

그냥 설명이 필요한 부분에 확실하게 구체적으로 주석을 다는 것이 좋습니다.

그리고 별점을 받는 과정에서 팀원들과 주석의 표현력에 대하여 맞추는 거죠.

저건 12년전 프로젝트입니다.

지금은 훨씬 더 좋은 도구도 만들어서 쓰고 있습니다. (영상은 없네요.)

주석을 달면 API도큐먼트처럼 좌측에 나열되고 상대방이 좌측을 눌러서

해당 코드로 이동하여 체크표시를 코드에 붙이는 방식의.

주석만 규칙에 맞춰서 계속 추가하면 Doxigen같은 기능이 되는 셈..