2022-06-14-지속가능한-SW개발을-위한-코드리뷰

01.내용정리

• 4차산업 VUCA
  • 계획대로하기 어렵다
  • 변동성이 가장 큰 포인트 알고 있는것으로 해결할 수 없는 시대가 왔음
    • 서로 협력을 통해 이런 문제를 해결해야함
    • 그렇기 때문에 코드 리뷰가 필요하다.
• 개발 DRFR
  • Deliver SW Rapidly, Frequently and more Reliably
  • SW를 더 빠르고 더 자주 안정적으로 출시
• 주로, SW와 건축을 자주 비교함
  • 건축은 90%빌드
  • 유지보수 비용이 적음
    • 완성이 되면 불편하더라도 왠만하면 그대로 살아야함
  • SW공학은 다르다 목적이 재생산 가능한 문서
    • 좋은 설계 = 클린 코드 = 코드 잘 작성하는 사람
• 우리는 처음부터 설계를 하기 보다는 남의 코드를 80%이상 보고 수정하고 사용함
  • 그렇기 때문에 작성보다 이해하는데 시간도 오래걸림
    • 실제로도 작성하는것이 더 빠르고 이해하는것이 10배의 노력이 들어감
• SW개발이나 설계할때
  • 빨리가는 방법은 잘가는 방법이다.
    • 이번만 빨리하는것 좋지 않음
  • 대개 이해못하는것은 사업에 도움이 안된다고 생각하는것이 많기 때문에 설득해야함
• 요즘 폰은 비싼것이 좋은데, SW는 그렇지 않음 비정상적, 비직관적임
• 재무적지표가 필요하고 높을때, 결합률등 어떤 이유로 비지니스적으로 더 빠른면을 어필해야함
• 에자일
  • 절자만 강조하는면이 있음
  • 개발역량에 대해서는 컨설트하지 않음, 그래서 서로간의 업무소통 필요
  • 에자일 + 장인정신(같이 무언가 하는 것)
    • 여기서 장인정신은 코드리뷰가 될 수 있음
    • Code SNS 리뷰
• 향후 변경 범용성 낮아야하고, 학습 및 지식 전달이 커야함
• 저자가 고생하면 리뷰에 걸리는 시간을 아낄 수 있음
• 코드를 비판을 했다고 나를 비판 한것이 아니다. 분리해서 생각해라
• 생각을 글로 표현하는 것 어렵다.
  • 항상 표현은 조심스럽게하자
• 커밋 분리가 필요하다.
• 지루한 작업은 컴퓨터로 해라
  • 수작업으로 할 필요 없는것은 컴퓨터로 쉽게 처리해야함
  • Formating Tool
    • 공백, 들여쓰기, 오류 등
    • 별도의 커밋/ PR로 분리 (필요 없는 것 제거)
  • unused import 를 Error로 선언해서 처리
    • 이런것들이 컴퓨터가 처리 할 수 있는것 하는것
• 스타일 가이드
  • 기존에 있는 스타일 가이드를 참고해라
  • 의견이 나올때 마다 쓰기
  • 하이브리드로 두개를 혼합해서 쓰기
• PR올릴 때 저자가 읽어보고 커멘트 남기기
• 많은 사람이 보게 해라
  • 많은 사람이 모면 버그를 많이 찾을 수 있고, 더 잘하게 노력하게 된다.
• 혼자하는 코드 리뷰
  • 커밋 잘 나누는 것이 중요하다.
• 리뷰는 즉시해라
  • 고수준에서 저수준으로 가라
    • 고수준
      • 버그, 장애, 성능, 보안
    • 저수준
      • 코드 오타나 띄어쓰기 등등 작은 부분
  • 너무 디테일하게 처음부터 가면 지치고 힘들다.
• 괴롭다고 생각이 들면 자주해서 익숙해져라
• 리뷰하는 사람의 노고를 인정해주는 것도 중요하다.
  • 리뷰를 할때 예제코드에 관대해라(선물을 줘야함)
  • 무작정 이렇게해 하면 사실 무책임한것
    • 모든 소스에 대해서 할 필요는 없다 2-3정도 적당선의 코드 선물로 예시를 제시
