Keep
- 아토믹 디자인을 적용해 Atom이라는 작은 단위부터 컴포넌트를 나눠서 컴포넌트 기반으로 작업하는 것에 익숙해질 수 있었다. 기능 단위로 일을 나눴다면 코드가 더 중구난방이 됐을 것 같다.
- 프로젝트를 진행하다보면 '아, 이 기능이 필요했는데, 이 prop을 넣어줘야 했는데..' 처럼 다른 부분에서도 보완해야할 점이나 수정할 점이 계속 떠오르는데, 이미 작은 컴포넌트 단위부터 만들어가는 방식이라 수정하기도 쉬웠던 것 같다.
- commitizen이나 eslint, prettier 설정을 꼼꼼하게 잡고 시작해서 프로젝트가 보다 정돈된 느낌이 들어서 좋았다.
- 브랜치 전략을 시작부터 정해서 브랜치 merge 할 때 큰 문제를 줄일 수 있었다.
- 데일리 로그를 작성하기 시작하면서 오늘 한 일, 나중에 해결해야 할 일을 남겨두고, 우선 다음 작업으로 넘어갈 수 있는 점이 좋았다.
동영1팀 데일리로그
- 강의가 컴포넌트를 직접 만들어보는 방식이라서 프로젝트에 적용하기 용이했다.
- 컴포넌트를 미리 정의해두는 방식으로 작업하니 UI 마크업할 때 수월했다.
- 주말까지 코어타임에 개더에 같이 모여서 작업하니 너무 늘어지지 않을 수 있어서 좋았다.
- 초반에 팀원들과 협업할 때, 이야기 나누지 않고 넘어가는 부분에 있어서 혼자 부정적으로 결론 내린 문제들이 많았다. 하지만 솔직하게 털어 놓자 사실 팀원들이 긍적적으로 생각하고 있다는 것을 알게 되었고, 프로젝트를 훨씬 수월하게 풀어나갈 수 있었다. 뭔가 문제가 있거나 부정적인 감정이 들면 솔직하게 팀원들과 소통하는 것이 중요하다고 느꼈다.
Problem
- 회의록을 너무 안 쓰는 문제가 있다.
- 도입해 볼 해결 방법: 서기를 정하자!
- 서기 순서: 권정희 - 이소진 - 임경희
- github project의 automation 기능이 잘 적용이 안 되는 문제가 있다.
- automation 되는 기준이 풀리퀘인 것 같은데 우리는 이슈를 기반으로 정리하고 싶다. 이슈 기준으로 정리하려면 수동으로 분류해줘야 할 듯
- 프로젝트의 기능 부분을 어떻게 구현할 수 있을지 잘 감이 오지 않는다.
- API 구조 파악이 어렵고, API에 대한 사전 지식이 없다면 API를 이용한 작업을 하는 데에 막막함을 느낄 것 같다.
- 코드 리뷰를 모두가 하는 것은 시간 낭비가 될 것 같은데, 한 명이 모든 코드 리뷰를 하기에는 부담이 있을 것 같다.
- 이전에 git을 써 본 경험이 많이 없다 보니 git으로 협업하는 데에 어려움이 있다.
- 작은 컴포넌트를 구성하는데도 시간이 꽤 많이 걸렸다. 초반에는 디테일까지 생각하는 것보다 대략적인 구성으로 만들고 나중에 리팩토링 하는 방법도 좋은 것 같다.
- 기능 구현을 들어가기에는 알고 있는 것이 부족하다고 느껴진다.
- 컴포넌트 구성을 시작할 때 이 컴포넌트의 구성을 어떻게 잡고, 어떤 값을 prop 으로 받아야 할지, 어떤 기능을 염두하여 설계해야 할지 막막함이 있었다.
- 일정의 압박감이 생각보다 심하다. 완성을 할 수 있을지 불안해져서 조급함에 더 일이 안 되는 문제가 있다.
Try
- 코드 리뷰 주기를 n일로 정했지만, n일 마다 코드 리뷰를 받아서 merge 하기에는 프로젝트 진행이 지연되는 문제가 있다.
- 코드 리뷰는 지금처럼 자율적으로 진행하되, PR에 봐달라고 요청한 부분은 꼭 보고 확인했음을 코멘트로 남겨주기로 했다.
- 급하게 develop에 push 해야 하는 부분이 있다면 push 하고 팀원들에게 꼭 공유하기로 했다.
어려운 점
- 현재 모든 컴포넌트를 만든 이후에 기능 개발을 들어가니 진도가 상당히 늦어진 것으로 파악했는데요. 더 작게 쪼개서 컴포넌트를 만들어나가며 기능을 계속해서 붙여나가는 방식이 좋았을 지 궁금합니다.😥
- 프로젝트를 학습하는 과정의 하나라 생각했을 때에도 기한 엄수가 하나의 문제를 깊게 파는 것보다 더 중요하게 생각되어야 할까요? 기한 엄수를 통해 저희가 배울 수 있는 것에는 무엇이 있을지 궁금합니다.
- MVP를 설정하는데에 실패했다고 느끼는데, MVP를 설정하는 꿀팁이나 이를 설정하는 방법? 같은 구체적인 방향이 있을까요?
- API에서의 예외처리를 공통적으로 처리해주는 로직이 있는지? 아니면 각 status 마다 다르게 처리해주는 식으로 전부 try, catch 해주어야하는 지 궁금합니다.
- 개발의 전체 흐름에 대한 이해가 없다 보니 이 단계 다음에 어떤 단계가 와야 하는지 감을 잡기가 어려운 것 같습니다. 현업에서 신입들은 개발 프로세스에 대해 어느 정도 이해하고 있어야 할까요? API를 이용한 기능 요구사항이 있을 때 혼자 힘으로 뚝딱 설계할 수 있을 정도는 되어야 하는 걸까요?