코드 리뷰어를 하며 저지른 실수 7가지

Article Date	2023.06.29
URL	https://yozm.wishket.com/magazine/detail/2095/

코드리뷰어의 실수

• 선호 방식 강요
  • 강요는 당장의 효과, 장기적으로 강한 반작용
  • 대화하여 거부감이 발생하지 않도록 주의
    • 강한 요구가 아닌 제안
• 맥락에 상관 없는 코드 보기
  • 텍스트(Text)에 깔린 서브텍스트(Subtext), 이것들을 감싸는 컨텍스트(Context)를 보는 안목이 필요
  • 코드가 짜여진 상태의 비판보다는 그렇게 짜여진 이유와 그 맥락을 두루 살펴봐야

💡
아직은 내가 짠 코드, 다른 사람이 짠 코드를 보면서 피드백을 주고 받거나 리뷰를 하는 일이 없지만, 코드에서도 기획과 같이 그렇게 도출된 결과에 대한 맥락과 이유가 충분히 있을 수 있다곤 생각했다. 아티클에서도 역시, 그 맥락이 개발자의 코딩역량 부족이 될 수도 있겠지만 그렇게 비효율적으론 코드가 짜여질 작동 환경이었을 수도 있다는 것을 강조하면서 무조건적으로 코드가 좋다 나쁘다를 평가해서는 안된다는 것이다.
이는 캠프 프로젝트의 협업과정에선 소통부분에서도 많은 도움이 될 만한 정보일 것이다.

 

• 내 말만 말하기
  • 지시가 아니라 의견을 제시하고 대화로 이어지게해야
    • 원하는 답/단답형 대답을 들으려고 하지 말아야
  • 상대를 배려하지 않은채 너무 많은 의견을 하지 않도록
• 원격 , 비동기 소통만을 고집
  • 글로만 소통한다면 의도를전달하기가 쉽지 않음
    • 오해와 상처를 줄 수도
  • 오프라인 소통도 중요한 요소

💡

기획자 PM 이라면 무조건 개발자와 디자이너를 만나서 커피챗을 기본 소통으로 하면서 프로젝트를 진행하게 된다.
비단 리뷰 뿐만이 아니라 프로젝트에 있어선 소통의 오류와 또 교류를 위해서 오프라인 소통은 개발자에게도 가장 중요한 한 요소라는 점을 간과해서는 안될 것이라 생각한다. 특히 서로 말하다가 새로운 아이디어가 제시될 수도 있는 긍정적인 효과도 기대할 수 있을 것이다.

• 비공유
  • 의견을 나눈 내용을 공유해야
    • 기억의 왜곡과 잊혀짐이 있기 때문에
  • 자연스러운 공유가 되기 위해 분위기 조성도 필요
• 합의하지 않은 리뷰 규칙
  • 리뷰 시기, 리뷰할 코드량(리뷰양), PR 크기를 조절
    • 전체 작업 속도를 낮추기 때문
• 따뜻함의 부족
  • 비판만이 아닌 따뜻한 말 한마디가 큰힘이 될 수 있다는 것

 

→ 소프트웨어는 사람이 함께 만든다는 사실을 망각하지 않도록