개발 문화

우리가 일하는 방식

• 잘하고 많이 알고는 중요하지 않아요. 팀 활동에 즐겁게 참여할 수 있으면 그걸로 좋아요.
• 어려움을 겪을 때 언제나 편하게 소통할 수 있는 팀 환경을 추구해요.
• FE, BE 모두 함께 참여하기를 지향해요. 팀원 모두가 본인이 작성한 코드를 포함한 전반적인 코드에 대한 이해를 갖추기를 원해요.
• 선택 하나하나에 의미있는 소통이 뒷받침 되기를 원해요.
• 본인의 의견과 다르더라도 틀림을 주장하지 않아요.

프로젝트 관리

• schedule, feature, backlog는 Github Project를 이용해 관리해요.
  • 선정 이유 : 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](https://google.github.io/eng-practices/review/)_