• [NIT] -> 하찮은 일로 트집 잡는다, 그냥 개선에 대해서는 의견을 내줄 알아야함
  • 자율성 필요함
• 한번에 완벽해지기 보다는 한단계 올리는것을 목표로해라
  • 완전하기 보다는 충분한 좋은 코드 만들기에 노력하기
• 피드백 할 때 중요한 말습관
  • 너, 왜, 맨날 이라는 말 하지 말기
  • 잘한 부분에 대해서 칭찬해라. 명령하지 말고 요청해야함
  • 무엇이 코드를 좋아지게 하는지 중요
• IMESSAGE로 말을 해야함
  • 행동 결과 감정
    • ~하면 어떨까요? 라는 언어로 유하게 말하기
• 건설적 피드백
  • 경쟁 유발하면 안됨
  • 생산성 높이는 것
  • 건설적 피드백 못하면 하지 않는것이 오히려 낫다.
• 리뷰어는 잘못에만 집중하지 말고, 칭찬도하는 것이 좋다.
  • 명령이 아니라 요청을 해야함
    • 명령: 자리가 비어있으니까 저기 걸어가서 앉을것이다.
    • 요청: 네명 앉을 자리를 부탁한다.
• 의견을 줄때
  • 제안하는 변경
  • 변경이유 설명을 해야한다.
• 너무 의견이 안맞는다고 계속 교착상태에 있으면 안됨
  • 어느정도는 승인해주고 SW품질이 낮더라도 타협해야함
  • 그렇게 의견 충돌로 퇴사를 하게 되면 오히려 더 손해의 경우가 생긴다.
    • 그렇다면 어떻게 해야하나?
      • 다른, 리더나 다른 리뷰어에게 할당하여 조치하거나 팀의 높은 사람과 같이 조율해보자 (Escalate)
  • 항상 말하지만 결정은 저자가 하는 것
    • 당신이 할 수 있는 최고의 설계
      • 완벽한 설계가 아님
    • 모든 설계 결함이 항상 실제 문제가 되지 않음
    • 코드리뷰는 비난이 아님 배움이다.
• 저자의 노력, 효과적인 리뷰가능, n명의 시간을 절약 할 수 있음
• 리더의 관심과 의지
  • 매일 관심갖고 참여해야함
• 코드비난에 두려움 없어야함
• 읽어보면 좋은책
  • 리팩토링
    • 위책을 읽어보지 않고 리팩토링해봤다고 하지 마라

  • 

  • legacy code
    • 의존성 관리
    • 테스트 추가
    • 새로운 코드 빠르게 추가
    • 레거시 분석

  • 

  • Clean Code & TDD
    • 코드리뷰자체가 중요한것은 아니다 이런 기술도 중요함
    • 공유와 코드에 대하여 논의 하는 문화가 중요
    • SW는 수학이 아님 과학임 그래서 예측 불가능하다.

  • 

02.생각정리

• 요즘 기술의 발달로 계획대로 하는것이 어려다고 하는데 이점에서는 이런 생각이 든다.
• 그렇기 때문에 집단 지성이 필요하다는 것
• 협력이라는 포인트를 잡고 있는데 협력이라는것이 모든 것을 같이 해야하고 알고 있는것
  • 그것이 협력일까?라는 생각이 든다.
  • 협력은 그렇게 같은것을 알고 공유하는것도 있지만 더 발전할 수 있는 협력의 경우는
    • 내가 다른 지식을 그사람으로 부터 알게 되었을때 이다.
    • 같은 장소에서 같은 교육을 받게되면 같은 생각에 주입이된다고 해야하나? 그래서 다른 생각을 하기가 어렵다 라고 생각이 든다.
    • 그렇기 때문에 같은 지식 또는 같은 기술을 가지고 있는 사람보다 여러 기술을 가지고 있는 팀이 오히려 어떤 면에서는 효율적이라고 생각한다.
