광필
- 협업 프로젝트를 진행하면서 혼자 개발할때와는 다른 생각들을 많이 하게 되었습니다. 특히 큰 그림위주로 생각하게 되었습니다 우선순위를 정할때도 다른 사람도 사용하는 기능을 우선적으로 개발하는식으로 초점을 맞췄고, 추후에 이게 어떻게 사용될지를 생각하면서 개발했습니다 기존에는 깊이 생각하지 않고 다시 수정하면 되니까 우선 즉각적으로 만들자는쪽이었지만, 큰 그림을 그리게 되니 더 신중해지고 좋은 퀄리티의 개발이 가능한것 같습니다
- 초기 eslint설정을 후에 많이 갈아엎게 되었는데, 팀원분들이 많이 도와주시고 테스트해주셔서 관련 설정에 대해 더 깊게 알게 되었습니다
- 로그인과 회원가입 페이지를 담당했지만 임시 로그인정도의 기능만 가능한 상태입니다 앞으로는 다른 분들이 사용할 수 있도록 회원가입 폼부터 임시로 완성하고, 로그인과 회원가입 모두 세부적인 사항을 수정할 생각입니다
민제
팀 단위로 프로젝트를 진행하는 것은 정말 다른 세계라는 것을 느끼게 되었습니다 🥲
- 건강 관리 및 시간 관리
가장 중요한 부분이라고 다시 느끼게 됩니다.. 초기 구상을 마치고 개발을 시작하기로 한 시점부터 주말부터 몸이 안좋아서 개발이 늦춰지게 되고, 이에 따라 계획에 차질이 생기니까 완성도가 많이 떨어지고 급급하게 개발하게 된 것 같습니다.
- 아이디어 구상, 기획 및 디자인
개발도 어려웠지만, 이 기간이 제일 어려웠던 것 같습니다. 어쩌면 제일 중요한 단계인 만큼 가장 많은 시간이 들고 결정하는데도 오래걸리는게 당연하지만 처음 시작하기전에 예상했던 것보다 시간도 많이 소비가 되는 것 같았습니다. “이쯤이면 되겠죠?”라는 말을 회의 할 때 마다 자주 했었던 것 같은데, 나중에 다시 다른 문제로 회의를 하는 것을 보니 회의가 얼마나 중요한지 새삼 느끼게 되었습니다.
- API 명세 분석
오프라인 회의에서 컨셉정도만 스케치해두고 개발을 시작했는데, 정확한 API 명세 분석이 없었다 보니 중간중간 회의가 생기고 용법에 따라 개발 내용을 수정하는 등 여러 이슈가 있었습니다. 인턴 근무 당시 API 명세를 꼼꼼히 살펴보고 질문해야 한다는 말이 얼핏 기억나는데 왜 그런지 알게된 것 같습니다.
- 퀄리티
팀 내부에서 정해둔 기간이 있는데, 해당 기간에 맞춰 어느정도 완성본을 만들어야 하다보니 맡은 부분에 대한 결과가 퀄리티가 많이 떨어지는 것 같습니다. 외적으로나 코드 내용으로나 많이 보완이 필요한 것 같습니다. 팀에 누가 되지 않도록 빠르게 보완할 수 있도록 해야겠습니다.
즐겨찾기를 설정한 유저에 따라 화면에 노출될 페이지를 상이하게 작성해야 하는데, 지금 작성한 코드내용은 목업느낌이 강합니다. 눈에 보이는 것을 먼저 만들어야겠다는 생각이 우선 들었는데, 지금 생각해보니 “이 부분을 처리하기 위해 어떤 작업이 필요합니다”와 같은 내용으로 팀원들과 공유하고 먼저 로직을 신경 썼으면 어땠을까 하는 아쉬움이 있습니다.
해당 내용을 오늘 스크럼에서 얘기를 나누었기 때문에 추후 개발에서 가장 신경써서 진행할 예정입니다.
- 생각을 말로 전하기
혼자 과제를 할 때는 머릿속의 생각을 따로 전달할 일이 없어 대충 적어놓고 기억해둔 편이었는데, 팀원들과 상의하기 위해 현재 갖고 있는 고민이 무엇인지, 이를 어떻게 정확하게 전달 할 수 있을지에 대한 고민이 많았던 것 같고, 팀원분들의 의견이나 질문을 전달 받을 때도 제대로 이해하고 있는지 여러번 생각하게 된 것 같습니다.
- 대면의 힘
오프라인에서 만나 진행했던 날이 개인적으로 가장 많은 내용을 공유하고 제일 진전이 있었던 날이 아니였나 생각됩니다.
상진
- 혼자 개발하는 것과 여럿이 개발하는 것은 매우 다른 문제라는 것을 느꼈습니다. 많은 기능들이 병렬적으로 개발되다보니 기능들 간의 의존성도 생각해야하고, 컴포넌트 간에 넘길 값들까지 약속해가면서 작업하는게 신선한 경험이었습니다. 개발하기에 앞서 긴 시간을 회의에 썼는데, 여러 사람이 공동으로 작업하기 위해 정해야할 약속이 많다 느껴졌습니다.
- 코딩 컨벤션: eslint, 컴포넌트 스타일링(css냐, styled-comopnent냐…)
- 깃 전략: 커밋 컨벤션, 브랜치 전략, 핫픽스시 쓸 브랜치, 팀원들의 코드 Pull하기
- 라이브러리/프레임워크: React, Vue, 디자인 프레임워크(Mui, Ant Design 등등)
- 코어타임 종료 시간 즈음(오후 7시) 다 같이 모여 그 날 개발을 하며 있었던 문제에 대해 토론을 하는게 큰 도움이 되었습니다. 단순히 문제를 해결할 방안을 찾는 것 뿐만 아니라, 소거법을 통해 버그가 있는 부분을 찾아내기 쉬워지거나, 문제를 해결하기 위한 새로운 아이디어를 떠올리거나, 문제를 우회하는 경우 등 다양한 해결책을 찾아냈습니다.
- Post(게시물) 객체에 content 프로퍼티를 설정할 수 없어 title에 Tag와 Content를 같이 담아 보내고있습니다. 이때 게시글 검색창에 “Title”, “Tag”,”Content”로 입력을 할 경우 모든 게시글이 검색되는 문제가 있었는데, 채우님께서 앞의 세 프로퍼티명을 dt, tg, dd로 바꿔 저장한 뒤 3글자 이상의 입력만 검색되게 하자 제안하셔서 문제를 해결할 수 있었습니다.
- Axios 를 통해 서버에서 데이터를 받아오는 과정에서 request는 되지만 response 값이 안 받아와지는 문제가 있었는데, 광필님과의 코드 대조를 통해 코드에는 이상이 없다는 것을 알았습니다. 소거법으로 코드를 없에고 나니 브라우저 문제 등으로 눈을 돌렸고, chrome 개발자 도구의 Network 설정을 통해 문제를 해결할 수 있었습니다. (해당 문제는 ERR_INTERNET_DISCONNECTED 으로 검색하면 비슷한 경우가 나옵니다)
- 현재 주소에 따라 하단 NavBar의 모습을 다르게 출력하는 중입니다. 처음에는 현재 위치를 전역스토어에 저장하고 읽어오게 하는걸로 가닥을 잡았었지만, 생각해보니 그냥 현재 주소를 읽어오면 해결되는 간단한 문제였습니다. 잠시 동안이지만 모두가 약간은 돌아가는 길을 고민한게 신기한 경험이었습니다.
- 개인적으로는 퀄리티나 코드의 깔끔함에 대해 많은 아쉬움이 남았습니다. 디자인 프레임워크(Mui)의 다양한 기능을 접해보고 나서 코드를 크게 한번 갈아엎었습니다. 일정이 좀 촉박했지만 반나절 정도의 짬을 내서 Mui에서 공식적으로 제공하는 Form subComponent들을 살펴봤으면 게시물 작성 페이지의 질이 훨씬 더 올라갔을 것 같습니다. 결과적으로 기능에는 하등 달라진게 없어서 약간 슬프기도 했습니다. 앞으로의 개발 계획은 다음과 같습니다.
- focusOut 이벤트를 통해 포스트 작성 페이지의 각 Input이 처음부터 Error를 표시하는 현상 수정
- 임시저장, 리셋 기능 구현
- Mui의 Chip 컴포넌트를 활용한 Tag 컴포넌트 구성 및 배포
동언
- 개인프로젝트가 아닌 팀단위 프로젝트를 진행해보니 혼자서 개발을 진행할때 와는 많은 차이가 있었습니다. eslint rule 부터 시작해서 사용 라이브러리, node 버전, 함수네이밍과 디렉토리 구조 등 많은 부분을 협의해서 일관적인 형태를 유지하도록 약속하고 문서화한 후에 프로젝트를 시작했었습니다. 실제로 현업에서도 적용되는 방식이어서 마치 실무를 보는 듯한 경험을 한것 같아 많이 도움 된것 같습니다.
- 네이밍컨벤션과 git commmit 컨벤션 저는 그동안 개인프로젝트를 진행할때 네이밍 컨벤션과 커밋컨벤션을 따로 정하지않고 야생의 날것 그대로 프리스타일로 작성을 했었습니다. 이번에 팀원들 덕분에 이런 컨벤션이 있다는것을 알게 되었고 처음으로 적용해봤는데 많이 깔끔해져서 좋았습니다.
- 팀단위 프로젝트를 진행하면서 많은 부분을 배웠지만 가장 많이 도움된 부분은 아무래도 스크럼을 통해 어려움을 공유하고 서로간에 도움을 주고 받는 부분이 아니었나 싶습니다. 혼자 고민했다면 더 많은 시간이 지체 되었거나 해결하지 못하는 문제가 될수도 있는 반면 비슷한 작업을 진행중인 팀원들에게 빠르게 피드백을 받을수 있었던 부분이 가장 좋았습니다.
- 현재 채널페이지를 80% 정도 완성된 상황입니다. 빠르게 채널페이지를 완성한후 post detail 페이지를 진행할 생각입니다.
채우
프레임워크 사용
앞서 했던 노션 클로닝 프로젝트의 경우 여러가지 과제를 한 다음에 진행한 프로젝트였다. 그래서 멘토과 팀원간에 리뷰를 통해서 어떤 방식이 더 좋은지 고민하고 생각할 시간이 많았다. 하지만 프레임워크 부분에서는 과제도 Vue에 대해서만 진행되었고 당시 몸 상태가 좋지 않아 앞서 말한 과정들이 많이 모자랐던 것 같다. 바닐라 JS보다 프레임워크가 편한 것은 많지만 잘 쓰는 것과 편한 것은 다르기 때문에 이를 고민하면서 생각보다 개발 진행 속도가 나지 않아 힘들었다.
문서와 친해지자
mui 디자인 프레임워크를 사용하면서 컴포넌트를 사용하는 것에 여러 시행착오가 많았다. 라이브러리나 프레임워크 관련 문서를 읽는 스킬을 조금 더 갈고 닦을 필요가 있다.
팀과의 협업
팀과 하는 커다란 프로젝트라서 지금까지 했던 과제나 프로젝트와는 느낌이 아주 달랐다. 분량도 많고 이를 팀과 나누어서 진행해야 했기 때문에 프로젝트의 계획과 역할 분담, 개발 프로세스를 조율하는데 시간이 많이 소요됐다.
디테일?
이번 프로젝트에 있어서 중요한 점은
협업 과 정해진 기한 내에 두 가지라고 생각한다. 정해진 기간 내에 개발을 완료해야 한다는 것이 개발을 하고 조율을 하면서 더 많은 생각을 하게 했다. 너무 세세한 내용까지 고려하는 성격 때문에 스크럼을 하면서 시간을 더 많이 쓰게 되고, 그 결과 개발 진행 속도에 악영향을 준 것 같았다. 물론 수정하고 개선하면 좋겠지만 정해진 기간이 있는 한 기본적인 기능이 우선 하는 것이 당연하기 때문에 일정에 따라서, 진행 정도에 따라서 고려할 부분을 유연하게 적용하는 것이 중요하다는 것을 경험을 통해서 느낄 수 있었다.
소프트 스킬
스크럼 이후에 나를 되돌아보면, 어떤 주장을 하는데 있어서 “내 생각이 맞고 너는 틀렸어”같은 느낌을 주게 말했던 적이 많은 것 같다. 좀 더 소프트 스킬을 개발하는 노력이 필요하다고 느낀다.
개발과 관련해서
search page 를 개발하는 과정에서 하나의 페이지를 구성하는 여러 컴포넌트를 어떻게 나누고 어떻게 합쳐야 하는가 아직도 생각이 많다. 탑-다운 방식으로 프로젝트를 진행하다 보니 컴포넌트의 재사용, 컴포넌트 분리 등 설계 과정이 충분하지 않았다. 프로젝트 기한 내에 기본 요구 사항을 수행하기 위해서 완벽하게 설계하기는 힘들겠지만 내 나름대로 개선한 뒤 멘토님이나 다른 사람들에게 피드백을 받고 싶다.아쉬운 점
이후 최종 프로젝트에서도 유용할 수 있는 경험을 이번 프로젝트에서 하지 못한 것.
- 협업에 있어서 도움이 되는 것들이 많았는데 프로젝트 진행이 더뎌져서 포기했다.
- github action
- gitflow
- jest
- git 전략 gitflow를 사용하지 않았다고 해도 브랜치 전략을 꼼꼼하게 설계하지 않은 점이 아쉽다. 그리고 github issue와 label의 경우도 특강에서 설명해주셨는데 이번 프로젝트에 적용하지 못했다.