2월 6일 부터 2월 17일 까지 진행된 프로젝트가 끝이 났다.
팀이 선정되고 나이키의 웹사이트를 클론 코딩 하는것으로 정해졌다.
처음에는 기능 구현을 하는 것에 초점을 두고 기술적으로 어떻게 접근해야 나이키라는 웹 서비스에 가장 근접하게 구현 할 수 있을까 고민을 했다.
예를 들면 나이키에서 회원가입 할 때 이메일 인증 방식 같은 것이나 무한스크롤방식으로 페이징을 구현했던 부분들을 고려했었다.
하지만 프로젝트를 진행하게 됨으로써 깨닫게 된 사실은 처음 부터 기술적으로 완벽하게 나이키 사이트와 똑같이 구현하는 것 보다 프로젝트 기간이 짧기 때문에 기본에 충실해서 기본 기능 구현에 초점을 맞추고 프론트와 백엔드간 문제점이 발생 할 수 있는 경우의 수를 최대한 줄이는게 짧은 기간내의 팀 프로젝트에서 완성도를 높이는 방법이라는 것을 깨닫게 되었다.
문제점
그리고 프로젝트를 진행하면서 느낀 문제점 몇가지 정리해보려 한다.
데이터 모델링에 시간 투자를 너무 많이 했다는것이 첫번째 문제점인 것 같다.
데이터 모델링이 예상 기한 보다 하루 반 정도 더 시간을 쏟게 되었다. 그렇게 됨으로써 기능 구현하는 시간이 더 짧아 지게 되었고 결과적으로 기능 구현의 완성도도 낮아졌고 프론트엔드와 통신하는데 필요한 시간도 줄어들게 되었다.
그리고 처음부터 완벽한 데이터 모델링을 구축할 수 없다고 생각하고 있고 프로젝트 진행하면서 역시 중간중간 몇차례 데이터 모델링을 수정함에 따른 코드의 수정도 불가피하게 됨으로써 시간을 더 소비하게 되었다.
두번째 문제점은 위에서 서술한 문제점의 결과이기도한데 프론트와 백엔드의 통신하는 시간이 줄어듬에 따라 서로 이미 기능구현은 되어있다하더라도 통신을 해 보면서 코드를 수정해야 할 부분이 분명 있기 마련인데 FE, BE 통신을 맞춰보는 시간을 많이 갖지 않아서 Route 가 서로 다른 규칙성을 띄고 있었던 부분도 아쉽고 통신하면서 fetch 메서드 이용시 다음과 같은 CORS 정책위반에 관한 에러에 직면하기도 했었고 이 때문에 시간을 많이 잡아먹게 된 것도 큰 문제점 중 하나였다.
Access to fetch at ‘https://api.lubycon.com/me’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.
개선점
처음 부터 완벽하게 데이터 모델링하려고 노력하지 말고 기본에 충실한 모델링을 만드는 방식으로 가는게 맞는 것 같다.
Agile 프로세스 적인 관점에서 봤을때 먼저 스프린트간 필요한 작업을 기능단위로 세부적으로 잘게 쪼개서 작업 흐름에 맞게 업무 분담을 하는 것이 좋을 것 같다.
예를 들면 로그인 기능과 회원가입 기능은 흐름이 같고 장바구니 기능과 결제하기 기능은 같은 흐름을 공유하고 있다.
따라서 팀 업무 효율을 높이기 위해서는 기능 단위로 같은 흐름을 갖는 업무별로 팀원들에게 할당이 될 수 있게 한다면 좀 더 생산성을 높이고 업무 효율이 높아 질 것 같다.
FE, BE 의 작업 context 를 맞추는데 시간을 더 할애해야 겠다. BE 기능구현이 먼저 앞서 나가던지 또는 FE 기능구현이 먼저 앞서나가더라도 결국 결과물은 서로로 기능 구현이 완료된 교집합에 대해서만 실질적으로 사용이 가능하고 시연이 가능한 부분이기 때문에 FE, BE 간 작업 context 를 맞추는게 중요할 것 같다.
이 작업 context 를 맞추는데에는 Route 의 convention 을 맞추는 것과 Request Body, Reponse Body 의 JSON 형식을 맞추는 부분도 포함이 될 것이다.