• 여러 기술을 가지고 있는 팀 각각의 개인의 장점이 있는것
  • 예를 들면 개발자들만 모여있는 팀이 디자인이 이쁜 작품이 나올 수있을까?
    • 또는, 디자이너만 모여 있는 팀이 제대로 잘 동작하는 작품을 만들수 있을까? 라는 의문 또는 반문에서 부터 시작해보자.
      • 대답은 사실 작품이 나올 수 있지만 현실적으로 어렵다이다.
• 위의 강의에서 말하는 협력이라는것 또는 코드리뷰라는것 자체를 성장이라는것에 포인트를 맞추어 도움이 될 수 있는것 같다.
• 영상에서의 포인트는
  • 리더는 특히 관심과 의지를 가지고 참여해야하고
    • 코드를 비난하는것이지 나를 비난하는것이 아니니 기분을 나빠하지 않아야하지만
    • 비난 즉, 너, 왜, 맨날 그리고 명령이 아닌 적어도 피드백에 도움이 될 수 있는 예제 코드라도 보여주면서 도움을 주는 코드를 좋아지게하는 것과 요청하는 말 습관이 중요하다는 것을 느꼈다.
  • 대게 남들보다 조금 더 알고 있는 사실과 경험이 있다고 간혹 그런것도 모르니? 라는 말을 하는사람이 있는데 그렇더라도 모르면 더 가르쳐주려고 하고 이해시켜주는 예시라도 들어 설명해주는것이 좋지 않나 생각이 든다.
  • 여기서도 말하는 것 처럼 건설적인 피드백을 못하면 하지 않는것이 낫다는것 과 남이 하는 말이 틀리다라기 보다는 다르게 생각함을 인정해야 좀더 좋은 리뷰나 환경이 되지 않을까한다.
  • 그리고 환경 이야기가 나와서 그러는데 항상 이런 핑계를 많이 듣는것 같다.
    • 우리는 시간이 없어서 못한다. 능력이 부족해서? 또는 실력이 없어서라는 말이다.
    • 물론 그럴 수 있다. 시간 없을 수 있고 능력이나 실력이 부족할 수 있다. 하지만 어느누구가 매일 한가한 삶을 사는것도 아니고 똑같이 주어지는 24시간을 어떻게 잘 사용하고 활용하는것이 개인 관리가 아닐까 한다.
    • 그리고 처음부터 우리가 태어나면서 김연아, 박지성, 손흥민이 될 수 있는 사람이 몇이나 될지 생각을 해본다면 다들 비슷하다. 나이나 경력이 많아서 더 많이 알고 적으면 덜 알고 내말대로 해야한다는 것은 정말 잘못된 생각인것 같다.
    • 나또한 유치원생들이나 어린 애들을 보면서도 배울점을 많이보는데 그런 막히 생각을 가지면 무엇인가를 더 가치있게 해낼 수 는 없는것 같다.
  • 리뷰 자체도 물론 더 잘하고 못하는 능력차이가 있을 수 있지만 결국은 사람간의 관계이다. 서로 존중을 할 줄 알아야하고 무엇인가 잘못됨을 지적을 하거나 피드백을 주는 경우라면 적절한 예시로 이해를 시켜줘야한다고 생각한다.
  • 여기서도 말하는것이 저자가 더 고생해야 리뷰하는사람이 덜 고생한다는 말처럼
    • 리뷰를 해주는 사람도 사실상 역으로는 저자가 되는 상황에서 피드백에 대해서 이해할수 있도록 설명해주는 것이 좋다라는 것이 코드 리뷰에서 가져야하는 자세같다.
    • 그리고 몇번해보고 이전에 이렇게 했는데 안됬다는 그런 경험 때문에 다른 사람들에게 영향을 주지 않고, 여기서도 말하는 괴롭다고 생각이 들면 자주해서 익숙해져라라는 말처럼 꾸준히 해보는것이 특히 우리 회사에서 필요한 점인것 같다.
      • 꾸준히라는게 쉬워보여도 제일 어렵기 때문에 시간이 없다 능력이 부족하다라는 핑계 없이 일단 해보고 판별하는 사람이 제 자신 스스로도 되어야할 것 같고 이 글을 읽은 독자들도 됬으면 좋겠다.