처음 써보는 회고록👍🏻 가봤슈 프로젝트

팀원들과 함께 진행한 프로젝트의 이름은 가봤슈! 입니다. 🤗

어떻게 프로젝트를 진행하였는지, 어떠한 점을 고쳤으면 좋았을 지 다시 뒤돌아보면서 회고록을 작성해보았어요.

 

처음으로 작성해보는 회고록이라 기술적인 내용보다는 프로젝트를 진행한 순서와 느낀점을 중심으로 써보았습니다.

(추가되었으면 하는 내용이나 수정하면 좋을거 같은 내용이 있다면 꼭!꼭! 댓글 부탁드려요.😌)

그럼 시작👉🏻👉🏻

 

1. 아이디어 정하기

프로젝트 특성상 사용할 수 있는 API가 정해져 있어, 게시글 형태의 아이디어를 팀원들끼리 자유롭게 이야기해보고 그 중에서 하나를 선택하는 방법으로 정해보았습니다.

 

👇🏻 그 때 나온 아이디어는 총 3개!

이 중에서 여행 일정 공유 서비스를 구현해보기로 결정하였습니다.🔥 ( 제가 낸 아이디어였다는건 안 비밀😌 )

이렇게 아이디어를 정하는 와중에 나온 것이 바로 프로젝트 이름 가봤슈였습니다. 😍👍🏻

 

저희 팀에서는 기획 과정에서 주로 카카오톡 투표를 사용해서 결정을 내렸는데,

아이디어와 프로젝트 이름 모두 압도적으로 하나가 선택되어 어려움 없이 결정할 수 있었어요. 😆

 

2. 사용 기술 정하기

이제 아이디어를 정했으니, 어떤 기술을 사용해서 구현할 지 함께 정해보기로 하였습니다. 🤨

아이디어를 정할 때와 마찬가지로, 노션 페이지에 사용하고 싶은 기술을들 쫙 적어보기로 했어요.

 

👇🏻 팀원들과 함께 작성한 기술 리스트(아직 후보)

정말 많은 후보 기술들이 나왔지만, 어느 것이 좋을지 판단하기 어려웠었습니다. 😭

그 때 많은 도움을 주신 분이 저희 팀의 멘토님이셨어요.😍

 

프로젝트를 본격적으로 시작하기 전에 있었던 오프라인 모임에서 멘토님과 함께 어떤 기술이

현업에서 실제로 사용되고 짧은 프로젝트 기간 내에 적절히 사용할 수 있는지 이야기를 나눌 수 있었습니다.😊👏🏻👏🏻

 

👇🏻 멘토님과 만나기 전에 준비한 기술리스트 그래프와 질문사항

 

3. 규칙(Rule) 정하기

저희 팀은 저 포함 총 5명으로, 멘토님 왈 한 팀의 이렇게 많은 프론트엔드 개발자가 있는 경우는 별로 없다 하시더라고요.ㅎㅎ😭

그래서 프로젝트를 시작하기 전에 여러 규칙(Rule)을 먼저 정하고 가기로 해보았어요. 😆

 

정한 규칙은

• 스크럼 시간
• Github에서의 commit 메세지 / branch 구조 / 코드 리뷰 진행 방식
• Convention
• 파일 구조

이렇게 4가지 규칙을 기본으로 하여 각자 개발을 진행하였습니다.

 

(1) 스크럼 시간

👇🏻 프로젝트 시작 전 진행했던 회의록 중

프로젝트에서 팀원들과 함께 매일 아침에 현재 하고 있는 일과 오늘 할 일, 문제점 등을 공유하고

3-4일에 한번씩 지금까지의 진행상황과 개발해야 하는 기능에는 어떠한 것이 남아있는지 정리하는 시간을 가졌습니다.

 

이를 통해 자신의 업무가 빨리 끝났을 때 다음에 무엇을 해야하는지 빠르게 파악할 수 있었고,

막히는 부분이 있다면 팀원들에게 공유하고 도움을 받아 개발을 진행할 수 있었습니다. 😚👏🏻👏🏻

 

(2) branch 구조

저희 팀에서는 먼저 기본이 되는 component들을 만들고,

이후 만들어둔 component들을 조립하여 기능을 구현하는 순으로 진행하였습니다. 🔥

 

따라서, 기본 component들을 만드는 branch(dev_baseComponent)와 기능을 구현하는 branch(feat_[featureName])를 별도로 두어 개발을 진행하였고,

개발 사항은 dev branch에 push하여 테스트를 진행하였습니다.

 

main은 배포를 위한 branch로 dev에서 테스트가 완료되었을 때, main으로 push하여 배포하도록 하였습니다.📌

(branch 구조 기획은 좋았지만, 실제 개발할 때 일어난 일에 대해서는 이후에🤗 ㅎㅎ😭)

 

(3) Convention

여러 개발자가 하나의 프로그램을 만들기 때문에, 코드 작성 규칙도 미리 정하고 개발을 시작하여야 코드의 일관성이 유지될 것이라고 팀원 모두의 의견이 일치하여 어떤 Convention을 사용할지도 정해보았습니다.

 

