내용에 문제가 있는 경우 삭제, 수정 조치 하겠습니다.
6월이 끝났다. 4주간 회고글을 못썼는데 한 번에 정리해보고자한다.
되돌아보기
기존에 목표로 했던 것들을 기반으로 작업했다.
업무별 시간을 작성하고, 각 작업별 분류를 통해 인지-개선하는 과정을 이어가고자 쭉 이어왔는데,
점점 챙겨야 하는 부분들이 생기게 되면서, 전환이 잦아졌고 로우 데이터를 작성하는 것이 어려워지게 되었다.
작성 자체가 하나의 컨텍스트 전환이 되어서 어려워진 부분도 있는 것 같다.
지금까지 데이터를 봤을때는 구현이 초기에는 60%였으나 50%대로 내려온 상태이고, 이전의 과정을 통해서 워크플로우를 확립하게 되어 이제 데이터 작성은 작성함을 통해 얻는 것보다, 그로 인해 몰입이 깨지는게 더 크다고 생각하여 이 부분은 더이상 유지하지 않게 될 것 같다.
잘한 것
워크플로우를 기반으로 작업
일전의 과정을 통해 확립한 워크플로우를 유지하면서 작업에 대한 속도와 퀄리티를 어느정도 잘 챙길 수 있었다.
설계문서를 먼저 작성하고, 이후 실제 코드를 작성하는 과거의 나와 페어 프로그래밍 하는 과정과 셀프리뷰시에 말을 하면서 하는 과정을 통해 챙겨지는 부분이 많아서 코드 퀄리티 개선에 많은 도움이 되었던 것 같다.
더불어 설계 문서 작성시에 어떤 데이터를 수집해야할지를 고민하고, 이를 배포 이후에 확인하는 과정을 통해 의사결정에 도움이 되는 데이터를 확보할 수 있게 되었다.
데이터에 대한 관심
요즘 그로스 해킹을 읽으면서 어떻게 하면 더 나은 제품을 만들 수 있을지,
어떻게 데이터를 해석해야할지 등을 학습하고 있다. 아직은 데이터 분석에 어려움이 있지만 계속해서 발전시켜나갈 것이다.
개선이 필요한 점
사이드 이펙트 고려하기
일전에 작업한 부분에서 사이드 이펙트가 발생해서 제품에 영향을 미친 케이스가 있었다.
어떤 부분이든 작성/변경한 코드가 있다면, 그것이 사이드 이펙트를 불러오지는 않을지 고민하는 과정이 필요하다.
이전까지의 워크플로우에서는 내가 작성한 코드가 잘 동작하는지에 대한 테스트케이스를 작성하고, 확인하는 과정만을 거쳤다면,
이제는 이 과정을 수행하기전에 내가 바꾼 코드로 인해 발생하는 사이드 이펙트가 있지는 않는지 확인하는 과정이 필요하다는걸 느꼈다.
셀프 코드리뷰 후에 작성한 코드가 어떤 것이고, 이것들로 인해 사이드 이펙트가 발생하지는 않는지 확인하는 과정이 더 필요하다고 느꼈다.
스펙 분석 단계에서 누락되는 케이스 제거하기
이전까지는 피그마를 읽는 방향을 신경쓰지 않고 스펙을 분석하다보니 UI 흐름에 따라 읽게 되었고, 이로 인해 놓치는 부분이 발생했다.
이런 부분을 최대한 없애기 위해 스펙 문서에 What's Changed 항목을 추가했다.
피그마의 모든 변경과 조건을 한번 정리하고, 놓친 것은 없는지 모두 확인한 후에 설계단계로 넘어가는 형태로 방향을 잡았다.
후속 대응도 똑같이 챙기기
하나의 스펙이 배포된 후 후속 대응을 챙길때 첫 개발할때보다, 워크플로우가 단순화되는 경향이 있었다.
후속 대응도 하나의 스펙으로 생각하고 첫 개발과 마찬가지의 워크플로우로 설계문서를 작성하고 진행해야한다.
마무리
이전까지의 목표들을 워크플로우로 만들어서, 목표를 간소화시켰다.
- 워크플로우를 준수하기
- 메모장을 준비하고, 메모하는 습관 유지하기
- 내용이 없어도 회고하는 사이클 지키기
- 코드 작성시 일관성과 정확성에 대해 의식을 갖고 챙길 것
- 불안감이 느껴진다면, 그림을 그려서 이유를 찾을 것
- 가정과 사실을 기록하고, 암묵적 가정을 하지 말 것
- 추측하지 말고, 시험할 것
- 아침에 30분씩 CSS학습
- 기능에 대한 논의는 모두 기록할 것/기능 논의는 가능한 경우 한번에 처리할 것
