KPT?
K
→P
→T
순서로, 좋았던 것 그래서 유지하면 좋을 것(Keep)을 이야기 하고, 문제였거나 부족하거나 아쉬웠던 것(Problem)을 그 다음으로, 마지막으로는 시도해볼 것(Try)을 이야기 하며 정리하는 방법이다.주장권
Problem
- 미룬 일 잊어버리기
이번 프로젝트를 진행하면서 ‘음 이 부분은 추상화해서 따로 utils에 빼면 좋겠는데’ 라고 생각되는 부분들이 많았지만, 빠르게 그리고 많은 기능을 구현하고 싶은 욕심에 PR올릴 때 쯤 수정하지 뭐.. 이런식으로 미뤘다가 그대로 잊어버리는 경우가 많이 늘어났다.
- 컨벤션 적용
사실 나는 이때까지 한 분야를 여러명에서 개발한 경험이 없었고 코드를 작성하면 나 혼자만 사용했었기 때문에 항상 세워둔 규칙 없이 자유롭게 코딩했었다.(변명) 이번 기회에 첨으로 팀 단위 개발을 경험하게 됐는데, 팀 컨벤션을 숙지하고도 컨벤션이 있었다는 사실을 망각한채 중구 난방으로 코딩하는 경우가 있었다.
김윤경
Keep
- 적극적인 코드리뷰
코드를 작성하여 기능 개발하는 것도 중요하지만, 팀원들의 코드를 읽고 이해하는 능력을 키우는 것도 중요하다고 생각한다!
- 개발 컨벤션 정의 및 적용하기
컨벤션을 통해 프로젝트 일관성을 유지하고, 코드의 가독성을 높일 수 있었다. 또한 협업의 효율성을 높이고, 코드 리뷰 시간을 단축시킬 수 있었던 것 같다. 여전히 개발 컨벤션을 지키는 것이 어렵고, 자주 깜빡하지만 … 컨벤션을 최대한 지켜보려 노력해 보자🔥
문휘식
Keep
- 개발 일정 지키기 그 날 구현하기로 한, 일정을 앞으로도 지키자.
- 컨벤션 준수 개인 프로젝트와 비슷하면서도 다르게, 지켜야 할 부분이 많다. 컨벤션은 팀 프로젝트 소통에 사용되는 하나의 언어라고 생각한다. 언어가 정해지니까, 소통에 필요한 비용이 많이 절감됨을 느꼈다. 가끔 까먹을 때도 있는데, 최대한 준수하려고 노력해야겠다.
- 항상 고민하고 생각하면서 코드 작성 나만의 코드가 아닌 모두의 코드이기에, 모두가 이해할 수 있게 그리고 너무 복잡하지 않게 추상화를 적용해서 깔끔한 코드를 작성하자. (사실 깔끔하다는게 너무 추상적인 표현이다.) 많이 노력하고 있지만, 가끔 이게 맞는지 의문이 들 때가 있다. 항상 고민하고 생각하면서 코드를 작성해야겠다.
Problem
- 소통 잘하는 것과 이를 알려주고 설명하는 것은 다르다고 생각한다. 내가 이런 케이스인데, 특히 머릿속에서 생각이 정리가 되지 않아 충분한 근거를 들어 설명하는게 부족했다.
- 사전 준비 개발하면서 느꼈는데, 우리가 공통 컴포넌트로 만들 수 있던게 많았다고 생각한다. (storybook을 도입 하지 않은게 아쉽다) 이러한 부분을 사전에 충분히 얘기 해보고 미리 만들어 두었으면 프로젝트가 더 원활하게 진행되지 않았을까 한다.
- 근거있는 기술 채택 프로젝트 사전 준비를 하면서, 기술을 채택할 때 최대한 근거를 생각하려고 했다. 내 근거의 대부분은, 이전 경험에서 비롯한 어렵거나, 불편했던 부분을 해소시킬 수 있다는 점이었다. 그런데, 이 부분에서 의문이 든다. 불편했던 것 자체가 근거가 될 수 있는 건가? 좀 더 기술적인 근거를 토대로 기술을 채택해야 하는게 아닌가? 하는 생각이 든다.
Try
- 기록의 습관화 매번 프로젝트를 하면, 기록으로 남기는게 쉽지 않다. 구현 과정에서 발생하는 트러블을 그때 그때마다 기록으로 남기는 것도 쉬워보이지만 어렵다. 추억은 사진으로 남기듯, 프로젝트는 기록으로 남기자. 내가 어떤 태도를 가지고 임했는지, 어떤 생각을 가지고 구현을 했는지, 미래의 내가 그리고 나를 모르는 타인들이 내가 어떤 사람인지 알 수 있도록 하자.
- 컨디션 조절 컨디션 조절도 개발자에게 필요한 역량이라고 생각한다. 나는 나만의 루틴을 방해받는 것을 굉장히 싫어하기 때문에, 최대한 루틴에 맞게 살려고 한다. 그러나 이번 프로젝트를 진행하면서 약간은 지친 느낌이 든다. 체력도 많이 부족하고, 정신적으로도 약간 번아웃 오기 직전인 것 같다. 근력 운동만 하지 말고 유산소도 겸해야겠다.
이진아
Keep
- 기술적인 부분에 대해 공식문서, 블로그, 유튜브 등을 참고해서 공부하기
- 협업에서 중요한 코드컨벤션, 브랜치 전략, 디렉토리 구조 등과 같은 프로젝트 컨벤션을 정하고 직접 적용해보는 경험을 가짐.
- 라이브러리를 사용하지 않고 직접 컴포넌트를 개발하는 과정에 대해 알게 됨.
- 어려운 부분은 팀원들에게 도움 요청하기
- 팀원 분들이 모두 긍정적인 것이 아주 좋음.
Problem
- 개발(리액트, API 등등..)에 대한 전반적인 이해도가 낮아 이해를 하는데 시간을 많이 써서 개발 속도가 느림.
- 의견을 적극적으로 표현하지 못함. 물어보고 싶은게 있어도 자꾸 망설였던 거 같다.(입 밖으로 나오지 않는다.)
- 나의 부족함에서 오는 걱정과 스트레스를 컨트롤 하지 못하고 혼자 끙끙 앓았다. → 기술적인 부분 도움 요청으로 조금은 해결.. 뻥 뚫리는 기분도 느낌