K
- 기획까지 해야하다보니, 상당한 부분에서 고려해야할 점이 많았던 걸 느낄 수 있던 기간이었다. 중간 프로젝트의 경험이 최종 프로젝트에 많은 도움이 될 것 같고, 현업에서는 이 과정보다 더욱 복잡하고 많은 부분을 고려하여 업무를 진행하겠구나 느낄 수 있었던 시간이었다.
- 규모가 더 커진 프로젝트에서 아토믹 디자인이 큰 이점이 되지 않을까 생각되었다. 작은 단위로부터 크게 컴포넌트를 쌓아가다 보니 처음엔 조금 힘든 작업이었지만, 나중에 기능을 추가할 때는 생성된 컴포넌트 내부에 코드를 조금 추가하거나, prop을 넘겨주는 방식으로 기능을 추가할 수 있었기 때문에 필요한 코드들을 조금 더 명확히 담을 수 있지 않았나 생각이 들었다.
- 팀 프로젝트를 진행해보니 배웠던 것들을 어떤식으로 적용해나가는지에 가장 빠르게 익힐 수 있었다고 생각하고, 가장 빠르게 배워나갈 수 있지 않았나 싶었다. 모르는 부분을 구현해보면서 팀원들과 주고받았던 부분이 가장 큰 도움이 된 것 같다.
- 데일리로그를 남김으로써 당장의 기술 부채가 있더라도, 기록을 통해 언젠가 보고 해결할 수 있는 점이 가장 좋았다.
- 이슈에 라벨 남겨서 할일을 추적 가능한 점이 좋았다!
- eslint, prettier, commitizen, husky 사용으로 코드 컨벤션 맞춤
- 브랜치 전략을 먼저 정하고 프로젝트를 시작한 것
- 작업이 정체될 때, 팀원들과 문제되는 것에 대해 이야기 나누기
- 실제로 서비스한다고 생각하면서 개발하기
- 처음에 리액트 강의를 다 듣고 진도를 맞추고 시작한 것
- 작업할 게 있으면 이슈부터 작성해서 팀원들과 공유하기
P
- 구현함에 있어서 많은 고민을 하지 않고 기능 구현에 급급했던게 아쉽다. 완성과 학습이라는 우선순위 사이에서 줄타기를 잘 못한 것 같다.
- 버그들을 해결 했지만 왜에 집중하기 보다는 해결되면 그냥 되네~하고 넘어갔던 것들이 있어서 그런 문제들을 차차 톺아볼 예정이다.
- 방법론의 선택이 중요하다는 점을 깨달았다. 꼭 하나만 치중해서 선택해야 하는 것도 아니고, 두 가지의 장점을 섞어서 가져갔을 수도 있을 것 것 같은데 그 부분을 채우지 못한게 아쉬웠다.
- 기획에 있어서 수요층에 대해 '이 부분이 사람들이 필요로 하겠지?' 라는 대략적인 추측보다는 체계적으로 분석해서 프로젝트를 시작해야 할 것 같다고 느꼈다.
- 아직 어려운 부분이 많다. API는 정희님이 만든 기초 샘플을 보고 그 위에서 작업을 해도 쉽지 않았는데.. 예전부터 느꼈지만 API 부분에서 어려움이 있다. 포스트맨을 좀 더 다뤄보고 익혀봐야 할 필요성을 느꼈다.
- Git 을 사용하는 부분에서 내가 갖고있는 문제점
개인 브랜치에서 작업을 마치고 push 햐는 시점에서 브랜치를 따온 develop 에 변화가 생겼을 때를 잘 대처하지 못하는 것 같다. 이 부분을 개인 레포지토리등을 통해 조금 더 공부하려고 한다.
- 모르는 부분에 있어서 해결해야 할 것들이 너무 많았던 점이 힘들었던 것 같다.
진도도 느려지고, 가장 많이 알고있는 팀원에게 많은 걸 물어보게되어 쏠림이 있었다고 생각한다. 최종 프로젝트 때는 기간이 좀 더 길기도 하고 그 전에 공부할 시간이 있기 때문에 이번에 느꼈던 부족한 부분을 중점으로 공부하려고 한다.
- 어떤 기능이 필요한지 처음부터 잘 정의해야 할 필요성을 느꼈다.
프로젝트를 진행하면서 이 기능이 필요할 것 같기도 하고, 굳이 필요없을 것 같기도 할 때가 있었다. 이런 부분을 초반에 조금 넓게 생각해보고 잘 정의해두면 좋을 것 같았다.
- 업무 분담에 있어서 내가 어떤 부분을 전담하고 있는지 명확하게 정해도 좋을 것 같다.
- 크게 영향을 끼치지 않는 사소한 부분에서 시간을 많이 들이는 개인적인 문제점을 조금 줄인다면 더 프로젝트의 진척도가 빨라질 것이라고 느끼고 있다.
- 질문을 할 때는 조금 더 체계적으로, 어떠한 시도를 했을 때 어떤 문제점이 있었는지를 체크해서 전달해야 할 필요성이 있다.
- 팀원 간의 개발 실력차로 인한 코드 리뷰와 질문이 편중되는 문제가 있었다.
- 업무가 분배되어 있는 상황에서 팀장인 정희님께 모르는 것을 질문하게 되면 정희님이 본인의 업무를 진척할 시간이 부족하게 되는 문제가 있었다.
- 오토메이션 문제 해결 방법 → https://www.hahwul.com/2018/07/27/closing-git-issue-with-commit/
- 팀원들이 현재 어떤 작업을 하고 있는지 알기 어려운 문제가 있었다.
- 깃헙 라벨을 이용해 현재 작업 중인 이슈를 표기해 어떤 작업을 진행중인지 다른 팀원도 알 수 있게 했다.
- 프로젝트를 진행하는 동안 개더에 상시로 모여 있어 수시로 작업 진행 상황을 공유했다.
- 너무 디테일까지 생각해서 일을 할 때 너무 오래 걸리는 문제가 있었다.
- 작은 단위로 쪼개서 체크리스트 쓰는 것으로 완화했다.
- 디테일을 최대한 버리고 틀부터 완성해서 PR하는 것으로 합의해 시간을 PR 올리는 시간을 단축시켰다.
- 중간 보고까지 처음 기획을 어떻게 구현할지 정확한 그림이 잡히지 않는 문제가 있었다.
- 매니저님께 서비스적으로 피드백을 받고 최종 발표까지 구현 가능한 정도로 기능을 대폭 수정했다.
T
- 마감기한을 늦게 정한 것이 아쉽다. 각자 할일에 따른 측정하는 노력도 할 수 있는 좋은 기회를 너무 늦게 시작한 것 같다. 꼭 맞춰야만 하는게 아니니 다음엔 일정을 꼭 산출하는 노력을 해보려고 한다.
- 마감기한과 더불어 전체일정도 잡아놨으면 좋았을 것 같다. 어차피 밀린다는 생각으로 잡지 않았었는데, 틀을 잡아야 어느 정도 목표 대비 진도 파악과, 느려지면 왜 느려지는지에 대한 원인 파악을 할 수 있을 것 같다.
- 주변에 있는 사람들을 통해 아이디어 피드백을 많이 많이 받아서 발전시켜 나가자.
- 전체적인 개발 프로세스 파악이 가능해져서 Top Down 방식도 시도해볼 수 있을듯 하다.
- Typescript 도입
- 나의 현재 기술 구현 수준보다 조금 더 높은 수준에 있는 기술 구현 도전하기(예상 작업 시간 미리 산정하기)
- 비동기 커뮤니케이션 방식으로 질문과 답변 주고 받기