mrGreen

mr.Green 둘러보기

• 테마별로 식물 추천 리스트를 제공
• 관심 식물 즐겨찾기 (로그인 이후)
• 전체 식물 리스트 조회

진행 과정

2021.10.01 ~ 2021.10.14
// 실제 코드스테이츠 기간은 10.05~ 10.15였지만, 미리 팀원을 구성해 아이디어 구상 등 기획의 시간을 조금 더 가질 수 있었다 (그럼에도 불구하고 이틀이라는 기획시간은 너무나 짧았고, 미숙했다)
// 마지막에는 발표 준비, 타 그룹 발표 영상을 함께 보고 질의응답시간으로 마무리 했다

2주라는 짧은 시간을 크게 파트로 나눠보자면, 세 부분으로 나눌 수 있겠다

1. SR 기획 / 10.05 ~ 10.07
2. 코딩 / 1차 배포 10.07 ~ 10.10
3. 마무리 (프엔/백엔 연결 밑 에러 핸들링 + 배포) / 10.10 ~ 10.14

SR 기획에서는...

• 팀/ 팀장/ 팀원 포지션/ 팀규칙
• 프로젝트 범위 설정
• 프엔/ 백엔 세부 기획
• 위키 및 to do list 작성
• not to do list 점검
• 최종 기획 설문 제출

의 순서로 진행했고, 노션과 피그마를 주로 사용해서,
프로젝트의 핵심 기능 설정, 우리만의 BMR/Adv 의 기능별 우선순위 리스트 업, 와이어프레임& 프로토타입, ERD,API, flow-chart 등을 작성했다

이 외에도, 협업이 모두 처음이기에
깃헙의 사용과 커밋,PR 의 규칙, 코드의 컨벤션을 설정하고 지키는데 어려움이 많았다 (제시 된 내용을 그대로 가져와 그것을 익히는 데에도 시간이 걸렸고, 프로젝트를 진행 하면서 비로소 의미를 알게 되고 아직도 구멍이 있다는 게 사실에 가깝다)

실제 코딩을 시작했을 때는,

• 팀원 중 한 분이 디자이너 출신이고, 나도 그렇기에, 디자인에 치우쳐 기능에 대한 깊은 고민의 시간을 충분히 더 갖기 전에 바로 적당히 보기 좋은 프로토타입을 구성하는데 먼저 초점을 두고 진행하게 됐다
  -> 초기에 무언가 기획이 단단하지 못한 것 같고 어딘지 이 순서가 아닌듯한 느낌이 들었지만 나조차도 명확하게 어디가 깨름직한 것인지 설명할 수 없었기에, 기본 기능들을 먼저 코딩하고 css부분을 나중에 하는 것이 어떻겠냐고 제안했을 때, 나머지 팀 두분의 의견이 먼저 프로토타입과 같이 css로 구현을 맞춰놓고 기능을 나중에 구현하는 것이 편할 것 같다 해서 팀에 맞추어 이 방식으로 진행하게 됐다
  -> 돌아보면, 디자인적인 완성도 보다는 최저 기능이 충분한가를 다시한번 고민하는 기획의 시간이 있었다면 하는 점과, 기능이 잘 작동이 되도록 먼저 구현하고 디자인적 디테일을 마감했으면 어땠을까 하는 아쉬움이 있다
  + 하지만, 짧은 시간 안에 완벽히 동작하고 배포하는 것을 무조건 이뤄내겠다는 강력한 의지 & 걱정이 있었기에 빨리 코딩을 하고 싶었던 상황은 백퍼 공감,, 그래서 결국 예상치못한 사건이 있었지만, 배포까지 마무리 할 수 있었던 것도 결과를 놓고 보면 무시할 수 없는 사실이다.
  ++ 그래도 다음 프로젝트에는 기능 우선의 플로우로 해보고 싶은데, 팀원들과 어떻게 조율이 될지..

• 로그인 구현과 토큰
  가장 기본적이고 필수적인 기능 구현이라 생각되는데, 유효성 검사는 쉽게 구현할 수 있었지만, 토큰을 어떤 식으로 사용할 것인지 기준을 잡는 것이 어려웠다, 프엔 포지션으로 시작해서 갑자기 서버도 함께 만들 상황이 되어서, 서버와 클라이언트를 동시에 이리저리 만지면서 해나가다 보니 더 헷갈리기도 했지만, 오히려 공부가 된 것도 같고.

• 즐겨찾기와 상태 관리
  팀원 모두 리덕스가 아직 충분히 익숙한 스택이 아니라 느껴졌고, 우리 핵심기능이 그렇게 큰 규모도 아니기에 충분히 프롭스로도 관리할 수 있을 것이라 생각했다,(아마도 클린코드라면 더더욱 리액트 자체의 상태관리만으로 충분한 프로젝트라고는 생각된다)
  하지만 막상 기능 구현을 하면서, 새로고침을 한다거나, 서버에서 받아온 전체 식물 리스트를 뿌려주거나, 로그인한 상태값 기준으로 마이페이지의 즐겨찾기 목록등을 뿌려줄 때, 내 처음 생각처럼 간단하고 아름답게 되지 않는 것을 발견, 세션스토리지라는 개념을 검색해서 사용했지만, 이것이 맞는 방식인지, 더 나은 방법이 없는지는 계속 공부해봐야 할 점이다

