프론트 회고록

Keep

• 탑다운 방식은 처음이여서 작업할 페이지를 각자 맡아 처음부터 끝까지 구현하고 있어서 아토믹 방식처럼 모두가 처음부터 같이 컴포넌트를 만들고, 언제까지 마크업을 마치고, 언제까지 api를 붙이고 등의 협업방식은 없었지만 오직 혼자서 컴포넌트에 대한 고민을 할 수 있는 시간이 많아져서 구현에 대한 고민을 깊게 할 수 있었다.

• 러닝 커브가 있더라도 실제 production에서 많이 사용되는 Typescript와 Next.js를 도전함으로써 많은 것을 배우고 자신감을 얻을 수 있어서 좋았다.

• 백엔드 배포 일정이 늦어질 때, 직접 백엔드 코드를 Local에 받아서 서버를 실행해보며 미리 테스트해 볼 수 있었던 경험이 좋았다.

Problem

• 회의 때 서로 같은 이야기를 하고 있다고 생각했지만, 서로 다르게 이해하고 있는 경우가 많았다.
• 초기에 백엔드와 프론트가 함께 API 명세를 제대로 잡고 가지 않아서 여러번 조율해야 하는 문제가 있었다. 백엔드와 프론트엔드가 처음부터 함께 API 명세를 함께 작성했다면 시간이 절약되었을 것 같다.
• API부터 논의하다 보니 중간 프로젝트보다 훨씬 회의 시간이 길었는데 확정 내용을 한 곳에 정리해두지 않아서 확정된 내용에 대해 서로 이해한 게 달랐던 문제가 있었다.
• 프론트엔드끼리 회의하다가 피그마에 반영해놓지 않고 결정한 내용을 백엔드 팀원 분들에게 공유하지 않은 문제도 있었다.

• 백엔드와 프론트 간 서로의 일정 파악이 부족했던 것 같다. 더 관심을 가져야 한다고 느꼈다.

• 전체적인 일정 부재로 언제 어떤게 나와야 하는지, 목표가 어떻게 되는지 모호했다.

• 탑 다운과 바텀 업의 이점을 둘 다 누려보고 싶었지만 탑 다운에 치우쳐져서 개발을 진행하게 된 것 같다.
• 처음에 어느 정도 설계하고 들어갔다면 추후 리팩토링 할 일을 더 줄일 수 있지 않을까
• 컴포넌트보다 페이지 구현을 먼저 하다 보니 나중에 컴포넌트를 분리하는 작업할 게 조금 아득하게 느껴진다.

• PR 크기를 잘게 쪼개지 못해서 며칠간 PR을 올리지 못 해 PR이 너무 크게 가는 경우가 있었다.
• 적절히 쪼개는 연습을 하거나 PR을 올리는 주기를 정해서 강제적으로라도 올리는 룰을 세워야 한다.

• 기술적인 이야기를 나누는 시간, 코드에 대한 이야기를 나누는 시간은 희망자에 한해 스크럼 이후로 하는게 흐름 상 좋을 것 같다.

• 회의 시간을 정해 시간 내에 하지 못하면 못한다는 생각으로 해야 무한정 늘어나는 회의를 막을 수 있을 것 같다.

• gitmoji를 commitlint로 강제해서 사용하는 컨벤션을 써보니 적합한 gitmoji를 찾느라 쓸데 없는 시간을 많이 들이는 느낌이 있고, 또 모든 gitmoji가 호환되지 않는 문제가 있었다.

• 브랜치 이름 전략에 따라 페이지 별 기능을 분리하여 브랜치를 만들기 어려웠다.

• Typescript, Next.js와 같은 새로운 기술을 도입하다 보니 공수 산정하기 어려운 문제가 있었다. 다음에 공수를 산정할 때는 신기술에 대한 러닝 커브도 고려해야 할 것 같다.

• Next.js, TS 등 에 대한 이해도와 로직 구현에 대한 이해도가 부족해서 작업 진척도가 더뎠다. 그래서인지 스크럼에서도 원활하게 커뮤니케이션을 잘 하지 못한 것 같다.

• 페이지를 동등하게 나누어서 맡은게 아니라 복잡한 페이지는 더 잘 할 수 있는 사람이 맡고 그 외에 크게 복잡하지 않은 페이지를 나누어 맡아 작업을 하였는데, 후에는 실력을 키워 복잡한 페이지도 뚝딱 구현해 내고 싶단 생각이 들었다.

Try

• 공수에 대한 기록을 통해 예측과 실제를 맞춰나가는 연습을 해보고 싶다.
• 이슈에 예측 공수, 실제 공수를 적어서 왜 더 오래 걸렸는지, 왜 더 짧게 걸렸는지 생각해보면 좋을 것 같다.

• 코드 리뷰를 남겼지만 개발을 위해 반영하지 않고 머지하는 경우가 종종 있었다.
• 코드 리뷰 레벨을 정해보면 좋을 것 같다. 리뷰어 입장에서 꼭 반영해줬으면하는 레벨이 높은 리뷰는 반영하기 전에는 머지하지 않도록 한다. (https://blog.banksalad.com/tech/banksalad-code-review-culture/#커뮤니케이션-비용을-줄이기-위한-pn-룰)

• 회의록 작성을 강제화하고, 어떻게 모은 정보를 찾기 쉽도록, 자주 볼 수 있도록 할지 고민해야 한다.

• 백엔드와 첫 협업이었는데 회의를 할 수록 백엔드에 대한 이해가 없다보니 회의 내용을 못 알아 듣는 경우가 많이 발생했다. 이번 프로젝트를 경험으로 후에는 백엔드와의 협업에서 커뮤니케이션이 잘 되었으면 한다.