리뷰를 하면 다른 사람의 코드를 분석하면서 여러 코딩 방식을 배울 수 있다. “오 이렇게 짤 수도 있구나” 싶은 게 많다.
그런데 리뷰를 하다 보면 “이 부분은 에러 날 수 있겠는데…” 싶은 것도 있다. 여기서 잠깐! 무턱대고 “여기 에러 날 듯.” 코멘트 하지 말자.
나 같은 소심이는 리뷰받는 사람의 기분을 고려한다. (잠들기 전에 내가 말실수한 건 없나 이불 킥하는 스타일.)
리뷰는 아무래도 개선 사항 관련된 게 많아서 리뷰받는 사람 입장에서는 지적으로 느낄 수 있다. 그래서 조심스럽다.
한국은 동방예의지국. 예의 바른 리뷰를 해보자.
1. 에러 관련 사항은 어떤 case에 발생할 수 있을지도 쓰자. 디버깅은 역시 재현 방법이 있는 것이 편하기 때문이다.
2. 개선할 부분만 쓰지 말고 대안도 같이 제시하자. 대안도 제시해주면 그 사람의 시간을 절약해주는 효과가 있다.
3. 이건 나만의 꿀팁인데.. 이모지를 붙여주면 딱딱한 리뷰 분위기를 좀 더 부드럽게 만들 수 있다. :-)
예의를 그림으로 표현하기 어려워 글자로 “예의”를 써버렸다.
리뷰받고 경험치 얻기
리뷰는 하는 것도 중요하고 받는 것도 중요하다. 특히 리뷰받는 자세에 따라 리뷰로 좋은 경험치를 얻을 수 있게 된다.
1. 코드에 자아를 부여하지 말기.
자아를 부여하는 순간, 방어적으로 바뀐다. 나도 옛날엔 누군가 내 코드에 대해 조언을 해주면 얼굴이 빨개졌다. 내가 혼난 것 마냥 낯 뜨거워진 것이다. 그리고 왜 그렇게 짰었는 지 변명을 늘어놓았다. (안돼~~) 이렇게 방어적으로 받은 리뷰는 변명하기 급급해서 경험치를 흘려보내기 마련이다. 왜 그렇게 짰는지 보다 어떻게 개선할지 생각하고 경험치를 얻도록 하자.
2. 리뷰를 또 리뷰하자.
더 나은 해결책을 제시해준 리뷰에 문제가 없는지 생각해봐야 한다. 숟가락으로 떠먹여 준 건 기억에 잘 안 남는다. 이 음식은 무엇이고 어디서 왔는지 판단 후 스스로 먹도록 하자. 그리고 가끔은 그것보다 더 좋은 해결책이 있기도 하다. 정답은 없으니까영혼 없이 반영하지 말고 더 나은 건 없을까 충분히 조사해보고 반영하자.
이렇게 썼지만 코드와 자아를 분리하는 일은 하루아침에 되지 않는다. 애정이 가는 만큼 내 자아가 반영되기 마련이다. 하지만 리뷰받는 순간만큼은 “이 코드는 남의 코드다”라고 암시해보자.