1차 프로젝트 계란후라이 회고

doyeonlee·2023년 2월 19일

프로젝트 회고

목록 보기
1/1
post-thumbnail

다소 늦은 감이 있지만,
열심히 정리하다가 드디어 회고를 적어본다..


프로젝트 상세 설명

계란후라이

프로젝트 주제 : 농산물 쇼핑몰

프론트 3명, 백엔드 2명과 함께 Vanilla JS로 진행.

계란후라이 레포지토리 주소

https://github.com/leedo97y/vegetable


계란후라이 소개

관리자가 제품과 카테고리를 관리할 수 있고 사용자는 제품에 접근할 수 있으며, 장바구니 추가, 주문하기 등이 가능합니다.

  • 사용자는 회원가입, 로그인을 할 수 있고, 마이페이지를 통해 회원정보 수정 및 탈퇴 등 사용자 관련 CRUD를 할 수 있습니다.
  • 관리자 페이지가 있습니다.
    • 여기서 관리자가 제품, 카테고리 그리고 회원 주문 정보에 CRUD 기능을 수행하며 관리할 수 있습니다.
  • 장바구니 관련 기능을 프론트 단에서 수행할 수 있습니다.
  • 일반 사용자는 제품과 카테고리에 대해 관리자의 CRUD 기능으로 접근할 수는 없지만 정보를 조회할 수 있습니다.
    • 조회한 정보를 바탕으로 장바구니와 주문을 생성할 수 있습니다.


기술 스택

계란후라이 기술 스택

프론트엔드

기술명설명
EJSHTML을 컴포넌트화 하여 사용하기 위해 사용
BULMA스타일링을 간단히 하기 위해 사용
Swiper메인 페이지 슬라이더를 구현하기 위해 사용
CKeditor게시글 작성하는 에디터를 구현하기 위해 사용
Daum 도로명 주소 API배송지 입력,
사용자 정보 페이지 주소 설정 시 사용자의 편의를 위해 사용
Fontawesome아이콘을 넣기 위해 사용

백엔드

기술명설명
Express JS가볍게 웹서버를 구현할 수 있기 때문에 사용
mongoDB, mongooseDB의 스키마를 설정하기 위해 사용
express-validator간편한 유효성 검사를 위해 사용
Joi중복적으로 사용되는 코드의 유효성 검사를 위해 사용
Multer, Cloudinary,
Multer-Storage-Cloudinary
게시글에 사진을 넣을 때
클라우드에 저장해서 사용하기 위해서
Jest코드 테스팅을 위해 사용한다.

배포

기술명설명
NGINX더 적은 자원으로 빠른 서비스가 가능하기 때문에 사용
PM2node.js를 사용해서 만든 프로그램을 잘 관리하기 위해 사용

아키텍쳐

계란후라이 아키텍쳐



프로젝트 팀 규칙

백엔드와 처음하는 협업이기도 했고, 다수와 프로젝트 관리를 해본적도 없기 때문에 걱정부터 앞섰다.

그래서 팀 규칙을 세웠으며, 스크럼 시간, 소통 방식, 브랜치 규칙, 커밋 컨벤션 등 정해야 할 것들을 줄세워 놓고, 하나하나 정해갔다.

그렇게 완성된 팀 규칙..!

1. 매일 아침 10:00 ~ 10:30 까지 회의 및 스크럼
2. 개인적인 이야기는 카톡으로! 개발관련 이야기는 디스코드로!
3. 10시부터 22시까지는 연락 빨리 잘 되도록 노력하기!!!
4. 주석 자세히 쓰기 / 브랜치명 규칙 정하기 (커밋컨벤션)

  • BE : feature-BE-login-api
  • FE : feature-FE-login
    • 브랜치명에 띄어쓰기가 있는 경우는 - 로 대체합니다.
      • (예시) 검색목록 기능 : feature-FE-search-list

        ....등 이 있다.