👇🏻 그리고 나온 결론, 저희 프로젝트 진행에 큰 벽이 되어버린🧅🧅

airbnb

 

처음에는 airbnb의 설정을 그대로 따라왔지만,

프로젝트를 진행하면서 마주한 엄청난 빨간줄과 어쩔 수 없이 그대로 사용되어야 하는 코드에 대해서

그 때 그 때 제한사항을 제거하면서 진행해 나갔습니다.

 

👇🏻 실제 eslint 코드

 

4. 화면 기획하기

다음으로는 정해진 아이디어를 바탕으로 각 화면과 제공되는 기능에 대해 정해보는 시간을 가졌습니다. 🤗

크게 > 작게 > 세부 내용 순으로 하나씩 단계적으로 정해나가보았어요.

 

크게는 바로 페이지! 어떤 페이지들이 나올 수 있는지 나누어 보고

이후에 작게작게 각 페이지에서 제공되는 기능과 세부적으로 해당 기능을 어떤 식으로 제공할 것인지 UI에 대해 논의해보았습니다. 🖍

이렇게 정해진 기획 내용들을 바탕으로 이후 개발을 진행할 때 참고할 수 있도록 화면기획서를 만들었어요! 😆

( 이전 회사에서 열심히 작성했던 기획서가 이럴 때 빛을 발하는 구남!! )

👇🏻 화면 기획서 중, post list page

🌹 UI 디자인은 figma에서 진행했어요. 😀

 

이제 모든 준비가 되었습니다. 남은건 열심히 개발을 할 뿐🔥🔥🔥

 

5. 개발을 진행하면서...

(1) 진행상황 공유

저는 팀 프로젝트를 진행하면서, 팀원들과 함께 현재 무엇을 하고 있는지(Doing) / 지금까지 무엇을 했는지(Done) / 앞으로 어떤 일이 남았는지(ToDo) 투명하게 공유하는 것 또한 중요하다고 생각합니다. (약간 신뢰와 밸런스의 측면에서(?)🧐)

 

때문에 프로젝트 진행 전, 아래와 같이 각 팀원별 [시작전/진행중/완료] 사항을 공유할 수 있는 노션 페이지를 만들어 공유하였습니다.

( jira를 사용해보고 싶기도 하였지만, 어떻게 쓰는지 배우는데 시간이 걸려 이번 프로젝트에서는 노션을 사용하였습니다. 😭 다음에는 꼭 사용해보리다🔥 )

이 내용들을 바탕으로 다른 팀원분들은 얼마큼 일을 진행하셨는지 파악할 수 있고,

코드에서 어떠한 문제가 발생하였을 때 어느 분에게 물어보면 좋을지도 알 수 있었습니다. 🤗

 

(2) Git 충돌의 향연

지금까지 토이프로젝트는 많이 해보았지만, 여러 개발자들과 하나의 프로젝트에서 개발해보는 것은 처음이었습니다. (두둥!😐)

그렇기에 지금까지 사용해본 git 명령어는 add / commit / push 뿐....

 

이번에 처음으로 rebase라는 것을 해보기 시작하면서 많은 문제점에 부딪히게 되었습니다.

👇🏻 첫 PR에 있는 수많은 rebase 충돌 수정 commit🤨🤨

 

rebase에 대한 정확한 이해 없이 인터넷에 있는 명령어를 그대로 따라했었고,

이러한 문제가 발생하고나서야 rebase에 대해 찾아보기 시작하였습니다.😭

🌹 앞으로는 기술에 대한 충분한 공부와 이해가 있은 후에 사용하는 습관을 기르자!

👉🏻 rebase 참고했던 블로그 (Click here!!! )

 

이후에는 rebase를 하는 도중 conflict가 발생하면 rebase가 중단되기 때문에 충돌난 부분을 수정하여 commit해주고 rebase --continue 명령어를 통해  중단된 rebase를 계속 진행시켜 주었습니다.

이를 반복적으로 수행하여 rebase가 모두 완료되어 conflict에 의해 생성된 no-branch가 없어지고 정상적으로 branch에 rebase 코드가 추가되는 것을 알게 되었습니다.

