저번 토이 프로젝트때는 생각보다 점수가 잘 안나와 피드백 받은 내용을 적용해 프로젝트를 진행했다.
토이 프로젝트1 피드백
- MVC 패턴 적용이 작 안 됨
-> DDD클래스 별로 역할 분담 명확하게 & MVS 패턴을 이용해 최종 리펙토링 진행 - 변수와 메소드 명을 작성할 때 역할이 명확하게 나타나도록 해야 함
-> 계층 별 변수와 메소드 명 통일
커밋규칙
- gitflow전략 사용
- develop 브랜치에는 에러 발생 코드 절대 업로드 금지!
- 병합 후 에러가 발생한다면 hotfix브랜치를 이용해 해결할 것
커밋 규칙이나 브랜치 규칙 역시 저번 토이 프로젝트와 동일하게 진행하는 동시에 저번에 아쉬웠던 점들을 보완하여 프로젝트 진행
일정
내가 맡은 역할을 여행 cud와 테스트 코드 작성이었는데, 생각보다 시간이 남았다. 나는 일찍 끝냈지만 다들 제출 직전까지 리펙토링하고 고민하는걸 보고 많이 반성했다. 다들 리스펙...
API문서
우리는 사전에 API문서를 미리 작성하고 거기에 맞춰 개발을 했다. API문서를 미리 작성해 본 것은 처음이었는데, 생각보다 편했다... 앞으로도 많이 이용해야지...
ERD
사실 가장 많이 고민했던 것이 ERD 아닐까 싶다. 하나의 여행이 여러개의 여정을 가지는데, 그 여정안에서도 이동,숙소, 체류로 나뉘어져 있어서 정말 헷갈렸다.
자유롭게 각자 해석하랬는데 팀원들끼리도 각자 생각하는게 다 달라서 기획하는데 시간이 생각보다 오래 걸렸다.
결국에는 여정의 타입을 이돈,숙소,체류 세 가지로 나누기로 결정!
공통 유틸리티
공통 유틸리티를 꼭 포함하라는 말에 팀원들이 단체로 멘붕이 왔던 기억이 난다. 도대체 일시에 대한 공통 유틸리티가 뭔데....
팀원들끼리 깃 이슈를 등록해 토론한 결과 '일시에 대한 유틸리티로 활용해라' 라는 문구에 집중해 출발시간과 도착시간을 이용해 여정은 몇 박인지, 또는 얼마나 시간이 소요되는지를 계산해주는 것을 공통 유틸리티로 관리하기로 결정하였다.
그 외에 여행 시작 날짜가 종료 날짜보다 늦지 않도록 검증해주는 코드도 유틸리티로 포함해 관리하였다.
후기
팀원들이 다들 열정적으로 참여해주고 코드 리뷰 많이 달아달라는 피드백도 잘 지켜주어서 너무너무너무 좋았다! 조장님이 프로젝트가 끝나고 수고했다고 기프티콘을 보내주셨는데 너무 감동.... 팀원들 너무 좋고 프로젝트가 끝나고도 다음번 토이 프로젝트에는 더 나은 개발을 하기 위해 끝까지 피드백을 하는 모습들을 보고 정말 본받아야겠다는 생각이 들었다.
이런게 참개발자의 자세인가... 난 아직 멀었다....
또 토이 프로젝트 발표회에서는 다들 동일한 주제를 가지고 다양한 기술들을 많이 사용하고 집중한 부분도 다 달라서 정말 많이 배워갔다. 나만 빼고 다들 잘하나보다...혜미 화이팅...