커밋 컨벤션은 링크를 참고하여,
아래와 같이 메세지 구조를 맞췄으며, 제목에도 타입을 맞춰서 써줬다.

계란후라이 커밋 메세지 형식



프로젝트 관리 툴

디자인 및 기획은 Figma, 일정 관리는 Trello, 팀원 간 소통은 Discord와 카톡을 사용해 진행했다.

Trello를 사용하여 프로젝트 일정 관리를 했으며,
Trello의 보드를 사용하여 ToDo(해야 할 것), Doing(하고 있는 것), Done(한 것)으로 나눠서 관리했다.

계란후라이 트렐로 보드

❖  Trello를 사용하고 좋았던 점

처음 사용해 보는 툴이었지만, 프로젝트의 진행상황이 간단히 보인다는 점이 매우 좋았다.

또, 각자 할 일을 할당해놓을 수 있어서 어떤 부분을 진행할 것인지,
어떤 부분을 진행 중인지, 누가 어떤 부분을 했는지를 알 수 있어서 상당히 좋았다.



프로젝트 디자인 및 기획

기획 시에 피그마를 작성하며 대강 마크업을 해나가기로 했다.

계란후라이 피그마

이렇게 대강 디자인 없이 뼈대만 잡아서 진행했고,
그 결과 나중에 디자인을 다듬으려니 조금 힘들었다ㅜㅜ

페이지 뼈대를 그린 후에 각자 맡을 페이지를 정해서 세부적인 부분들을 추가 했고, 코드 작성을 시작했다.



구현한 부분

  • 회원 정보 관리 페이지

    • 회원 정보를 수정, 회원 탈퇴를 할 수 있는 페이지를 구현했다.
      ⇀  주소를 수정 할 때 Daum 도로명 주소 API를 사용해 사용자의 사용성을 높였다.

    회원 정보 수정 페이지

  • 관리자 관리 페이지

    • 관리자가 할 수 있는 제품 관리, 카테고리 관리, 주문 관리 각 페이지로 넘어가기 전에 나타나는 페이지를 구현했다.

    관리자 관리 페이지

  • 주문 내역 전체 조회, 상세 조회 페이지

    • 전체 주문 내역을 조회하는 페이지를 구현 후,
      주문서 번호를 클릭하면 상세 주문서로 이동하는 페이지를 구현했다.

    ❖  전체 주문 내역
    ⇀   주문 일자와 주문서 번호, 주문 상태와 주문 총액을 보여주는 페이지이다.

    전체 주문 내역

    ❖  상세 주문 내역
    ⇀   각 주문 별로 상세 내역을 알려주는 페이지이다.
          주문 상품의 사진과 이름, 주문 갯수와 상품 금액이 표시된다.

    주문 상세 페이지

  • 에러 페이지
    • 에러가 나면 보여주는 페이지이다.
  • 푸터 컴포넌트 분리
    • 푸터 컴포넌트를 EJS를 이용하여 작성하여, 재사용성이 좋게 만들었다.
      ⇀  푸터, 헤더와 같은 부분은 여러 페이지에 쓰이는 만큼 반복되는 코드를 줄여야 코드 관리가 수월해지므로 EJS를 사용하여 분리하는 것이 좋겠다고 생각하여 사용했다.
      실제로 사용 후에 훨씬 코드를 관리하기 쉬웠다.


오류 내용과 그 해결 방법

1. Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.

라는 에러가 발생했다.

이 문제는 express 경로 문제였으며,

express에서 정적 파일을 제공하려면 express.staticExpress에 내장된 미들웨어 기능을 사용해야한다.

아래 코드대로 작성해주면 된다.

express.static(root, [options])

여기서 root는 정적 자산을 제공할 루트 디렉토리를 지정한다.

처음에 css, js 파일을 전부 public 폴더에 넣는 것으로 해결을 했었는데, 찾아보니 express 공식문서에서 정적 파일을 제공하려면 저런 방식으로 해결하라고 알려주고 있었다. ^^;

