우리가 일하는 방식
•
잘하고 많이 알고는 중요하지 않아요. 팀 활동에 즐겁게 참여할 수 있으면 그걸로 좋아요.
•
어려움을 겪을 때 언제나 편하게 소통할 수 있는 팀 환경을 추구해요.
•
FE, BE 모두 함께 참여하기를 지향해요. 팀원 모두가 본인이 작성한 코드를 포함한 전반적인 코드에 대한 이해를 갖추기를 원해요.
•
선택 하나하나에 의미있는 소통이 뒷받침 되기를 원해요.
•
본인의 의견과 다르더라도 틀림을 주장하지 않아요.
프로젝트 관리
•
◦
선정 이유 : issue를 이용해 스케줄 및 feature를 관리하기 때문에 issue와의 연동성이 좋은 Github Project를 선정했어요.
코드 리뷰
CL : changelist의 약어로 버전 관리(Version Control)에 제출되었거나 코드 리뷰가 진행 중인 독립된 변경 단위입니다.
LGTM : Looks Good to Me의 약어입니다. 위의 코드 리뷰를 승인할 때, 리뷰어가 사용합니다.
Nit : 리뷰어들은 항상 무엇인가 더 나은 방법이 있을 수 있다는 의견을 자유롭게 남길 수 있어야 합니다. 그러나 그것이 그다지 중요하지 않다면 “Nit:”와 같은 접두어를 붙여 코드 작성자가 선택할 수 있도록 해야 합니다.
PR : Github의 협업 방식과 관련된 Pull Request를 의미합니다.
•
모든 PR에 대해 리뷰를 작성해요.
•
모든 팀원의 comment를 받기 전까지 자체 merge하지 않아요.
•
리뷰어는 무엇을 봐야하는가?
•
코드 리뷰는 아래 사항을 확인해야 해요.
◦
설계(Design): 코드가 잘 설계되었고 시스템에 적합한가?
◦
기능(Functionality): 코드가 작성자의 의도대로 동작하는가? 사용자에게 적합하게 동작하는가?
◦
복잡성(Complexity): 더 간단하게 만들 수 있는가? 나중에 코드를 다른 개발자가 보았을 때 쉽게 이해하고 사용 가능한가?
◦
테스트(Tests): 잘 설계된 자동 테스트가 있는가?
◦
작명(Naming): 개발자가 변수, 클래스, 메소드 등에 명확한 이름을 선택했는가?
◦
주석(Comments): 주석이 명확하고 유용한가?
◦
스타일(Style): 스타일 가이드(코딩 컨벤션)를 따르고 있는가?
◦
문서화(Documentation): 개발자가 관련 문서도 업데이트 했는가?
참고 자료 : Code Review Developer Guide