기획이 끝났으니 개발을 해야지
빠른 개발을 위해 Node.js 를 선택했다. 팀원 셋 다 JS 에 대한 경험이 많이 없어 Toy Project로 ‘Todo List’ 를 만들고 있었고, 그에 대한 피드백이 이어진 멘토링이었다.
또한, 매번 강조하신 블로깅, 기록 등에 관한 이야기도 나누었다.
멘토링 기록은 주제에 대해 나누고, 멘토님의 질문(Q)과 우리의 답변(A) 그리고 멘토님의 솔루션(S)으로 구성한다.
1. Todo List (Toy Project)
협업을 하기 위해, GitHub Repository 를 팠고, 프로젝트 스펙과 코딩 컨벤션, 페이지 별로 나눈 역할 분담에 대한 README 문서에 대한 피드백이 있었다.
Q. 왜 코딩 컨벤션 인가?
A. 개발에 들어가기 전, 블로그 글을 보면서 또는 책(오래된 책이긴 한데 ‘읽기 좋은 자바스크립트 코딩 기법’을 봤다)을 보면서, JS 언어 자체가 가지고 있는 자유도와 컴파일 시 코드가 어떻게 바뀌는지를 감안하다 보니, 코딩 컨벤션을 맞추면서 가야겠다 라는 생각이 들었고, 또한 협업 시 생기는 세세한 부분, 예를 들어 ‘TAB의 공백 개수’, ‘이름 규칙’ 등등 merge 할 때 잡음을 최소화 하기 위해 정리했다고 말씀을 드렸다.
S. Lint
컨벤션을 지키고, 정립하는 것도 좋지만 자동화 할 수 있는 방법이 있다. 자동화 할 수 있는 부분에 대해서는 최대한 시간을 아끼면서 가는 것이 좋다.
컨벤션을 맞출 때, 유명한 회사 (ex, Google / Facebook … ) 의 규칙을 사용하면, 의견 조율이 더 원만해 지고, 좋은 컨벤션 또한 얻을 수 있다.
GitHub 에 Pull Request 를 날릴 때, Lint 를 돌려서 컨벤션 규칙을 맞춰라. 1차적으로는 본인이 규칙을 잘 지켜야겠지만, 놓치는 부분들이 있을 수 있다. CI 를 붙여서 Pull Request 를 날릴 때, 컨벤션에 대한 이벤트를 발생시켜서 확인해라.
keyword
- Circle CI
- Travis CI
Q. GitHub 을 이용한 협업
A.
- 저장소 하나를 두고 각자 브렌치만 따서 작업을 하는 경우.
- 저장소를 fork 한 후에 본인의 Repository 에서 개발을 하는 경우.
S. 최대한 Pull Request 를 많이 해라
코딩을 잘 못하고, 언어에 대한 이해도가 높지 않기 때문에, 최대한 기능을 잘게 쪼개서 많이 Pull Request 를 날리고, 최대한 빨리 검증을 한 후에 merge 하는 방식으로 가야 한다.
Q. 테스트 코드를 짜는가?
A. 도입 필요성을 느끼고 있지만, 사실상 경험이 없다.
S. TDD 방식으로의 개발을 추천한다.
테스트 코드를 짬으로서, 코드를 합쳤을 때도, 돌아갈 거라는 확신을 가질 수 있다. 아직은 모르겠지만, 꼭 짜야하는 테스트와 짜지 말아야하는 테스트를 육감적으로 느낄 수 있어야 한다. 기능을 최대한 작게 나눠서 테스트 코드를 짜보는게 중요하다. 리펙토링 또한 테스트 코드가 있을 때 가능 한 것(돌아가고 나서야 리펙토링이 필요하다는 의미).
- 특정 모듈에 함수 혹은 필드가 있는지 없는지 까지 테스트
- 라우터에 특정한 URL 이 매핑 되었는지 테스트
Q. 마이그레이션 에 대해 생각해 보았는가? (MongoDB 를 쓴다고 했는데 Schema 에 변동이 생긴다면 어떻게 되는가?)
A. 생각해 보지 않았다. 개념도 사실 잘 몰랐다.
S. 만약 배포 후에 User 테이블에 어떤 칼럼을 추가하라는 요구 사항이 들어왔다면?
서비스 중인 프로젝트 이고 DB 에 이미 데이터가 있는 상황에서 필드를 추가하라는 요구가 오는 경우가 있다. 마이그레이션 전략에 대해서 생각해보고, 어떻게 대처할 지 해당 DB 는 어떤 전략을 가지고 있는지 확인해 봐라.
2. 할 것
- 테스트 코드를 통한 Todo List 개발, 기본적인 것은 본인 로컬에서 돌려 볼 수 있는 상태
- 코딩 컨벤션에 대해 정리하고 커뮤니티에 글을 기재하고 검증 받기
- CI 붙이기