프론트엔드 데브코스 5기 MIL 4편 - 노닥노닥

호벌·2024년 1월 23일
2

DevCourse

목록 보기
9/10

이번 회고에는 한달동안 진행한 프로젝트에 대한 전반적인 내용이 포함되어있으며,
프로젝트를 진행하는 과정에 따라 만족했던 부분, 부족했던 부분, 반성하는 부분으로 정리할 예정입니다.🙀

기간 : 12월22일 - 1월 17일
프로젝트 명 : 노닥노닥
프로젝트 설명 : 익명(별명) 체계의 투표서비스를 기반으로 한 SNS

기획과정

노아팀에서 기획은 다른 팀들에 비해 일주일정도 이르게 진행되었다. 이유는 팀원들이 프로젝트 경험은 있었지만, 명확한 프로젝트 설계와 진행방식을 경험해보지 못한 것 같았고 각자의 실력 및 경험에 확신이 없는 것 같았기 때문이다.

초기 기획은 컨벤션, 기술스택, 프로젝트 진행과정, 팀 문화 등등 최대한 볌용적인 내용을 기획했다. 모든게 프로젝트에서 실질적으로 반영이 될지에 대한 의문이 존재하긴 했지만, 각자 최선을 다해 맞출것이라고 예상하고 진행했다.

이후 기획과정에서는 다양한 검색 및 정보를 찾아가며 4기분들의 프로젝트를 찾아볼 수 있었고 api 명세서와 같은 내용을 찾아 여러가지 주제 및 커스텀 api 에 대한 내용을 많이 이야기했다.

실질적인 프로젝트 기간이 시작되고 나서는 대부분 구체적인 기능 명세와 프로젝트의 목적, 초기디자인을 설정하고 개인별 페이지를 분담했다.

Bad

프로젝트를 기획하는 과정에서 투표쳬계를 구현하기 위해서는 API를 커스텀해야했고 해당 과정에서 가장 많은 아이디어를 제시했기에 투표를 진행하는 페이지를 담당해서 구현하는 도중 기획에 대한 부족함이 생겼다.
해당 내용은 network탭에 누가 어디에 투표했는지에 대한 정보를 확인할 수 있다는 점이었다.
투표자를 익명으로 설정하기 위해서는 투표자 ID를 제거해야 하는데 이런 시스템으로 구현한다면 중복투표를 막을수가 없었다. 정리하자면 아래와 같다.

1. 익명체계를 포기하고 중복투표를 할 수 있도록 할 것인가.
2. 중복투표를 막고 익명체계 대신 별명의 체계로 프로젝트를 진행할 것인가.

두가지 의견에 대해 팀원들 및 멘토님과 의견을 나눴는데 2번으로 진행하는게 그래도 초기 기획과 비슷한 내용이라고 판단해 그렇게 진행하기로 했다.

해당 과정에서 명확한 기획에 대한 중요성을 깨닫게 되었고 , api 를 커스텀하는 과정에서 조금 더 구체적으로 했어야 한다는것을 알게되었다. 물론 백엔드 개발자들이 함께했다면 수정할 수 있는 내용이지만 정해져있는 api로 구현해내는것도 프론트엔드의 역량이라고 생각한다.

디자인

해당 단계부터는 팀원들의 업무분담이 시작되었다.
누군가는 기획 및 설계를 진행하고 누군가는 화면디자인을 누군가는 공용컴포넌트를 구현하고 누군가를 디자인시스템에 대해 설계하고 피드백했다. 빠른 진행을 위해 각자 할 수 있는 부분에 대한 분담을 진행했는데 결과적으로 봤을 때 타인이 진행한 업무는 내가 할 수 없는 영역이라는걸 깨닫게 되었다. 나는 디자인을 맡지않았기에 화면설계에서 어디에 어떤 컴포넌트가 추가되어야 명확한 화면이 완성되는지 모르는 사람이 된 것이다.

Bad

위에서 언급한 내용과 같이 프로젝트를 마무리하는 시점에서 나는 결국 디자인을 하지못하는 프론트엔드 개발자가 된 느낌이었다. 방학의 시점에서 개인적인 일이 이어져서 리팩토링이나 추가적인 학습을 할 순 없었지만 다음 프로젝트를 진행하기 이전에 코드를 뜯어보며 우리가 사용했던 디자인 체계나 디자인 시스템에 대해 사전학습을 진행해야 다음 프로젝트에서 응용할 수 있을것이라고 생각했다.

