구리

KPT 회고 방법론을 적용하며 잘한 점은 유지하고 부족한 점은 개선하기 위해 2월을 회고해본다.Keep더 나은 코드를 위한 고민개발할 때 코드 구조(컴포넌트 설계 등)에 대해 고민하며 제일 나은 방안에 대해 코드 리뷰 시간에 논의한다.사수분은 나의 고민과 방안에 대해 들으시곤 고민 해결 방향성을 봤을 때 바람직한 것 같다는 피드백을 주셨다. 물론 코드를 짜는 방식은 취향 차이가 있을 수 있지만 그렇게 짠 방식에 대한 타당한 이유는 있어야 한다고 생각하기에 고민하며 보낸 시간들이 헛되지 않았다고 느꼈다.아무리 바쁘지만 내가 짠 코드에 대한 설명은 할 수 있어야 한다고 생각한다. 그래야 결과물에 책임을 질 수 있기 때문이다.Problem고민을 너무 많이 하는 것 같다는 피드백한 문제에 대해 더 나은 코드 구..

KeepDX 개선Google Analytics 이벤트 코드가 여기저기 분산되어 있어 수정할 때 여기저기 찾아다녀야 하는 불편함이 생길 것 같아 마음에 들지 않았다. 그래서 사용자 동작이 중요하지 않은 단순 데이터 수집 이벤트라면 vuex plugin을 통해 한곳에서 이벤트 전송 코드를 관리하도록 개선했다. 기능 개발도 중요하지만 DX도 고려해서 개발하는 습관을 들여야겠다.import { trackUserCpk, trackUserId, resetUserInfo } from "@/helpers/tracking";export default function sendUserEventPlugin(store) { store.subscribe((mutation, state) => { const {type} = ..

현회사의 팀은 한달 단위로 스프린트를 진행한다. 일이 바쁘다보면 시야가 좁아지고 일을 쳐내기 바쁠때도 있다. 그래서 개인적으로 좋았던 점, 아쉬웠던 점들을 돌이켜보며 더 발전하기 위해 스프린트가 끝나면 회고를 하려 한다.회고는 KPT 방식으로 진행하며 앞으로는 Try에 작성한 방법들을 적용하며 Keep의 항목이 더 많아지는 것을 목표를 잡아본다.Keep기획 과정에서 개선 방안이나 아이디어를 많이 제안한 것이다. 그 덕분에 기능이 좀 더 견고해진 것 같다. QA 중 종종 A 케이스에는 어떻게 처리가 되는 건가요? 와 같은 질문이 올 때가 있는데 기획 과정에서 누락된 케이스들이 발견되곤 한다.중요한 부분을 놓칠 때도 있어서 QA 중 기획 및 개발 수정이 들어가곤 하는데 이번에는 그런 부분들이 적었던 것 같다..