Section.1 회고

Day.1 첫시작 팀 프로젝트에 대한 설렘과 기대

 

처음으로 시작하는 팀 프로젝트가 시작하는 날 재밌을것 같다는 설렘과 기대가 있었다.

 

팀별로 정해진 주제를 가지고 실습을 하는 부분에서 개인적으로 쇼핑몰을 하고 싶었지만, 6조를 시작으로 LMS가 정해져있어 6조인 우린 LMS를 가지고 실습을 시작하게 됐다

 

LMS에 대해 주어진 요구 명세를 바탕으로 1. 시나리오, 2. 데이터 테이블, 3. ERD, 4. API 문서제작 순으로 진행됐다.

 

요구 명세는 아래와 같다.

 

LMS(학습 관리 시스템)

• 사용자는 모든 수업을 조회할 수 있다
• 사용자는 특정 분류의 수업을 조회할 수 있다(예: 강의자/ 수업명 / 수업코드 등)
• 사용자는 수업을 수강신청 할 수 있다
• 사용자는 모든 수강중인 수업을 조회할 수 있다
• 사용자는 이메일 정보와 같은 개인정보를 변경할 수 있다
• 사용자의 타입이 강의자일 경우 새로운 수업을 생성할 수 있다
• 사용자는 수업에 대한 수강신청을 취소 할 수 있다

처음 시나리오로 유저, 강의, 수강신청 세 가지로 리소스를 나누어 짜보았다

ex) 김재환은 컴퓨터공학을 수강한다.

 

이를 바탕으로 데이터 테이블를 짜보았다.

 

USER

id

name

email

REGISTRATION

registration_id

student_id

course_id

COURSE

id

course_name

course_type

위에 나와있는 세 개의 테이블은 3개의 리소스에 어떤것이 포함되어 있어야 할까를 명세를 참고해 초반에 생각한 모델링이다. 명세를 좀 더 자세히 분석 했을 때, 단순히 User 테이블 하나로 두는 것보다는 학사 정보 시스템 특성 상, 강사 정보가 다수의 수강생 정보와 같은 User Resource Pool 에 존재할 시 강사 정보 검색에 비효율 존재, 새로운 Resource Table로 나누어 검색하는 것이 성능적으로 우수하다고 판단으로 이분할을 시도했고 이분할 후 ERD 진행은 아래와 같다.

 

다음은 LMS 요구 명세을 가이드 삼아 API 가이드 라인을 작성해봤다.

• API 작성 Guide 참조
  • 사용자는 모든 수업을 조회할 수 있다. (R) : 사용자 (Student,Instructor)는 Get Method를 통해 수업(Course) Data를 불러올 수 있다.
  • 사용자는 특정 분류의 수업을 조회할 수 있다. (R) *강의자, 수업명, 수업분류로 조회. : 사용자 (Student, Instructor)는 GET Method로 특정 값(강의자, 수업명, 수업분류)을 기준으로 해당 값과 연관된 Data를 불러올 수 있다.
  • 사용자는 수업을 수강신청할 수 있다. (C) : 사용자 (Student) 는 Post Method로 Registration에 Data를 생성할 수 있다.
  • 사용자는 모든 수강중인 수업을 조회할 수 있다. (R) : 사용자 (Student)는 GET Method로 본인이 수강한 수업 정보를 조회할 수 있다.(/student_id , /registration)
  • 사용자의 타입이 강의자일 경우 새로운 수업을 생성할 수 있다. (C) : 사용자 (Instructor)는 Post Method로 Course Table에 Data를 생성할 수 있다.
  • 사용자의 타입이 강의자일 경우 수업의 정보를 변경할 수 있다. (U) : 사용자 (Instructor)는 Put Method로 본인이 생성한 수업 내용을 변경할 수 있다.
  • 사용자는 수업에 대한 수강신청을 취소할 수 있다. (D) : 사용자 (Student)는 Delete Method로 본인이 신청한 수업을 취소할 수 있다.

다음은 API 문서로 초기 모델과 구현하면서 수정된 최종 API 문서이다.

Day1 초기모델

 

Day2, 3 수정 최종 모델

초기 모델에서 없었던 token get이나 put이 patch로 바뀌는 등 변경사항이 많이 생겼다.

 

