[Assignment]2 프레시코드

프로젝트(자세히)

개발 요구사항

• Database 는 RDBMS를 이용합니다.
• 로그인 기능
  • JWT 인증 방식을 구현합니다.

기능 개발

• 로그인 기능
  • 사용자 인증을 통해 상품 관리를 할 수 있어야 합니다.
    • 구현
      • JWT 인증 방식을 이용합니다.
      • 서비스 실행시 데이터베이스 또는 In Memory 상에 유저를 미리 등록해주세요.
      • Request시 Header에 Authorization 키를 체크합니다.
      • Authorization 키의 값이 없거나 인증 실패시 적절한 Error Handling을 해주세요.
      • 상품 추가/수정/삭제는 admin 권한을 가진 사용자만 이용할 수 있습니다.
• 상품 관리 기능
  • 아래 상품 JSON 구조를 이용하여 데이터베이스 및 API를 개발해주세요.
    • 구현
      • 서비스 실행시 데이터베이스 또는 In Memory 상에 상품 최소한 5개를 미리 생성해주세요.
      • 상품 조회는 하나 또는 전체목록을 조회할 수 있으며, 전체목록은 페이징 기능이 있습니다.
      • 한 페이지 당 아이템 수는 5개 입니다.
      • 사용자는 상품 조회만 가능합니다.
      • 관리자는 상품 추가/수정/삭제를 할 수 있습니다.
      • 상품 관리 API 개발시 적절한 Error Handling을 해주세요.

기술

• node, express
• sequelize, mysql
• postman, aws
• jest

과제 접근

• 첫 과제에 비해 인원이 많다보니 역할을 분담하는 것도 쉽지 않았다. 인원이 많아 시간적 여유가 있을 거란 생각에 각자 해보고 싶었던 역할을 고르기로 했다. 각자의 역할을 나누고 팀내 잘하시는 분들은 역할 뿐만 아니라 도움을 주시기로 했다. 역할은 크게 api, db, 테스트, aws, 리팩토링으로 나누었다. 첫날엔 두 팀으로 나누어 api명세 설계와 리팩토링을 했다. 리팩토링을 하는 이유는 기존의 이용하는 방식으로 과제를 진행하기 때문에 더 나은 환경을 만들기 위해서이다. api 명세 설계는 생각보다 쉽게 쓰여졌지만 나중에 여러 문제를 불러왔다. 우선 다 같이 상의한 것이 아니란 점이다. 리팩토링을 했던 팀원들과 api에 대한 의견차이가 생겨 수정을 해야 했다. 또한, 명세가 명확하지 않아 다음날 api를 짠 팀도 api가 헷갈렸다. 명확하게 api를 짜야 나중에 혼선이 없다는 것을 몸소 느꼈다. 팀원이 미리 db ERD를 설계해 와서 구조를 쉽게 파악할 수 있었다. 이번 과제는 반드시 RDBMS를 사용해야 하기 때문에 mysql과 sequelize를 선택했다. SQL로 갈지 ORM으로 갈지에 대한 고민이 있었는데 sequelize는 SQL이 필요하면 날릴 수 있었기에 sequelize를 선택했다. 테스트 툴로는 jest와 mocha 중 어느 것을 쓸지에 대해 이야기 하였다. mocha는 필요한 것들을 따로 추가하면서 사용해야 하는 어려움이 있어 편리한 jest를 택하여 테스트를 하기로 결정했다.

구현

• 테스트와 데이터베이스에 관심이 있어서 역할을 나눌 때 도전해보고 싶었지만, api도 아직 부족한 게 많다 생각하여 api를 골랐다. api 명세를 잘 때 과제에 대한 구조가 머리속에 그려지지 않아 어려움을 겪었다. menu와 item의 관계 menu와 tag의 관계 등 연관시키는 것이 어려웠지만, api를 명세를 작성하고 보니 훨씬 이해가 쉬웠다. api 명세 작성의 의의를 몸소 느꼈다. api 구현은 기존 과제를 리팩토링하여 만들었다. api가 좀 늘어나니 어디에 뭐가 있고 뭐가 어디에 있는지 왔다갔다하는 게 쉽지 않았다. 또한, 라우터를 구성할 때 어떻게 나누는 것이 효율적인가에 대한 의논이 많았다. tag는 menu에 속하는데 menu에 속한 tag를 추가 삭제할 때 라우팅을 따로 둘건지 어떤 라우팅에 속할 건지 등에 대한 의논이었다. admin과 일반 사용자를 나누는 것은 jwt에 admin의 여부를 추가하는 방식으로 쉽게 구현했다. 토큰에 admin이 true로 돼 있으면 admin 사용자가 이고 false면 일반 사용자가 되는 것이다. api를 구현하면서 각자의 로컬에서 하는게 아닌 vscode의 live share를 이용하였다. 서로 실시간으로 의견을 전달할 수 있고 코드가 꼬일 일이없는 좋은 점도 있었지만, 서로 작업 중에는 테스트 하기 어려웠다. 확인 없이 api만 늘어갔고 나중에 헬퍼로 오신 분이 오류를 수정해야 했다. 이와 같은 방식은 정말 지양해야 할 부분이다. 하나씩 확인하면서 늘려가는 게 오류를 찾기 더 쉽고 시간을 절약할 수 있다. 다음 과제부터는 테스트 환경 구성부터 시작해서 차츰 늘려가는 방식으로 해 봐야겠다.

끝마침

• 이번 과제에서는 기능별로 역할을 나누었다. 이러다보니 어떤 한 역할은 이전 역할의 결과를 기다려야 하는 상황이 생겼다. 예를 들어 데이터베이스는 api에서 어떤 값을 어떻게 보내주는 지 명확히 알지 못한 상태에서 개발을 했다. 또한, api는 데이터베이스가 구축되지 않아서 구동 확인을 기다려야 했다. 이와 같은 문제로 인해 다음 역할을 나눌 떄는 한 사이클이 되는 것을 기준으로 역할 분담을 해보는 것도 좋겠다는 의견을 나누었다. 기능별로 나눈 것은 한 기능에 대한 지식을 깊숙히 익힐순 있지만, 다른 역할에 대해서는 전혀 알 수가 없다. 모두가 부족한 기능에 대해서 알고 싶어하기 때문에 조금씩이라고 접근해 보는 것이 좋아 보인다. 많은 인원으로 과제를 수행하라고 한 것은 아마 서로 의견을 나누는 시간을 가지라는 의미인 것 같다. 하지만 기능별로 인원이 나뉘어 의견을 나눈 사람이 한정되었다. 사이클로 나누게 된다면 코드 충돌의 우려가 있지만, 여러 팀원들과 의견을 나눌거리가 많아 질 것이다. 다음 과제는 어떻게 될지 모르겠지만, 약한 부분을 도전해 봐야겠다.