아래는 토이프로젝트 코드의 일부이다.
위 코드와 아래 코드의 가장 큰 차이가 무엇일까.
우선 첫번째 사진은 주석내용이 눈에 띄고 비교적 깔끔하게 코드 구성이 되어있다. 주석내용은 작업용으로 제출할 때는 최소화해야 하지만 병합이나 코드 리뷰과정에서 협의되지 않은 네이밍이나 구현과정의 이해를 돕기 때문에 개인적으로 주석을 정리하며 코드를 작성해왔고 대체로 좋은 의견을 얻었던 것 같다.
두번째 사진은 메인 코드 진행에 비해 모듈을 불러오는 코드들이 지저분하게 배치되어 있다. Import 했음에도 연결되지 않는 모듈도 있고 기능적으로 겹치는 모듈들도 있다.
대부분 코드 컨벤션이 처음부터 정리되지 않고 중구난방으로 시작되어서 발생했다고 생각하기 때문에 다음 프로젝트때는 초반부터 팀 코드컨벤션과 ERD를 잘 기획하고 팀원들에게 공유해야 할 분명한 이유가 생긴 셈이다. ERD가 진짜 중요하구나 ;
협업툴의 경우는 Git 포크 방식으로 풀리퀘스트를 이용했는데 알고보니 이 방법이 팀단위 작업시 생각보다 자주 쓰이는 방법이 아니었고 좀 더 넓은 범위의 사람들이 오픈소스에 개별적으로 기여하기 위한 방법에 적합한걸 알게 되었다. 사실 단어만 봐도 collaborator보다는 contributor가 먼 느낌이지만 번거로움은 어쩔 수 없다.. 단지 이번에 이런 방식을 써봤으니 다음에는 더 자연스럽게 쓸 수 있겠다는 부분만 생각하기로 했다.
사실 본인은 지난 번 실수를 반복하지 않으려고 팀원들에게 맡은 단위별로branch를 구분하고 pull request를 적극적으로 사용하자 건의했는데, 정작 중요한 내용을 공유하지 못한 것 같아서 아쉬웠다. pull request 협업 프로세스를 활용해 원래의 목적에 맞게 작업 과정을 확인하며 활발한 의사 표현을 하면서 작업작업 진행 과정이나 버전 별 특징을 설명하는 readme 정리도 공통적으로 지적되는 피드백이었다. 기능단위로 짧게 구현을해서 PR하고 합치는 과정을 연습해 봐야겠다.
- ERD, 코드 컨벤션 기획은 미리 꼼꼼하게
- 작업 진행 과정이나 버전 별 특징을 설명하는
readme 작성 - 기능 단위로 짧게 구현/확인
Pull request빠르게