첫날 시작할 때는 설렘과 기대가 가득했지만, 첫 날부터 비전공자로써 부족함을 많이 느꼈다. 우리팀은 주로 팀장인 주형님이 네비게이터 역할를 수행하면서 진행이 되었고 첫날 팀원으로써 수행한 것은 시나리오, 데이터테이블 의견, api문서 작성 도움 정도였다. 다른 팀원들이 주고받는 의견을 들으면서 내가 아직 모르는 용어가 많구나 라는걸 느끼며 좀 더 공부 시간을 늘려야겠다고 생각했다. 훌륭한 팀장님과 팀원분들 덕분에 매니저님께도 별 다른 말 없이 통과되어 첫날은 일찍 마쳤고 추가적으로 오늘 어떤것을 했고 어떻게 해야할지에 대해 짧은 지식으로나마 생각해봤다.

 

Day.2 나는 누구 여긴 어디? 이어지는 절망

 

실습 두번째 날이 시작되고 나는 누구 여긴 어디라는 생각이 하루종일 들었던것 같다.

처음 database을 준비하고 fastify 프로젝트 생성 그리고 테이블과 데이터 준비, was와 database 연결 과정을 시도해봤다.

하지만 연결 부분에서 mutipass을 사용하는 사람으로 어려움을 느끼게 됐고 왜 그런까에 대해 생각하며 헤매게 되었다. 나중에 알고보니 localhost 대신 inet 주소를 넣어야 하는데 기존 inet이 변경되어 새로운 inet으로 넣어야했다는걸 알게 되었다. 

 

이후 계속 진행중 팀장님이 어차피 데이터베이스와 서버는 한사람이 해야된다고 해서 팀장님이 만든걸 github을 통해 pull 하고 진행하게 되었다.

 

유어클래스에 있던 내용을 공부하고 남은시간에 유어클래스 말고 다른공부를 해서 그런지... 어떤코드를 작성해야하는지 너무나 막막했다. 팀장님이 주도적으로 자기가 get부분 할테니 authorization에 대한 부분과 delete 부분 해달라고 요청하셔서 그 부분에 집중하기로 했다.

 

처음 authorization에 초점을 맞춰 조사를 했을 때 fastify-jwt에 대해 알게 됐고 이걸 이용해 토큰을 얻고 인증해보자 호기롭게 다다갔지만, 코린이인 나는 모니터 너머에 산이 있는거 마냥 멍 하며 여긴 어디 나는 누구를 시전하게 되었다. 추후 팀장님이 jwt을 보고 한시간만에 구현했다고 한다.. ㅜㅜ 

 

대신 delete부분에서는 어느정도 코딩을 짜보았다 몇시간의 산물...

위에 코드는 다음 설명과 같다.

 

처음 제가 짠 코드에서는 명세와는 다르게 body로 요청한게 아니라 params로 요청한거여서 수정해야 됬었다. 이후 팀원인 도현님이 params을 body요청으로 바꾸어 같이 delete부분을 완성하게 되었다.

 

팀장님이 거의다 해주셔서 너무나 감사했지만, 실습시간이 너무 짧아 중간중간 공유받지 못한 부분은 너무 아쉽다고 느껴졌다. 

 

후기

 

호기롭게 시작했던 첫 실습 설렘과 기대가 충만했었지만 시간이 하루 이틀 지나면서, 몸도 피곤하고 절망감이 많이 들었던것 같다. 물론 어느정도 도움이 된 부분이 조금이나마 있다고 생각하지만 팀장님이 한거에 비해서는 조족지혈이었고 팀장님이 헤쳐나가는 모습을 보면서 어떻게 저부분에서 저런 생각을 가지고 접근해 해결해나가시는거지  생각하며 존경하게 되었다. 

3일차 때 팀장님이 자기가 어떻게 접근했고 어떻게 코드가 이루어지는지 친절히 설명해주셨는데 이해는 가지만 온전히 내것이 되었다는 생각은 들지 않아서, 추후 혼자 작게 연습해보려고 한다.

 

앞으로 남은 실습 일정에 민폐가 되지 않게 더 노력해야겠다고 생각한다.