<엔지니어링 회고> 오늘은 퍼블리에 들어오고 첫 엔지니어 회고를 진행했다.엔지니어 회고는 무거운 미팅이라기 보다는 어떤 작업을 했는지, 작업할 때 잘한 것은 어떤 이유에서 잘 하게 되었으며, 못한것은 왜 못했는지를 가볍게 이야기하는 시간이다. 주로 내가 잘한것은 그저 '돌아가게는 만든것' 이었다. 신입으로서 잘 돌아가게 만드는 것만으로도 꽤 벅찼다. 하지만 나는 계속해서 성장해 나갈 것이기 때문에 돌아가게만 하는것에 만족할 수 없다. 시니어 개발자가 되기 위해서는 나쁜 코드를 좋은 코드로 바꾸는법도 알아야 하며, 기술적인것 뿐만아니라 의사소통, 일하는 방식에 있어서도 더 나아져야 한다. 아래는 엔지니어 회고에서 공유한 여러가지 고칠 점 중 중요하고, 꼭 맞춰가야 할 것들에 대해서 적었다. 1. 태스크를 분할하여 사이드 태스크로 나눠 작업은 잘 진행하였으나, 사이드 태스크 이름만 보고는 PM, PD가 어떤 작업인지 알 수 없도록 적었다. 이유는 태스크를 작업해야하는 파일명으로 적었기 때문인데, 이는 파일이 서로 의존적인 작업을 할 때에는 나조차도 어떤 작업을 하고있는 것인지 모호해졌다. 앞으로는 사이드 태스크는 작업의 목적별로 나누고, PM, PD 또는 제 3자가 보아도 어떤 작업인지 알 수 있도록 하는 이름을 사용하려 한다. 2. 한 곳에서만 작업할법한 것까지 모두 컴포넌트, 모듈화해서 적용했다. 예를들면 한곳에서 밖에 쓰이지 않는 팝업창 임에도 굳이 파일을 나눠 작업했다. 이에 내 태크리드는 작업을 시작할때부터 아키텍쳐를 생각하지말고, 우선은 돌아가게 짜둔뒤 반복되게 쓸만한 것을 잘 고려해서 아키텍쳐를 생각해보라고 조언했다. 이는 처음부터 아키텍쳐를 생각하던 나에게 꽤 도움되는 말이었다. 이 작업 이후의 작업에서는 아키텍쳐 생각하지않고 돌아가게 짜두었는데, 돌아가게만 짜두고나니 반복적인 부분도 더 잘보였고, 아키텍쳐를 생각하는 시간도 훨씬 줄게 되었다. 3. 작업이 진행되는 도중 변경사항이 생겼는데, 그 변경사항과 상당히 비슷한 케이스의 경우는 그대로 두고, 해당 변경사항만 적용했다. 상당히 비슷한 케이스의 경우가 있다는 사실도 알고 있었는데, 슬랙에서 이야기 나온 것은 한가지라고만 생각하고 내 판단으로 넘어갔던 것 같다. 아니나 다를까 QA단계에서 이야기가 나왔으며 다시 작업을 해서 스테이징 앱 빌드도 다시 해야하는 번거로운 일이 생겼다. 이런 경우는 완벽한 나의 실수라고 생각하고, 앞으로는 의문점, 모호한 부분이 생기면 팀원들과 바로 공유하는 습관을 가질 것이다. 이 밖에도 아주 많은 실수들이 있었지만, 코드적인 부분, estimate을 잘 못한 부분 등 정리해두기에 애매한 것들이다. 회고를 통해서 내 잘못된 점을 고쳐갈 기회까지 주는 회사... 최고다 많은 피드백을 통해 성장하고 있는 느낌이 너무 좋고, 더욱더 성장해 나가고 싶다.