마무리 (마무리라지만 서버 구현의 시작이었던)

• 전체적인 코드 정리의 부재
  여러명이 작업한 것을 합치는 방식으로 하고, 다듬는 시간까지는 가질 수 없었기에, 각 페이지별 컴포넌트들은 온갖 상태와 버튼 핸들러, 또 그안의 axios 요청 등 일관되지 않은 순서의 함수 나열로 쉽게 원하는 부분을 찾을 수 없고, 정리되지 못한 느낌이다.
• 혼자 토이 프로젝트로 간단한 게시글 작성 페이지의 서버를 만들어 본것 외에는 처음으로 서버를 만들어 보았고, 또 갑작스럽게 맞게 된터라 시간적인 압박이 있어 맞건 틀리건 우선은 동작이 우선! 이라는 식으로 만들었기에 아쉬움이 크다, 지식의 부족함도 많이 느꼈고, 프엔 파트에 비해 프엔팀원 어느누구도 이게 분명히 맞다!라고 확신을 줄만한 백엔드 지식이 있는 상황이 아니었기에, API대로는 아니지만 적절한 응답코드를 보내게끔 구현하는데 그쳤다

배포

• 백) EC2에 MySQL 설치해서 사용하기 -> 아 이래서 RDS 쓰나요..
• 클라이언트 빌드 과정 중 만난 에러 (캡쳐)

개선/추가하고 싶은 점

• 로그인 없이 직접 /mypage로 들어갔을 때 안내창
• 행운 페이지, 전체 반응형 적용
• 무한 스크롤 구현
• 테마를 컴포넌트 재사용을 통해 추가할 수 있도록 리팩토링하기
• 테마별로 추천한다는 것에 대한 UI/UX 관점의 고민
• 즐겨찾기 사용성 개선

느낀 점

• "기획의 중요성"
  기획에 적은 시간을 들인 것은 아니라 생각되는데, 아무래도 모두가 처음해보는 프로젝트이기에, 기획에 대한 개념 자체가 제대로 숙지되지 못한 것도 많았고, 나름대로는 구체적으로 짰다고 생각한 부분도 실제로 코딩을 해가면서 다시 손봐야했기에, 전체적인 태스크 분배, 일정관리가 제대로 안됐다고 볼 수 있다,
  실제로 코딩을 하면서도 어설프게, 성글게 짠 기획의 부분들이 들어날때마다, 그냥 무시하고 코딩을 막무가내로 할 수 없다는 것을 피부로 느꼈다, 협업이기에, 또 혼자하는 프로젝트라도, 방향성과 기준이라는 것이 참 중요하고, 이 중요성을 팀원 모두와 공유하는 것은 또 다른 얘기지만 역시 참 중요한 것 같다

• "태스크 설정과 분배의 어려움"
  처음 하는 프로젝트에서, 특정 기능을 구현하기까지 얼마의 시간이 걸릴지 가늠하고, 또 각각의 파트를 나눠서 팀원간에 분배하는 일은 정말 쉽지 않다, 그래서 회사에서는 따로 일정과 태스크 관리하는 포지션이 있는 거겠지..
  그래도 전체 기능을 목록화 한 뒤, 우리에게 주어진 전체 시간, 데드라인에 맞춰서 우선순위, 난이도별로 나누어 분해하는 식으로 어찌저찌 쪼개기는 했다
  실제로 그 작업이 계획한 시간에 맞춰 잘 이루어 졌는지는..음, 첫주까지는 얼추 맞았지만, 1차 배포 계획한 부분부터 밀리기 시작하면서, 점점 계획이고 시간이고, 일단 서버를 구현하는 것에 초점이 맞춰지면서 미친듯이 마감하기 바빴다, 다음에는 일정에 최대한 맞춰서, 에러핸들링, 리팩토링, 추가기능 등을 고려해볼 수 있는 시간이 있었으면 좋겠다

• 그럼에도 잘 마무리했다고 할 수 있는 건,
  필수 Bare Minimum Requirements 로 스스로 설정했던 기능들을 모두 구현했고, 비록 기획, 코드, 기능적으로 아쉬운 점은 셀 수도 없지만, 첫 프로젝트로 예외 상황을 이겨내며 최소한으로 정해둔 필수 기능들을 구현하고 배포했다는 것에 의의를 둔다

앞으로

• 어느새 4주 프로젝트 시작
• SR 기획 중
• 내일쯤이면 러프한 전체 일정을 잡을 듯

이것만은 꼭!

• 건강관리 _ 몰입과 휴식
• 프로젝트 중 필요한 학습
• 에러 기록