Git에 대해 추가적인 공부가 필요함을 절실히 느낄 수 있었던 프로젝트였습니다.😭 (// TODO)

 

(3) 커뮤니케이션

앞에서도 말했듯이 저희 팀은 커뮤니티와 의사 결정을 위해 카카오톡을 적극 활용하였습니다. 😊

• 일정 공유
• 문제점 공유 및 함께 원인과 해결방법 찾아보기
• 의견 제시 및 의사 결정

등등의 여러 사안에 대해서 바로바로 의견을 나누고 피드백을 제시하여 코드에 반영할 수 있었습니다.

( 얼마나 열정적이었는지, 자고 일어나면 쌓인 메세지가 많아 다시 읽어보기 힘들었다. 휴 )

 

사실 이 부분에 대해서는 이후의 프로젝트에서 고치고 싶은 점이 생겼습니다.

🌹 이슈별로 의견을 공유할 수 있는 git의 이슈나 slack의 채널을 이용해보자.

멘토님과 함께 최종 회고를 진행하던 중, 멘토님께서 카카오톡은 하나의 대화 페이지만 볼 수 있는 한계에 의해

그 때 그 때 메세지를 확인하지 않으면 자신과 관련있는 이슈의 내용을 확인하지 못할 수 있을 뿐더러

하나의 이슈에 대해 깊게 의논할 수 없다는 이야기를 해주셨습니다.

 

그 이야기를 듣고 프로젝트를 뒤돌아보니 확실히 다른 팀원들이 말했었던 내용을 전부 파악하지 못하고 있어

다시 이야기가 진행되는 일이 없지 않아 있었던 것을 떠올리게 되었습니다. 😭

 

따라서 다음에 팀 프로젝트를 진행할 때는 이런 부분을 고쳐 이슈별로 의견을 나눠서 관리할 수 있도록

다른 툴을 사용해야 겠습니다. 😌📌📌

 

6. 프로젝트를 끝내고...

2주일에 길고도 짧았던 프로젝트가 완료되었습니다. 🤗

학교 과제도 아닌, 공모전도 아닌 팀 프로젝트로서 마지막은 팀원 모두가 같이 참여하면 좋을거 같아

토크쇼 형식의 발표를 하자고 건의해보았고 팀원분들이 승낙하고 도와주셔서 만족스러운 결과 영상은 만들 수 있었습니다.👏🏻👏🏻👏🏻👏🏻

오랜만에 여러 개발자들과 함께 진행했던 프로젝트는 역시 재밌었습니다. 😆👍🏻 

실제로 개발자로서 일을 하게되면 기술적인 스트레스보다 인간관계에서 나오는 스트레스가 더 불편했었는데,

그러한 일 하나없이 처음부터 끝까지 완만하게 진행되었던 프로젝트였고,

팀원분들이 어느 일이든지 열정적으로 도움을 주시고 참여해주신 덕분이라고 생각해요. 😌

 

(1) 아쉬운 점

📌 짧았던 프로젝트 기간

2주안에 아이디어를 기획하고 화면을 정의한 이후 API까지 연동하여 배포까지 완료하기 위해, 빠듯하게 개발이 진행되었다는 점이 많이 아쉬웠습니다. 최대한 기획 사항에 맞게 개발하기 위해 여러 기능을 구현해야 했고 때문에 하나의 기능을 구현할 때 어떻게 구현할 것인지, 어떻게 구현해야 좀 더 깔끔하고 깨끗하게 작성할 수 있는지 고민하는 시간이 부족했다고 생각합니다. 이 부분에 대해서는 다시 한번 코드 리팩토링을 하면서 복습하고 짧은 시간에 적절하게 코드를 작성하는 능력을 기르면서 개선해나가고자 합니다.🔥

📌 부족한 코드 리뷰

위의 이유와 동일하게 제가 담당한 업무를 완료하기 위해 다른 분들이 올려주신 PR을 제대로 확인해보지 않았고, 다른 분들 또한 그랬다고 생각합니다.

이 떼문인지 모든 코드가 합쳐지는 dev brach에서 테스트를 해볼 때 여러 이슈가 발생하였고 원인을 파악하고 해결하는데 또 시간이 소비되게 되었습니다. 😭

하지만 이 덕분에 코드리뷰와 중복 테스트의 중요성에 대해 알게 되었고, 앞으로의 프로젝트에서는 코드리뷰를 통해 다른 팀원분들과 코드를 공유하고 이슈를 미리 찾아 개선할 수 있도록 할 것입니다. 😠

 

7. 앞으로

사실 이번 프로젝트는 백엔드 단이 프로그래머스에서 제공되었기 때문에, 저희 서비스에 맞게 커스터마이징된 백엔드를 다시 구축하고자 하였습니다.🌹

 

다행히 이전에 mysql과 node js를 이용해 간단한 백엔드를 구축해본 경험이 있기 때문에

빠르게 기존에 제공되었던 API와 동일한 저희만의 서버를 만들 수 있었습니다. 🤗

( TMI 아직은 제 컴퓨터에서만 돌아가서 제가 일어나 있을 때에만 작동된다는 사실.. )

 

이제 백엔드도 만들어졌겠다. 이에 맞추어 프론트엔드단도 API 연동 부분을 수정하고, 기능적인 면에서 리팩토링을 계속해나갈 예정입니다.😆👍🏻

 

👇🏻 뭔가 복잡한 DB 테이블 관계..😐

 

8. 추가적으로

제 손가락 실력 조금만 보고 가세요.😆

(1) 가봤슈 로고

-> 여행 일정 공유 서비스여서 지도 어플리케이션에서 나오는 화살표를 참고하여 디자인해보았어요.

(2) 404 페이지

-> 마찬가지로 여행 일정 공유 서비스여서 지도를 보고 길을 잃은 것으로 404 페이지를 디자인 해보았습니다!