개발 및 배포

해당 과정에서 팀장으로서의 고민이 생겼다. 프로젝트의 프로세스를 진행하는데 있어서 배제해야할 부분과 진행시켜야 할 부분에 대해 명확한 해답이 없었다. 그래서 진행과정에서 차분하게 쌓아가기보다 완성된 상태에서 부서진 부분을 수리하자였다. 이러한 목표를 중점으로 뷰로직을 최대한 빨리 완성하고 기능로직을 이어붙이는 방식으로 구현하기 시작했다.

Good

장점은 프로젝트를 빠르게 끝냈고 기간적으로 여유로웠다는것이었다. 또한 기능적으로 이슈가 터진부분들을 많이 수정할 수 있었고 예상되는 문제들을 파악했다는점이다.

Bad

단점은 초기에 목표했던 코드퀄리티가 얼마나 나왔는지에 대한 의문이었다.
우리팀의 최종 목표는 퀄리티있는 코드상태였는데 추상화가 덜 된 느낌이었고 이러한 부분들에 만족하지 못해 추가적으로 리팩토링을 진행해야겠다는 점이었다.

1차 테스트 및 리팩토링

프로젝트를 시작하고 2주만에 초기 배포를 진행하였고 1차 테스팅을 진행할 수 있었다.
1차 테스팅은 팀원들끼리 QA를 진행했고 이슈가 터진 부분들을 분배해 추가적인 기능구현, 코드수정등을 진행했다.

Good

이부분은 굉장히 좋았다고 생각한다. 초기개발을 빠르게 진행했고 각자의 실력에 명확한 해답이 없다면 망가져있는 부분들을 수정하는것은 크게 어렵지 않다고 생각했기 때문이다.
팀원들이 초기 배포까지 많은 고생을 했고 빠르게 진행되어 감사한 부분들이 많았다.

2,3차 테스트

이후 대학생들을 대상으로 2차 QA , 데브코스 2,3,4,5기를 대상으로 3차 QA를 진행했다.
해당 과정에서 의도하지 않은 에러들을 많이 찾아냈고 , UX적인 부분들도 약점도 많이 찾아낼 수 있게 되었다. 해당 과정에서 의문점은 기획단계에서 얼만큼 더 촘촘하게 진행했어야 하는가?
공용컴포넌트 , 추상화 할 수 있는 로직등은 어떻게 더 세분화해서 나눴어야 하는가 등등이었다. 해당 과정에서 장단점을 나누기보단 반성을 많이했다.

반성

  1. 팀원들이 구현한 코드에 대한 명확한 해석이 가능한가.
  2. 공통적으로 사용되는 요소들 (hooks, components)을 얼만큼 이해하고 있는가
  3. 실질적인 추상화를 잘 진행했는가
  4. 각 페이지별 기능을 이해하고있는가
  5. 프로젝트의 개발 프로세스에서 나는 얼만큼 기여했는가

최종

프로젝트의 각 프로세스에서 느낀점, 반성할 부분, 잘 진행한 부분 등을 많이 작성했다.
마지막으로 하나의 프로젝트를 무사히 끝낸시점에서 느끼는 감정은 무사히 끝냈다 인 것 같다. 그리고 느끼는 감정은 나는 3차 프로젝트에서 어떤 포지션으로 어떻게 학습해야 나에게 도움이 될 것인가? 라는 생각이었다. 그래서 2차프로젝트과정에서 부족했던 부분을 체크하고 3차전에 남은 시간동안 부족했던 부분들을 체크하고 추가학습을 할 예정이다.

  1. 리덕스 사용 과정
  2. 디자인 학습
  3. 리액트를 잘 사용했는가
  4. 리렌더링 및 퍼포먼스

마지막으로 프로젝트 프로세스에서 주변에서 많은 도움을 줬다. 친구들도 응원을 많이해줬고 선생님도 프로젝트 기획단계 개발단계 테스팅 단계 모두에서 도움을 줬다. 내가 불안해하는 부분을 캐치하고 위로도 해줬고 이해하지 못하는 부분들을 이해할 수 있게도 많이 도와줬다 (감사함..)
마지막으로 노아팀 팀원들을 포함해서 (구) 멋쟁이들도 서로 많이 응원해줬고 데브코스 동료들이 많이 도움을 줬다 ☺️☺️☺️ 아주 감사합니다.

0개의 댓글