해당 회고는 개인적으로 미션을 진행하면서 느낀 점, 배운 점 그리고 고칠 점에 중점을 두고 진행했습니다. 미션 진행 및 풀이에 대한 기록은 해당 레포지토리에서 확인하실 수 있습니다 ᵋ ･֊･ ᵌ !
C : Continue
-> 지속해야 할 부분 또는 만족하고 있는 부분
습관성 기록
미션을 진행하면서 어려웠던 부분이나 재미있었던 부분같이 고민들을 노션에 써내려가면서 정리를 하는 편이다. 친구에게 말하면 고민을 스스로 해결할 수 있듯, 생각의 흐름을 하나씩 써내려 가다 보면 정리가 절로 되게 된다. 틈틈히 채워넣은 흔적들 덕분에 미션이 끝나고 마무리 단계에서 하는 문서화 작업이나 회고 작성이 순조롭다. 또한, 내가 이전에 비슷한 문제로 고민했던 흔적들을 보면 시간을 오래 끌지 않고 금새 해결 할 수 있어서 좋다.
작업 세분화
작업 단위를 크게 잡으면 딴 길로 새기 쉽다. A 작업을 완료하기로 목표를 잡으면 어느 새 B 작업도 같이 엮여있게 된다. 따라서 A 작업을 하기 전에 해당 작업을 완료하기 위한 작은 목표들을 세운다. (아래 예시)
목표 : 벨로그 글 쓰기
- CSS
- 습관성 기록
- 작업 세분화
- 배운 거 활용
- 시간표 지키기
물론 나도 아직 세분화를 시작한 지 얼마 되지 않아서 익숙하지 않고 세분화를 잘 하지도 못하지만, 이렇게 작게 쪼개면 하나의 목표를 완성하는데 도움이 된다. 하기 싫을 때도 큰 거부감 없이 일을 끝낼 수 있게 도와준다.
배운 거 활용
이번 미션에서는 깃 컨벤션과 JS Style을 배웠다. 문서를 읽는데 오랜 시간이 걸리긴 했지만 배운 것을 미션에 바로 도입하면서 시행착오를 거치니 습득도 빠르고 이해도 더 잘 됐다. 깃 컨벤션 같은 경우에는 커밋메세지를 날릴 때 LLM에게 형식이 올바른지 물어가면서 맞춰나갔고, JS Style은 리팩토링을 하는 과정에서 문서와 코드를 오가며 수정을 진행했다. 이론만 아는 것과 직접 해보는 것에는 큰 차이가 있다는 것을 몸소 느낄 수 있었다. 앞으로도 배운 것은 바로 써먹을 수 있게 실습하는 것을 습관화 해볼 예정이다.
시간표 지키기
원래 학습하는 시간이 정해져 있지 않고 내가 원할 때 하곤 했는데, 우테코를 들어오면서 목표와 함께 시간표를 정했다. 물론 가끔 안 지켜질 때도 있지만 시간을 정해놓으니 어떻게든 그 시간에 집중하려고 노력하게 된다. 생활도 균형이 잡히게 되는 것이 느껴져서 계속 유지해보려고 한다.
S : Stop
-> 그만 두어야 할 부분 또는 문제점이라고 인식되는 부분
무분별한 커밋
이번 미션에 README에 기능 목록을 작성하고, 기능 단위 별로 커밋하라는 요구사항이 있었다. 나는 기능에 영향이 가는 변경사항이면 커밋하라는 것으로 이해하고 커밋 단위를 최대한 작게 해서 진행했다. 그랬더니 다른 사람들은 많아도 10개를 안 넘는데, 나는 거의 60개가 되었다. 미션을 제출하고 보니 기능 단위라는 것이 하나의 기능을 구현 완료하는 기준이라는 것을 알게 되었다. 더군다나, 새로 배운 깃 컨벤션을 적용하느라 푸쉬 하기 전 전체적인 코드 확인을 하지 않아 오류가 있음에도 불구하고 깃에 올려버리는 실수가 있기도 했다. 깃에 대한 새로운 것을 배울 수는 있었지만 아직 엉망진창인 상태로 사용하고 있다.
얼렁뚱땅 넘어가기
설계에서 구체적인 사항을 정하거나, 뭔가를 할 때 '이 정도면 되겠지?'라는 생각으로 얼버무리고 넘어가는 일이 잦다. 자세한 부분까지 생각하지 않고 일단 무턱대고 행동하는 버릇 때문에 나중에 가서 벌어진 사태를 수습하기 마련이다. 추가 학습을 할 때도 마찬가지로 학습을 하면 정리를 하고 넘어가야 하는데 종종 대충 알고 넘어가서 결국 나중에 다시 찾아보거나 까먹게 된다. 한가지 일을 시작하면 끝을 맺고 넘어가는 연습이 필요할 것 같다.
콘솔 창으로 결과 확인하기
분명 디버거를 사용해본 적이 있지만, 콘솔창을 통해 결과를 확인하고 디버깅 하는 습관이 남아있어 디버거를 사용하지 않게 된다. 매번 Console.print()를 작성하는게 힘들지만 습관이 잘못 들어서 그런지 이 방법으로만 디버깅을 하게 된다. 나중에 더 복잡한 프로젝트를 하게 된다면 이 방법만으로는 디버깅을 하기 힘들 것을 알고 있기 때문에 천천히 고쳐나가야 할 것 같다.
S : Start
-> 새롭게 시작할 부분 또는 Stop에 대한 액션 플랜
푸쉬하기 전 전반적인 코드 확인
하나의 푸쉬를 날리기 전에 전반적으로 코드를 확인하는 습관을 들여보려 한다. 구현 목표에 해당하는 기능은 전부 구현했는지, 오류는 없는지 등 손색없는 코드인지 확인함으로써 오류 있는 코드, 미완성인 코드로 비효율적인 로그를 남기지 않을 것이다.
설계 구체화 및 기능 단위 세분화
리드미에 시간을 조금 더 투자하여 기능목록을 세분화 하고 전반적인 구조를 먼저 탄탄하게 잡고 구현을 시작할 것이다. 기능목록을 최대한 수정하지 않기 위해 노력하며 푸쉬의 수와 적힌 기능의 수 차이가 크게(1~5개) 나지 않게 해보려고 한다.