express 공식문서

public으로 수정

지침에 따라서 위와 같이 디렉토리를 public으로 수정해주고 css, js와 같은 파일들의 경로를 절대경로로 수정해주었더니 해결되었다.


2. 주문 내역 상세 페이지가 주문 별로 뜨지 않는 문제

❖  페이지의 흐름 !

이 문제를 해결하려면 먼저 페이지의 흐름을 이해해야 한다.

상세페이지로 오려면 우선 전체 페이지에서 주문 내역을 클릭해야하고,
해당 주문 내역에 맞는 상세 내역이 뜨게 된다.
페이지의 흐름 그림


페이지의 흐름을 알겠다면, viewsRouter 코드를 보자.

viewsRouter 코드

여기서는 해당 페이지 뒤에 orderId를 붙여서 라우팅 해주고 있으며, 경로에 있는 orderId를 params를 사용해 가져온다.
그리고 가져온 orderId를 render 시에 함께 보내준다.

orderHistoryDetail 코드

주문내역을 클릭하여 들어간 orderHistoryDetail 페이지의 pathname에서 /를 기준으로 split 하여 path에 저장해준 뒤, path를 요청 api에 넣어 해결해주었다.



프로젝트가 끝나고는 KPT 회고를 진행했었다.

KPT 회고란?

KPT 회고는 Keep, Problem, Try의 앞글자를 따와서 만들었으며,
프로젝트 진행과정에서 좋았던 점을 유지하고, 문제를 명확히 정의하고,
이를 바탕으로 다음에 시도해야할 것 들을 정리하는 회고이다.

계란후라이만의 KPT

Problem 부분은 1차 프로젝트에서 불편했던 부분,
2차 프로젝트에서는 개선했으면 하는 부분에 대해 작성했다.

마지막으로 Try 부분은 앞의 Problem에서 작성했던 부분에 대한 해결책을 작성했다.

KEEP

1차 프로젝트에서 만족하고 있는 부분,
2차 프로젝트에도 이어갔으면 하는 부분에 대해 작성했다.

  • 프로젝트 진행 방식을 Trello를 사용하여 진행한 것.
  • 개개인의 에러 해결에 그치지 않고, 코드 설명을 하며 해결방법을 공유함.
  • 다양한 라이브러리와 툴을 사용하며 효율적인 방법을 찾아 개발함.
  • 디스코드를 통해 매일 회의를 하며 적극적인 소통을 함.
  • 긴급한 회의를 했을때, 자신의 일이 아니더라도 모두가 참석해 해결방안을 찾음.

PROBLEM

  • 코드 스타일, 디자인 등 세부적인 부분을 계획하지 못하고 개발을 함.
  • 기한 마지막 날 배포를 하여 오류를 발견하고 수정할 시간이 부족했음.
  • 스크럼 시간을 조정할 필요가 있었다.
  • git에 대한 숙지가 부족했음.
  • 관리자 상품 페이지, 상품 목록 페이지, 주문 페이지 등 페이지네이션을 적용하지 못함.
  • 초기 모델을 설정 시, 많은 시간을 투자해야 할 것 같다.

TRY

  • 프로젝트 계획 단계에 중요성을 두고 2~3일 시간을 투자할 필요성이 있을 것 같다.
  • 코딩 컨벤션, 스타일, 기능 구현의 깊이, 추가 기능 등 상세히 기획을 해야할 것 같다.
  • 초반에 모든 기능을 전부 분배하고 개발을 시작해야한다.
  • 효율적인 스크럼 시간을 정하는 것이 중요할 것 같다.
  • 정보 공유시, 메인 플랫폼을 두고 필요한 문서, 링크를 모아놓는 것이 중요할 것 같다.
  • 멈칫하지 말고 말하고 싶은게 있다면 자신 있게 주장하기..!
profile
느려도 천천히 꼼꼼하게 !

0개의 댓글