프론트엔드 스쿨 1기의 마지막 프로젝트. 3주간 서로 논의하며 개발했던 시간이 지나고 이를 회고하고자 블로그를 작성한다. 이 글은 팀원들과 함께 적은 회고록에서 본인(🍑) 부분을 발췌한 부분과 추가로 작성한 부분으로 이루어져 있다.
😁 프로젝트가 끝났는데 소감이 어떤가요?
🍑: 주어진 시간 안에 완벽은 아니지만 90%이상의 목표를 달성하여 뿌듯합니다. 그리고 프로젝트에 대해 세세하게 기록하는 방법을 알아감으로써 이해도를 높일 수 있어 좋았습니다.
이전 경험을 토대로 협업툴을 이용한 것이 프로젝트를 달성하는 데 큰 도움이었습니다. 노션 템플릿을 이용하여 스케쥴, 칸반, 간트 차트 등 프로젝트를 공유하여 관리할 수 있어 팀원들과 계획을 세우고 중간 작업을 체크하면서 목표를 조정해나갔습니다. 특히나 저번에 회의록이나 오류에 대해서 기록하지 않은 아쉬운 점이 있어, 오류가 발생하면 원인과 해결방법을 문서로 작성했습니다. 이는 나중에 팀원들과 함께 이야기해보며 좀 더 좋은 해결책에 대해 서로 이야기해보기도 않고 어떤 오류들이 발생할 수 있는 지 간접 경험을 해볼 수 있었습니다.
이처럼 팀원들과 같이 프로젝트의 과정을 밞아 나가는 것이 생각을 더 깊게 해 볼 수 있어 좋은 경험이 되었고 다시 한번 팀 프로젝트를 했으면 좋겠다고 생각했습니다. 그리고 마지막으로 프로젝트가 처음에 기획했던 부분이 남아있고, 팀원 모두가 완성에 같은 뜻을 두고 있기 때문에 조금 더 힘을 내서 완성도를 높여보겠습니다.
🧐 이번 프로젝트에서 새로운 점은 어떤 건가요?
mock server로 데이터 통신을 하여 개발을 진행했다는 점입니다. 프론트엔드로 개발을 진행하다보면 백엔드에서 API를 주기 전에 express를 사용하여 따로 mock server를 만들어서 진행한다는 것을 알고 이번 프로젝트에 적용해봤습니다. 또한 SPA로 프로젝트를 구현하면서 경로가 바뀔 때마다 index.html파일을 response값으로 주어야 되서 필수적으로 mock server를 구현할 필요도 있었습니다. 직접 서버를 만들고 데이터 구조를 만들어 주고받는 것이 신기하면서도 나중에 프론트엔드를 다지고나면 백엔드쪽도 배우고 싶다는 생각이 들기도 했습니다.
🤔 프로젝트를 하면서 좋았던 점, 앞으로 유지해야겠다고 느꼈던 것은 어떤 것이 있나요?
🍑: 첫번째는 다른 사람의 의견에 귀 기울여 주는 자세가 좋았습니다. 매일 오전에 회의하는 시간을 가지면서 전체적인 일정을 조율했습니다. 이 때 모두 다른 사람의 말에 집중하고 의견차이가 있을때 상대방의 의견을 차분하게 들어주는 점이 의견을 존중받는 느낌이 들어서 팀을 생각하면서 프로젝트에 집중할 수 있었습니다. 이런 부분을 상기하며 앞으로 프로젝트를 하면서 팀원의 의견에 귀를 기울이고 존중하여 즐겁게 개발하는 환경을 만들어야겠다고 생각했습니다.
두번째는 코드 리뷰와 깃모지를 사용한 commit convention이였습니다. 확실히 텍스트보다 이모지가 눈에 더 들어오기 때문에 가독성 측면에서 매우 좋았습니다. 다만 해당 이모지가 어떤 의미를 담고 있는지 알고 있어야 되서 외워야되는 부분이 있지만 그 부분은 프로젝트를 진행하면서 계속 사용항게 되면 익숙해지는 부분이라 사용하는 것이 더 이점이라고 생각됩니다.
🤨 4명이 함께 협업하면서 어려움이 있었나요?
🍑: 다른 팀원의 코드를 파악하는 것이 어려웠습니다.
Pair programming에서는 같이 작업을 하고 리팩토링할 시간도 충분했기에, 자연스레 여러 번 반복 학습을 하게 되었고 코드를 충분히 파악할 수 있었습니다.
그렇지만 이번 프로젝트는 CBD & SPA로 작업하면서 여러 개의 컴포넌트로 나누어져 있다 보니 전체 구조를 파악하고 하나씩 코드를 분석해야 했습니다. 그래서 매일 오전에 회의를 하며 각자 맡은 부분을 어떻게 코드로 구현했는지 설명을 듣고 어떤 오류가 있었는지 이야기를 나누며 서로의 코드를 파악했습니다. 또한 기능을 구현하면서 필요한 개념, 오류가 난 원인 등을 문서로 작성하여 다른 팀원들의 코드를 이해할 수 있도록 했습니다.
이런 부분 덕에 코드를 수월하게 파악할 수 있었으며 오류, 리팩토링 등을 할 때 어떤 부분을 고려해야 하는 지에 대해 생각하며 코드를 수정할 수 있었습니다.
🤔 CBD, SPA로 작업을 하셨는데 구체적으로 어떤 부분이 어려우셨나요?
🍑: 컴포넌트 첫 렌더링 시, 서버에 요청을 보내는 시점을 생각하는 것이 쉽지 않았습니다.
팀원들이 DOMContentLoaded 이벤트가 발생할 때 서버에 요청을 보내면 App.js가 첫 실행되는 시점에만 발생하고 컴포넌트의 새로운 인스턴스가 생성될 때 발생하지 않는다고 했습니다. 그래서 인스턴스가 생성되는 시점인 constructor에서 메서드를 호출하고자 했습니다. 그렇지만 서버 요청을 하고 그 결과 값을 store에 저장하게 되면서 다시 렌더를 호출하게 되고 무한 루프에 빠지게 되었습니다. 그렇게 팀원들이 다른 방법을 시도하게 되었지만 일관성 있게 작동하지 않는 문제가 있어 다시 원점으로 돌아가게 되었습니다. 마지막으로 render함수 안에서 서버에서 요청한 데이터로 바로 domString을 만들고자 했습니다. 하지만 이 부분도 서버에 계속 요청하게 되어서 다른 방법을 생각하게 되었습니다. 그러다 강사님께 이 방법에 대해 상의하게 되었고 서버에 요청을 보내는 것도 상태값으로 관리를 하여 현재 path와 상태 값을 비교하여 렌더 하게 되었습니다.
이것을 구현하면서 프레임 워크에서 생명주기가 이런 점 때문에 필요한 거구나라고 느끼게 되었습니다. cbd, spa의 원리에 따라 구현에 보면서 React, Angular 등의 프레임워크의 전반적인 흐름에 대해 이해할 수 있는 시간이 되었습니다.
🥲 어떤 부분이 이번 프로젝트에서 가장 아쉬우셨나요?
🍑: 4명의 팀 단위로 작업을 하는 기회가 많지 않은데 다양한 방법으로 작업하지 못한 것이 아쉬웠습니다. 3주 동안 프로젝트를 하면서 1인, 페어, 전체 팀으로 나눠서 진행해보았지만 장점도 있었지만 아쉬움이 있었습니다.
1인 작업은 기능에 대해서 혼자만의 고민을 해보는 시간이 주어져 좋았지만 개인 작업이다보니 다른 팀원의 코드를 파악하기 위한 시간이 필요했으며 기능의 난이도를 고르게 분배하는 것이 어려웠습니다.
페어로 리팩토링을 진행했을 때는 다른 팀원이 어떤 생각으로 기능을 구현했는지 자세하게 알 수 있었습니다. 또한 다른 시각으로 문제를 바라볼 수 있었습니다. 하지만 리팩토링의 시간이 많지 않았던 터라 페어 팀을 돌려가면서 전체 코드에 대해서 세세하게 파악하는 시간을 갖지 못한 것이 아쉬웠습니다.
팀 작업은 jwt같은 개념을 러버덕하거나, 병합 단계의 오류를 해결하는 것으로 진행했습니다. 라이브 쉐어로 같이 코드를 보며 작업을 하거나 드라이버와 내비게이터의 형태로 진행하기도 했습니다. 다만 드라이버와 내비게이터의 경우 드라이버를 한 명으로 역할을 부여하니 집중력이 흐려지기도 했던 것 같습니다.
하지만 이를 계기로 협업에 도움이 되는 방법이나 시간 관리에 대해서 생각해보게 되었고 다음 팀 프로젝트가 있을 시에 적극적으로 적용해보고 싶습니다.
😎 앞으로 어떻게 개발 공부를 하겠다는 생각이 들었나요?
🍑: 생각했던 것을 메모하는 습관이 필수라고 느꼈습니다. 코드 양이 방대해짐에 따라 내가 왜 이런 코드를 생각했는지, 왜 오류가 발생했는지 명확히 알 수가 없었기 때문입니다.
파이널 프로젝트에서 DnD 기능을 구현하면서 추가적으로 필요한 기능들이 있었습니다. 그에 따라 전역 상태에 관리해야 하는 상태가 늘어났고 코드를 파악하는 시간을 더 많이 소요해야 했습니다.
또한 기능 구현을 끝내고 문서를 정리하려고 하니 어떤 오류가 있었고 내가 어떤 식으로 해결했는지 잘 기억이 나지 않았습니다. 그러면서 자연스럽게 다시 공부하는 기회도 놓치게 되었습니다. 앞으로는 개발관련 탬플릿을 하나 만들어서 잘 정리해야겠습니다.
⬇️ 팀원들과 함께 적은 회고록은 여기로 - 🍑(dee) : 본인
https://velog.io/@dessin/%ED%9A%8C%EA%B3%A0%EB%A1%9D-Vanilla-JS-SPA-CBD-%EA%B8%B0%EB%B0%98-%EC%97%AC%ED%96%89-%EC%9D%BC%EC%A0%95-%EC%BB%A4%EB%AE%A4%EB%8B%88%ED%8B%B0-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8
