[week05] 코드리뷰 - 류석영 교수님

가독성 더 좋은 버전 ⬇

https://selective-aphid-cd5.notion.site/a4c0b6b92cec4812bf2601988ac16702

코드리뷰 강의 정리

✅ 결론

코드리뷰에서 가장 중요한 2가지는

• 이해하기 쉬운 코드
• 유지보수 하기 쉬운 코드

이해하기 쉬워야 유지보수가 편하다. 

유지보수가 편해야 디버깅할 일이 없다.

💻 코드리뷰

구글 코드리뷰에서 제일 중요한 것

• Test-Driven Development(TDD)
  • 구현해야 할 요구사항(requirements)과 구현(implementation)를 분리하는 것.
    • 구현하기 전에 test부터 짠다.
      • 제대로 동작하려면 이런 input일 때 output이 이렇게 나오겠지
      • edge case도 생각한다. (코드부터 짜면 이걸 잘 못잡음)
    • test는 실행 가능한 문서다.
      • 주석은 글이라서 실행할 수 없고, 계속 버그를 고치다 보면 주석과 코드의 실제 실행이 멀어지게 되는데, test는 그럴일 없다(돌다 죽으니까).
    • No source code without tests
      • code commit 전에 항상 test를 돌려야 한다.
      • 조금조금씩 commit을 해 놓아야 문제가 발생했을 때 범인을 찾기 쉽다.
• Pair-programming
  • 제일 빨리 배우는 방법은 선배 어깨너머로 배우는 것이다.
  • 둘이 나란히 앉아서(컴퓨터는 하나) 한다.
    • 지식의 전파 속도가 매우 빠르다.
    • ex) 오전에는 사수가 코딩을 하고 오후는 부사수가 코딩을 한다.
    • 오후에
      • Q. 사수가 뭐가 필요할까?
      • A. 이런 일을 해야 하니까 모듈이 필요할 것 같아요
      • Q. 구글링 해 볼까? 구글링은 어떻게 해야할까?
      • 이런식으로 페어 프로그래밍을 하면 정말 빨리 배운다.

코드리뷰란 무엇인가?

• 소프트웨어 개발에서 꼭 필요한 단계(workflow) - 필수!
• 동료로부터 commit 하기 전에 feedback을 받는 것.
• 코드리뷰가 아닌 것
  • 소프트웨어 설계를 어떻게 할 것인지 이야기하는 것
  • 우리 상품에 어떤 기능을 넣을까 상의하는 것
• 즉, 코드리뷰는 완전히 코드 변화에 관한 것이다.

코드리뷰 Workflow

1. SoftWare Engineer(SWE)가 변화시키려는 코드를 CL(change list)이라고 부른다.
2. CL 가진 사람이 동료들에게 코드리뷰 해달라고 보낸다.
3. 지목받은 동료가 comments을 남긴다.
   • 최근 구글에서는 bot이 있어서 가장 적합할 것 같은 리뷰어를 추천해주기도 한다.
4. comments를 바탕으로 코드를 수정한다. 리뷰어는 2~3명인데 다 같이 좋다고 해야 넘어간다. 그 전까지 2~3을 계속 수행한다.
5. 모든 reviewer들이 괜찮다고 하면 CL을 repository에 넣는다.

왜 코드리뷰가 필요한가?

• 당신의 CL을 이해하기 쉽게 만듬
  • 동료들이 내 코드를 이해할 수 있어야 한다.
• 당신의 CL에 동료가 남긴 의견으로부터 tips & lessons들을 배움
  • 숙련된 개발자로부터 코딩 스타일과 팁을 배움
  • 당신의 팀이 공통된 코딩 스타일을 공유할 수 있음
• 결함을 줄일 수 있음
• 당신의 coding decision에 대한 개발 역사를 보관함
  • 좋은 개발자들은 코드를 바꿀 때 이유를 같이 써 놓는다. 그걸 보고 어떤 생각을 가지고 코드를 짜고 있는지 알 수 있음
  • 팀원 중 한 명이 팀을 나가더라도 그 사람이 개발하던 기능에 대해 아는 사람이 1~2명 더 생김
  • 동료의 의견은 코드 설계와 결정 사항에 대해 이해하는 데 매우 큰 도움이 됨
  • 새로 온 개발자는 committed logs와 의견으로부터 코드의 구조와 결정사항을 이해할 수 있음
• 당신의 코드에 일관적인 코딩 스타일을 유지할 수 있음
  • 새로 온 개발자가 기존의 코딩 스타일을 따를 수 있도록 도와줌
  • 일관적인 코딩 스타일은 이후에 코드를 refactoring하거나 디버깅할 때 큰 도움이 됨

좋은 코드리뷰 예시

a라는 list가 비었는지 안비었는지 확인할 때 len(a) > 0 보다는 isEmpty() 함수를 사용하는 것이 좋습니다.
a의 길이가 100만일 경우 컴퓨터의 쓸모없는 비용을 소모하게 됩니다.
더 알아보고 싶으시다면 ~ reference 제공

코드리뷰의 단점

• 잘 하는 사람이 코드를 봤을 때 화가 날 수 있고, 이것이 거칠고 무례한 형태로 코드리뷰를 신청한 사람에게 갈 수 있다.
  • 코드리뷰 받는 사람이 위축될 수 있음 → 긍정적인 feedback을 주는 것이 필요.
