코드 리뷰

CodeReview 에 대해서

아키텍처의 중요성

• 시장과 비즈니스는 요구사항은 휘발성이며 모호하고 혼란스럽다.
• 비즈니스 혁신은 더더욱 가속화되고 있으므로 그에 맞는 속도가 필요함.

결국, 소프트웨어 개발은 더 빠르고 더 자주 더 안정적으로 개발되어야 함.

• 릴리즈 수가 증가함에 따라 개발자의 수는 기하급수적으로 늘어나게 된다.
• 계속되는 릴리즈마다 코드의 생산량(LOC)은 점점 떨어지게 된다.
• 릴리즈 수가 증가함에 따라 개발비용 또한 기하급수적으로 늘어나게 된다.

---

클린 코드, 좋은 설계, 아키텍처의 주의를 기울여야 함.

• 기능이 동작만 하면 개선없이 다음 기능 구현으로 넘어감.
• 기능 변경은 복붙 및 일부 수정 ... 향후 수정 시 문제
• 공유 부족으로 인한 소수 개발인력 의존도가 높아짐

Big Ball of Mud

• 뚜렷한 아키텍처가 없는 시스템
• 돌려봐야 알 수 있는 시스템
• 이번에만 급하니까 더럽게 짤게요!! 다음 번엔 더 잘할게요 (X)
• 소프트웨어가 변화하는 요구사항을 수용할 수 있는지 없는지?
  • 극단적 가정
    • 동작은 하지만 고칠 수 없는 소프트웨어 (오늘은 쓸 수 있지만 내일은 쓸 수 없음.)
    • 고칠 수 있지만 동작하지 않는 소프트웨어 (오늘은 쓸 수 없지만 내일은 쑬 수 있음.)

---

아키텍처란?

• 요구되는 시스템을 구축하고 유지보수하는데 요구되는 인적 리소스를 최소화하는 것이지 해고는 아니다.

Agile 은 개발역량과 개발절차가 모두 수렴이 되어야 한다.

• 온라인 코드리뷰를 통해 지식과 경험을 공유할 수 있게 한다. (코드리뷰를 통해 손이 올라가는 행동은 금물)

코드리뷰는 왜 어려운가?

• 저자 : 본인이 생각하는 PR은 엄청 멋지다고 생각함.
• 리뷰어 : 왜 멋지지 않은지에 대해 장황한 이유를 설명함.
  • 심지어 코드에 대한 리뷰를 자신에 대한 비판 및 공격으로 생각함.
    • 상급자면 더더욱..
• 실패, 성공 여부에 상관없이 공유가 중요함.
• 원칙에 기반한 피드백과 요청으로 표현, 예제 코드를 제공하라
• '~하는게 좋습니다.' 보단 '~하는건 어떨까요?'

리뷰

• PR의 크기와 복잡도를 고려하여 선정함.
• D등급의 PR을 받으면 B, C 등급을 받을 수 있게 도와라.
• 완전하진 않아도 충분히 좋은 코드가 될 수 있도록 하라.
• 수 차례의 리뷰 라운드에도 F 상태인 코드는 승인을 보류하라.
• 반복적인 패턴에 대해서 피드백을 제한하라.
• PR 범위가 아닌 코드는 리뷰 범위가 아니니라.
• 큰 리뷰를 잘게 나눌 기회를 찾아라.

최악의 코드리뷰 사례

S가 보낸 첫 PR이 너무 대충.. 파이썬은 처음이니? 의무감을 가지고 코드 리뷰 60군데를 기록한 나는 훌륭한 리뷰어? S가 나에게 업데이트 PR을 보냄. 변수명 변경, 오타 수정 등 간단한 수정만 하고 indentation 6단계가 들어간 복잡한 제어문은 고치지 않음. 화가나서 새로운 코멘트를 보냈으나 동일 코드 리뷰에서 멈춘 상태 3주 동안 개선 사항이 없음.