나의 첫 웹개발 팀 프로젝트 회고

yoondgu·2022년 7월 5일
0
post-thumbnail

지난 주 수요일, 2주 동안의 팀 프로젝트가 끝이 났다.
개발 공부를 시작하고 처음으로 해본 프로젝트, 그것도 팀 프로젝트였다.
공부한 것을 연습하기 위한 세미프로젝트라 부족한 점이 많았지만 말이다.

JSP model1 개발방식의 실습을 위하여 5명으로 구성된 각 조마다 실제 웹사이트 하나를 레퍼런스 삼아 구현해보는 것이 프로젝트의 목표였다.

나는 장바구니 및 주문 그리고 배송지 관련 기능을 맡았다.

  • 장바구니 조회 페이지에서는 체크박스 선택에 따라 달라지는 화면 내용, 장바구니 아이템의 변경 작업이 이루어져도 체크박스 상태를 유지하기, 배송지 관련 출력 등의 사항을 고려했다.

  • 사용자는 여러 개의 배송지를 추가, 수정, 삭제할 수 있다.
    화면에 출력되는 '선택 배송지'는 주문할 때마다 주문서의 배송지로 하나의 배송지를 선택하는 것이다.
    그와 별개로 DB에 저장되는 사용자의 기본 배송지는 별도 선택한 배송지가 없을 경우 '선택 배송지'가 된다.
    배송지 관리 페이지는 마이페이지 배송지관리, 장바구니 조회, 홈의 배송지아이콘 드롭다운 세 가지 경로에서 접근할 수 있다.
    각 경로에 따라 적절하게 페이지 재요청 되도록 코드를 짰다.


  • 장바구니 -> 주문 시퀀스

  • 주문 내역 페이지에서는 페이징 처리, 기간 별 조회를 구현하였다.

  • 주문 상세 내역 페이지에서는 모달창을 통해 상품을 다시 담거나, '배송준비중' 이전의 주문을 전체 취소시킬 수 있다.

  • 상품을 담는 모달창은 별도 파일로 분리하여 도서상세페이지에서도 활용하였다.

벌써 프로젝트가 끝난지 일주일이나 지났는데, 의외로 굉장히 짧은 기간의 이 프로젝트에 대한 회고를 하는 게 엄두가 안났다. 하는 김에 최선을 다 한다고 밤낮, 주말 내내 작업을 하다보니 조금 진이 빠졌나보다.
하지만 더는 미룰 수 없어서 오늘, 프로젝트 소개와 필수적인 내용들을 먼저 깃허브에 정리해두었고 개인적으로 느낀 점들은 이곳에 남기려고 한다.

1. 표기법에 일관성을 갖자.

자바에서 변수 선언하는 데 가장 익숙한 채로 생각 없이 막 쓰다보니 소스코드든 파일명이든 카멜표기법과 그렇지 않은 것들이 뒤섞이게 됐다.
브라우저에 따라 url의 대소문자 구분여부도 달라진다고 알고 있는데, jsp파일도 어떤 건 대문자가 섞여있어서 오류는 발생하지 않더라도 혼란스러워 좋지 않았다.
다음부터는 표기법에 있어 꼭 규칙을 통일해서 작성해야겠다.

2. 변수 선언 위치에 신중하자.

사용자 상호작용 부분을 구현하면서 생각보다 스크립트 코드를 많이 작성하게 되었는데,
js에서도 자바에서처럼 변수 선언 위치를 신중히 해서 혼란을 야기하거나, 불필요한 선언을 하지 않도록 더 신경써서 써야겠다.

3. 기본적인 것부터 전체를 완성하고, 그 다음 상세한 기능을 만들어나가자.

자꾸 당장 눈에 보이고, 클릭해서 실행되는 부분에 세부적인 완성도를 높이려고 하다보니 하나의 기능을 구현하는 데 시간을 많이 쏟게 되었다.
완벽을 추구하는 것은 좋지만, 작업 순서는 기본->디테일로 가야 한다.
전체 구현 내용을 모두 쭉 정리해보고 작업을 하는 것은 굉장히 도움이 많이 되어서 계속 습관으로 가져가려고 한다.
하지만 정작 실제 작업할 때는 자꾸 디테일에 집착하고 있었다!.. 그래도 덕분에 다양한 개발방식(시스템 팝업, 모달, 동기식 요청, 비동기식요청, 로컬스토리지 활용 ..) 을 시도해본 것은 좋았다.

4. 손으로 개발하지 말고, 머리로 개발하자.

구현 내용을 정리해보고도 비슷한 코드가 반복되면 생각없이 복사, 붙여넣기 해놓다가 쉽게 갈 길도 어렵게 돌아서 가는 상황이 생기곤 했다. 손에 익어서 익숙한 내용을 입력하는 것, 복사-붙여넣기로 빠르게 코드를 작성하는 것만이 다가 아니다.
무엇을 구현하는지 머리로 계속 생각하면서 하자.

5. 협업에 영향을 주는 부분들은 확실하게 결정하고, 또 공유하자.

팀 프로젝트인데다가 조장이 되어서 사실 부담감이 없지않아 있었다.
초기에 공통 사항에 대한 협의를 가능한 확실하게 정리해두고자 했는데, 생각처럼 잘 되지는 않았다.
DB컬럼을 추가하게 되면 sql문을 공유하는 것 등등이 기본적으로 신경써야 할 부분이었는데
'확실하게 공유하자'는 내 생각 자체가 팀원분들께 제대로 전달이 되지 않았던 것 같다.

이번 프로젝트에서는 주로 소통에 대한 고민을 많이 하게 되었다.
아무리 카톡 메시지로 변경사항을 보내두더라도 답장이 없으면 확인 여부를 알기 어렵기도 했고.. 사람들은 모두 소통방식이 다르다.
문서화와 개발 방식에 대한 사전 협의, 즉각적인 상황 공유가 중요하다고 느꼈다.

마감 때까지는 구현 예정이라고 알고 있었던 기능이 미구현 상태인 것을 발표 직전에 알게 되는 상황도 있었다.
각자 맡은 기능을 구현하는 것이 중요하기 때문에 나도 내 파트에만 집중한 것이긴 하지만, 그런 상황에 대해서 조장으로서 더 좋은 방법은 없었을까 아쉬움이 남기도 했다.

6. 새로 알게 된 점, 겪어보지 못한 오류는 바로 기록하자.

이건 뭐 길게 말할 것은 없고, 내 기억을 과신하지 않고 기록을 사랑하기로ㅋ 했다.

프로젝트 정보

프로젝트에 대한 상세한 소개와 정보는 github 저장소 에서 확인할 수 있다.

  • 깃허브에 DB 설정을 위한 전체쿼리를 저장했고, 개발환경 버전 또한 마크다운에 기록해두었다.
    시간이 지난 뒤 다시 확인할 때에도 어플리케이션이 정상적으로 작동할 수 있도록 DB 설정값과 각종 개발환경 버전을 정리해두는 것이 중요할 것 같아서다.

0개의 댓글