• 리뷰가 늦어지면 개발 기간이 늦어짐
• 코드리뷰를 제대로 하려면 시간이 걸림
• 경험이 부족한 개발자의 잘못된 CL을 리뷰하느라 숙련된 개발자의 시간이 허비될 수 있음
  • 그러나 생각보다 남의 코드 보면서 자신이 생각하는 것을 말로 바꾸면서 많이 배운다.
  • 대화하다보면 내가 미처 생각하지 못한 것을 알 수 있음
• 코드리뷰를 위해서는 어느 정도 숙련된 개발자가 필요함

코드리뷰는 문화가 필요하다

• 동료를 respect 해야함
• 건설적인 피드백을 남겨야함(마상 방지)
• 문화가 되기까지 시간이 필요하다

코드리뷰는 회사에게 좋다.

• 코드리뷰는 투명성을 늘려준다
• 코드리뷰를 하면 협력이 늘어난다
• 코드의 표준이 올라간다

구글 코딩 가이드

https://google.github.io/styleguide/cppguide.html

Google C++ Style Guide

• 어떤 언어로 코드를 짰다면 반드시 2명이 코드리뷰를 해야 한다.
  • C언어로 짰다면 C전문가
  • 프로젝트 오너(프로젝트가 하는 일이 무엇인지 아는 사람)
• 코드리뷰는 코드를 작성하는 사람을 위한 것이 아니라 코드를 읽는사람을 위한 것이다.
  • 클린코드에 보면 문학적인 표현이 많은데 이런 식이다.
    • 여러분은 작가이다. 작가는 글을 쓰고, 한 번 글을 쓰게 되면 여러번 읽히게 된다. 그리고 심지어 그 글을 읽는 사람에 여러분도 포함된다. 그러니까 Reader를 위해 써야 한다.
  • 암묵적으로 타입을 변환시키는 경우(특히 자바스크립트가 가장 심한데) 개발자들은 그것이 편하니까 좋다고 생각하지만 나중에는 발목을 잡을 것이다.
    • 디버깅하기 정말 힘들다.
    • 그러니까 미래를 생각해서 현재의 귀찮은 것을 조금 참고 타입등을 다 적어주자. 이름도 길게, 읽으면 무슨 뜻인지 알게 작성하자.
• 새로운 기능은 잘못되었을 가능성도 많고 그 기능을 모르는 사람도 많기 때문에 욕심을 버리고 아는대로 해라.
• 코드리뷰를 하다보면 최적화가 안돼서 코드가 느려질 수 있는데, 그럴때는 속도에 양보해라.

일반적인 작명 Rules

함수(제일 중요⭐)

• 함수를 만들 때 중요한 점
  • 함수는 한번에 한 가지 일만 하게 해라(작게 짜라).
  • 함수는 하는 일이 뭔지 명확하게 알아야 한다.
  • 이름에서 무슨일을 하는지 드러나야 한다.
• 함수가 하는 일이 여러개면,
  • 무엇을 위한 함수인지 이해하기 어렵다.
  • 문제가 있을 때 디버깅하기 어렵다.
  • 함수에 대한 테스트코드 만들기 어렵다.

📍 Testing

왜 Testing이 중요한가?

• Testing Rocks! Debug Sucks!(테스팅이 최고야! 디버깅은 최악이야!)
  • 디버깅은 보통 문제를 찾는데 엄청 시간이 오래 걸림
  • 테스팅은 새로 작성한 코드에서도 결함을 검출할 수 있음
  • 테스팅은 테스트 코드를 필요로 하기 때문에, 유지보수 부담을 줄임
    • 새로 코드를 추가하다가 기존 코드를 건드렸는지 기존 테스트코드 돌려보면 알 수 있음(테스트가 당신을 보호할 것입니다...)
• Project Scalability
  • 새로온 개발자도 테스트 코드를 잘 작성해서 프로젝트에 기여할 수 있음
  • 동료나 외부 기여자에게 도움을 받기에 가장 적합함

Testing types

• Unit Testing (젤 많이 씀)
  • 단위 하나, 즉 함수 하나씩 테스팅한다.
  • 그러나 충분하지 않음
• Integration Testing
  • 하나의 상황에서만 사용되지 않기 때문에 여러개의 상황에서도 테스트해봄
• Regression Testing (밤에돌림)
  • 과거의 동작은 새 코드에서도 유지함을 보장하기 위한 test
• End-to-End(E2E) Testing
• 테스트계의 교과서
•  

  

🔨 Code Refactoring

Refactoring 교과서

Refactoring의 정의

• Refactoring은 SW의 동작을 바꾸지 않으면서 내부 구조를 개선하는 것.
  • 즉, 코드의 구조를 잘 정해진 규정대로 수정하는 기술
• sw를 더 이해하기 쉽게 만들고, 수정하는 비용을 줄임
• Refactoring is an overhead activity

왜 Refactoring을 하는가?

• sw 설계 개선
  • refactoring이 없으면 프로그램의 설계는 낡아짐
    • 항상 새로운게 나오기 때문에 그걸 배워서 적용해야 함
  • 설계가 좋지 않은 코드는 보통 같은 일을 하는데 코드가 길고, 같은 일을 여러 곳에서 함.
• 이해하기 쉬움
  • 대부분의 SW개발 환경에서, 누군가 언젠가는 당신의 코드를 읽어야 할 때가 오기 때문에, 그들을 위해 이해하기 쉬운 코드를 작성해야 함
• 프로그램 속도 향상
  • 프로그램에 대해 더 잘 이해하게 됨

좋은 코드와 나쁜 코드의 키워드