[마소콘 2018] 2080 라이프 강연 내용 정리 및 느낀점.

2018년 12월 15일에 와이프랑(개발자다..!) 마이크로소프트웨어 콘퍼런스에 다녀왔다. (줄여서 마소콘)

• 관련 링크 : https://www.imaso.co.kr/masocon2018/

전반적인 강연 내용은 기술부채를 개선하는 방법에 대한 내용들이었다.
기술부채란 개선해야 할 것을 알지만, 묵혀두고 있는 기술적 빚을 뜻한다.

일단 글을 쓰기전에 중간중간에 놓친 부분도 있고 (사실 집중을 잘 못한다..)
정리를 잘한다고 생각하지 않기에 강연자가 전달하고자 하는 부분을 제대로 짚었는지는 모르겠다.
하지만 강연 내용을 기억으로만 남기기에는 나중에 기억이 나지 않을 것 같아 정리를 해보려 한다.

2080 라이프 강연 내용 정리.

설계 또는 개발 그리고 안정화 과정에서 시간이 부족하다는 이유로 돌아가게만 짜는 경우가 있다. 또한 정해진 컨벤션을 무시하고 본인만 만족하는 코드로 개발하는 개발자들도 있다보니 기술부채가 쌓이고 그 빚을 값는데에 더 많은 시간을 쓰게되며 야근 철야를 하게 된다. 그런 기술부채들을 줄이기 위한 방안으로 강연자는 코드리뷰를 강조했다.

코드 리뷰란?

개발자가 작성한 코드를 다른 개발자가 정해진 방법을 통해 검토하는 일을 말한다. 서로가 검토를 통해 코드가 안고 있는 잠재적인 결함을 찾고 개선해가는 과정이다.

코드리뷰는 어떠한 방법으로 하는가?

코드리뷰시엔 Gerrit이란 툴을 사용하는것을 추천하였다.

그럼 Gerrit은 무엇인가?

Gerrit은 코드 리뷰 기능과 Git 서버 저장소 관리 기능을 제공하는 웹 기반 코드 리뷰 시스템이며. 일정 점수 이상의 코드 리뷰 점수를 얻어야 코드의 변경 사항을 적용할 수 있게 해 코드 리뷰를 강제하는 도구이다. 정리하면 Gerrit은 애초에 코드 리뷰를 자동화하고 강제하는 목적에 맞춰 만들어진 시스템이다.

• Gerrit은 참고글 : http://ithub.tistory.com/112 , https://d2.naver.com/helloworld/6033708

강연자가 다니고 있던 회사에서는 매일 커밋을 하고 싶을때마다 Gerrit에 적고 한명 이상의 리뷰어가 그 코드에 승인을 하자마자 커밋을 할 수 있다고 하였다. 그리고 코드리뷰는 하는게 좋다고 재차 강조하였다.

하지만 코드리뷰를 하면 시간이 많이걸리므로 다른 일정들이 영향을 받아버린다. 그래서 주저할 수 있는데 강연자는 리뷰 시 많이 보이는 문제들의 20%를 해결하면 80%의 문제는 해결할 수 있다고 하였다.

코드리뷰를 단축하기 위한 몇가지 가이드도 제시하였다.

1. 빌드타임은 짧은게 좋다.
2. 브랜치를 잘 쓴다. 브랜치마다 무슨 역할을 하는지 분류를 하여 관리한다. 코드리뷰할때 범위를 좁힐 수 있음. (merge를 했을 대 어떤일이 나올지 알게 되므로)
3. Style : 가독성을 높이면 코드리뷰를 빨리 볼 수 있고 리뷰시간이 빨라진다.
   • gerrit, commit 시 로직이 100줄이 넘어가지 않도록 되도록이면 짧게 커밋한다.
4. 코드 리뷰 관련 기록을 계속 남겨 히스토리를 쌓는다.
5. Refactor : // TODO(name) Refactor 주석 달기.
6. VSCode 시 확장팩 사용 : CodeMetrics -> 이걸로 분석하여 리팩토링 포인트를 찾음. 리팩토링은 시간이 날때마다 하는게 코드리뷰 시간을 줄이는 방법임.
7. TEST코드 작성.
8. 빌드테스트 자동화.

중요한건 커뮤니케이션

• 조직 전체가 코드 리뷰 문화를 자연스럽게 받아들이도록 하는 것도 중요하다
• 다른사람이 안한다고 하면 다 할 수 없다.
• 규모가 있는 회사같은 경우는 커뮤니티가 있어서 문서에다가 정리.. 새로 입사한 사람들한테 문서를 주면서 이렇게 하고 있으니 그 이유는 이러니 해달라고 부탁…
• 셋업하는게 시간이 많이 걸리므로 부담이 들고 의구심이 들지만 결국엔 품질이 좋아지고 버그잡는데 시간을 줄일 수 있으므로 결국엔 개발시간이 줄어듬
• 코드리뷰를 하지 않거나 가끔씩만 받게되면 언젠가는 본인몫으로 들어온다. (새벽근무 밤샘 등등..) 중시하는 문화는 결국엔 팀에 좋은 영향을 미친다.

느낀점

사실 이전 솔루션 회사를 다닐 때(좀 오래됐다..) Gerrit을 써볼려고 팀 차원에서 시도해본적은 있었으나.. 사실 잘 되지 않았다.

코드리뷰를 해본 경험에서 확실한 단점이라고 생각되는 것은 리뷰를 하는 부분은 다른 개발자도 어려워 하는 부분이거나 명확하지 않는 부분이라는것..
또한 커밋 시 계속 반려가 되면 (사실 자괴감이 든다.) 생산 의욕을 꺾을 때도 있다는 것이다.

기존 솔루션이 SVN을 사용하였고 당시 팀원들이 GIT에 그렇게 익숙하지는 않았다. (그리고 당시 이클립스를 개발툴로 썼는데 그 당시 EGit 은 그닥 좋지 못했다.) 또한.. 코드리뷰를 이미 어느정도는 구두로 하긴 했어서(대부분 팀장님이 했었고 팀장님 퇴사 후엔 리뷰가 필요할 것 같은 코드만 같이 공유) 그게 더 빨랐기에 그닥 필요성을 느끼진 못했던거 같다.

하지만 지금 생각하면 아쉬움이 많이 남는다. 다들 단점들에 대해서도 익숙해지는데 시간이 필요했는데 그 기간만 어느정도 확보되었으면 좀 더 좋은 품질의 제품이 되지 않았을까? 라는 생각이다. (사실 솔루션이 시간이 지나면서 매우 덩치가 커졌고 그러면서 에러를 잡는데 시간을 많이 쓰게 되었다.) 코드리뷰가 기술부채를 반드시 해결할 것이라고 보장할 순 없지만 개인의 발전 및 제품의 코드 컨벤션을 지키기 위해서라도 필요하다고는 생각한다. (결국엔 그것이 기술부채를 조금씩 갚아나가는 과정이라고 생각한다.)

다른 강연 후기들은 내일부터 천천히 써야겠다. 벌써 잘 시간이네..

관련자료

• https://www.imaso.co.kr/archives/4481
• http://it.chosun.com/site/data/html_dir/2018/12/15/2018121500832.html