🍉 Final Project 최종 배포링크
배포링크 : 📎 https://triplus.world
발표 : 📎 Triplus 프로젝트 발표
🍉 회고
1. 팀
1. 😉 커뮤니케이션은 많이 할 수록 좋다 : 1일 2머지
2주차 프로젝트와 같이 하루에 2번 머지를 진행하였다. 이번에 추가한 사항은 각자의 코드를 리뷰하는 시간을 가진 것이다. 자신이 어떤 코드를 작성했고, 어떤 에러를 만나서, 어떻게 해결했는지를 간단하게 서로 리뷰하여 자신의 코드뿐만이 아니라 팀원들의 코드도 같이 이해하며 프로젝트를 진행할 수 있었다.
2. 😉 효율적인 소통을 위한 방법 : 노션 활용
이슈 공유를 위해 노션을 활용했다. 1차 구현이 끝나고 에러 핸들링과 코드 피드백을 본격적으로 진행했을 때, 서로에게 전달해야 할 사항이 많았고, 그러다 보니 줌으로 하나하나 전달하거나, 디스코드로 한명한명에게 메시지로 보내는 것이 비효율적이었다. 또한 서로에 대한 코드를 피드백하고 수정 요청하는 과정에서 가끔 부정적으로 받아들여지기도 하여, 피드백하기가 점차 조심스러워지기도 했었다.
이를 개선하고자 노션에 '요청사항' 페이지를 생성하였다. 해당 팀원에게 요청 이슈를 작성하여 공유함으로써 각각의 팀원에게 요청한 사항과 요청받은 사항을 한번에 파악할 수 있었다. 또한 요청사항 혹은 피드백을 말이 아닌 정돈된 단어와 문장으로 전달함으로써 자칫 오해가 생길 수 있는 부분을 방지할 수도 있었던 것 같다.
3. 😉 의견 충돌과 팀 규칙의 중요성 : 팀 규칙
2주차 프로젝트를 진행했을 때 어떤 방식으로 구현할지 등과 같은 정답없는 사소한 논쟁이 있었다. 이를 계기로 4주차를 시작할 때에는 팀 룰을 아래와 같이 구체적으로 정하였다.
📎 깃헙 Wiki (Team-rules : 2.커뮤니케이션, 생활) 링크
이번 4주차를 진행하면서도 의견충돌이 종종 있었다. 어떤 기능을 구현할 것인지, 정말 필요한 기능인지 등등에 대한 의견 충돌이 있었고, 자신의 의견에 대한 확신이 있을 때에는 이런 충돌을 해결하기는 쉽지 않았다. 그래도 위와 같은 팀 룰을 정해둔 덕분에 의견 충돌로 인한 갈등으로 이어지지 않고, 해당 사항에 대한 결정이 지체되지 않아 정해진 기간 안에 프로젝트를 마무리할 수 있었다.
이 규칙이 어느 조직에서나 유효한 규칙은 아닐 것이다. 하지만, 팀원 모두가 비슷한 지식과 짧은 개발 경험을 가지고 있었기 때문에, 해당 룰은 우리가 프로젝트를 진행하는데 적합한 룰이었던 것 같다.
🥺 문제점 : 건강관리
건강관리이다. 4주 프로젝트동안 팀원 모두가 새벽까지 작업을 하며, 최대한 프로젝트의 완성도를 높이기 위해 노력하였다. 하지만, 장기적으로 보았을 때 이런 방식은 건강에 매우 좋지 않을 것이다. 실제로 새벽까지 코드작성을 하며 피로가 누적된 탓인지, 점점 아침회의에 지각하는 팀원들이 많아졌었다. 때문에, 작업시간과 휴식시간을 잘 조율할 수 있도록 시간 관리할 수 있는 능력도 함양하는 것이 필요한 것 같다.
2. 개인
😉 나의 장점 : 꼼꼼한 구현
이번 프로젝트에서 내가 중점으로 두었던 것은 꼼꼼한 구현이었다. UI 구현 뿐아니라, 에러 핸들링, 코드의 가독성 등을 고려하며 코드를 작성했다.
1차 프로젝트 때 아쉬웠던 점들을 최대한 고려하며 코드를 작성하였는데,
(관련 블로깅 :📎 Bean-us 프로젝트 최종 회고)
예를 들면,
- 유저가 서버 요청을 보내는 버튼을 응답받기 전에 연속해서 누를 수 없도록 하거나
- 상황별 에러 핸들링을 세분화
- state 등을 조작하여 부적합한 서버 요청을 하는 경우 고려
- 느린 네트워크 환경을 위한 이미지 로딩 개선
등 1차 프로젝트에서 아쉬운 점으로 정리해둔 사항을 고민하며 기능 구현을 하였다.
아직 많은 부분 부족하고 리팩토링해야하는 부분이 남아있지만, 그래도 팀원들의 리뷰를 통해 내가 의도한 부분이 반영되어 작성되었다는 것을 알 수 있었다.
