어쩌다보니, 크론이 아닌 왼손에게 원오원을 신청하게 됐다. 다음주 화요일에 왼손에게 회고를 잘하는 방법에 대해 물어볼 예정이다. (질문이 막연하지만 일단 물어보고 어떤 아이디어라도 얻을 예정이다.)
두 번째 Action Plan은 목표가 모호해서 잘 해내지 못한 것 같다. 좀 더 구체적으로 다음과 같이 목표를 바꿨고, 이번주에 다시 도전할 예정이다.
누구의 리뷰까지 반영해야 할 지 고민이다. 지금까지는 나의 리뷰의 의견만 반영했다. 그리고 시간이 된다면 페어의 리뷰도 반영했다. 그런데 오늘 다른 크루의 리뷰도 보게 되면서 내가 고칠 점이 끝도 없다는 것을 알게 되었다. 그래서 이것도 반영하고 싶은 욕구가 들었다. 그런데 내가 짠 코드가 아니다 보니 보다보면 시간이 많이 들 것 같았다.
나는 어디까지 반영해야 할까? 이것들을 모두 반영하면 지칠 것 같고, 또 반영하지 않자니 뒤쳐지는 것 같다. 나는 어떤 기준을 가지고 앞으로 미션을 해야할까?
사실 지금, 리뷰 반영 뿐만 아니라 어떤 책을 읽고 어디까지 공부해야 할 지도 모르겠다 😭
일단 지금 내린 결론은 다음과 같다.
포코의 조언:
1. 뭘 모르는지 잘 정리하는 방법이 필요하다.
- 뭘 모르는지 파악하고 이건 지금 공부하지 말아야지 버리는 선택을 할 줄 알아야 한다.
- 무언가 공부를 안하면 불안해할게 아니라, 다른 공부에 집중할 수 있다는 뜻이기도 하다.
2. 필요한 것부터 공부하는 방법이 필요하다.
- 내가 뭘 모르는지 아는 것이 우선이고, 모르는 것을 채우면서 공부해야 한다. (⇒ 키워드 위주의 학습 방법)
- 당장 공부할 필요가 없는 것은 미뤄두는 것이 필요하다.
요약
: 뭘 모르는 파악하자 👉 가장 모르는 것을 파악하자 👉 채우자(필요한 것부터 공부하자)
객체 지향의 사실과 오해
책의 마지막 챕터를 읽으며 깨달은 점이 있다.
지금까지는 Controller에서 모든 중계 역할을 해야 한다고 생각했는데, 그럴 필요가 없다는 것이다.
예를 들어, 이런 식의 흐름이 있다면, 손님 👉 바리스타 👉 기계
나는 모든 👉
부분을 Controller가 하게 했고 비대해졌다. 하지만 생각해보니 가능하다면 각자의 내부에서 요청해도 되는 것이었다. Controller의 역할은 UI와 Model의 연결을 도와주는 것이기 때문에 모델끼리의 상호 작용까지 모두 해줄 필요는 없었다.
페어 프로그래밍이 끝나고 나서 페어에게 리뷰를 주니까, 과정이 어땠는지 기억이 잘 않았다. 평소에 페어를 관찰하고 배울 점과 아쉬운 점을 기록해야겠다.
질문: 왜 명령형보다 선언형을 지향할까?
답변: 코드가 간결해진다. 가독성이 올라간다. 내부에 어떻게 설계했는지 줄줄이로 쓰게 되면 side effect가 생길 확률이 올라간다.
시지프: 정말 class 안쓰고 짜도 됩니다! class 는 결국 생성자 함수라는 거.. JS 에서는 생성자 함수나, 객체만 활용해서 짜도 충분할 수 있어요.
항상 console.log로 디버깅을 해왔다. 아래 방법으로 디버깅하는 법도 궁금하다.