🎯 이번주 Action Plan 회고하기

• 페어 프로그래밍을 진행하며 페어에게 배울 점과 아쉬운 점을 찾는다.
• 나를 포장하려고 하지 말기. (우테코는 나를 인정하고 그냥 자신의 모습대로 살아가도 괜찮다는 걸 실험해볼 수 있는 공간이니까)

1. 페어 프로그래밍 피드백
   페어 프로그래밍을 하면서 페어의 특징을 따로 기록할 시간은 없었지만, 장점은 계속 말로 반복해서 알려줬다. 그렇게 하면 나도 자연스럽게 기억할 수 있었고, 개선이 필요한 부분은 슬쩍 노트에 적어두었다.

2. 나를 숨기지 않기
   이번 주는 유강스를 기점으로 나의 단점을 있는 그대로 드러내고, 함께 개선해 나가는 시간을 가졌다. 아직 완전히 자연스럽진 않지만, 나를 숨기지 않으려 노력하는 중이다.

---

🎯 아직 진행 중인 Action Plan

• 누군가 물어봤을 때 제대로 설명하지 못하면 온전히 내 것이 아니다.
  👉 설명하다가 막히는 개념 최소 1개는 개념 리스트에 추가하고 정리하기. (진행 중)
• 헷갈리는 개념이 있을 때 코치에게 최소 1번 이상 질문하여 내 생각을 견고히 하기. (진행 중)

🍵 이번주의 생각 1: 로또 미션을 진행하며 느낀 점

로또 미션을 진행하면서 고민한 부분이 많았지만, 미리 정리해두지 않아서 제출할 때 어려움을 겪었다. 결국 생각나는 것들을 정제하지 않고 그대로 작성해 제출하게 되었는데, 이것이 오히려 독이 될 수 있다는 생각이 들었다.

내 사고 과정을 함께 공유하지 않았기 때문이다.
조금만 고민하다가 답을 찾지 못하면 바로 질문을 보냈고, 그러다 보니 자연스럽게 질문이 많아지면서 리뷰어에게 의존하는 경향도 생겼다.

앞으로는 고민한 내용 중 절반 정도는 내가 찾은 답과 함께 제출하는 연습을 해야겠다.
리뷰어가 제시하는 방향도 중요하지만, 스스로 사고하는 과정을 놓치지 않는 것이 더 중요하다.
리뷰에 의존하여 사고 과정이 단축되지 않도록 주의해야겠다.

🍵 이번주의 생각 2: 현직자와 대화에서 얻은 인사이트

오랜만에 현직에 계신 진범님을 만났다.
레벨 1과 2에서 진행한 내용이 기본적인 개념이라 포트폴리오에 활용하기 어렵다고 생각했는데, 대화를 나누면서 관점이 달라졌다.

물론, 단순한 자바스크립트 개념(예: 호이스팅 개념 적용)은 포트폴리오에 넣기 어렵다.
하지만 컴포넌트 분리 기준, OOP와 FP 선택 기준, 구조 개선 과정과 같은 내용은 나만의 기준을 확립하는 과정이기 때문에 레벨에 상관없이 잘 정리해야겠다고 생각했다.

또한, 다음 레벨로 넘어가면 자바스크립트의 기초 개념을 다시 공부할 시간이 없을 것이다.
따라서 지금 호이스팅, 클로저, 이벤트 루프 같은 핵심 개념을 탄탄히 다져두어 기술 면접에 미리 대비해야겠다.

🪵 간단한 모닥불

🔥 E2E 테스트 VS 통합 테스트

테스트 피라미드를 보면 "단위 < 통합 < E2E" 순서로 되어 있다.
그런데, 왜 E2E가 통합 테스트를 포함하는 개념이지?라는 고민을 했다.

나는 통합 테스트를 단위 테스트를 연결하여 전체적인 흐름이 정상적으로 동작하는지 확인하는 테스트라고 생각했다.
그런데 미션을 진행하며 E2E 테스트를 해보니, 통합 테스트보다 더 작은 단위의 테스트를 수행할 때도 있었다.
심지어 너무 작아서 "이거 단위 테스트 아닌가?" 싶을 정도로 느껴졌다.

그래서 내린 결론은, E2E 테스트는 '시나리오'를 세워서 '시작'과 '끝'이 있는 테스트다.
즉, 내가 정의한 시작과 끝을 기준으로 시나리오가 존재한다면, 그것은 E2E 테스트라고 볼 수 있다.

🔥 클래스에서 메서드가 필드를 사용할 때, 필드를 this로 가져다 쓸까? 인자로 넘겨줄까?

이 부분도 고민해볼 필요가 있다.
필드를 직접 this로 가져다 쓰면 객체 내부에서 편리하게 접근할 수 있지만, 의존성이 커질 위험이 있다. 그럼 테스트 코드를 작성하기가 어렵다.

반면, 인자로 넘겨주면 의존성이 줄어들지만, 메서드 호출 시 매번 전달해야 하는 번거로움이 생긴다.

아직 어떤 상황에 어떤 것을 써야할 지 고민이다.

🔥 상태를 전역으로 관리하지 않는 방법은?

내가 상태를 파일의 상단에 선언해놓고 파일 내에서 자유롭게 쓰고 있었다. 그리고 이게 나쁜 방법은 아닐까?에 대해 고민하고 있었고 리뷰어는 나에게 이런 질문을 했다.

• ❓ 헤일리가 생각하는 전역의 범위는 어디까지인가요?
• ❓ 왜 해당 상태를 현재의 위치에 둘 수밖에 없었나요?
• ❓ 현재 이 상태를 참조할 수 있는 범위는 어디까지인가요?

내가 생각하는 전역 범위는 파일 전체다.
즉, 해당 파일 내에서는 어디서든 읽고 쓰는 것이 가능하다.
(단, let, const로 선언했기 때문에 window 객체에는 등록되지 않는다.)

이렇게 한 이유는, 해당 파일 내의 함수들이 이벤트 리스너를 통해 호출되는데,
이 함수들이 서로 연결되어 있지 않아서 전역으로 선언하지 않으면 값을 공유할 수 없기 때문이었다.

그래서 전역으로 선언하여 쉽게 값을 공유하도록 했는데,
그렇게 하면 어디서든 값이 변경될 수 있다는 문제가 발생할 수 있었다.

👉 그래서 STEP 1에서 클래스를 사용하여 상태를 관리하는 방향으로 스코프를 한정하는 방식으로 수정했다! 50b5432

다만, 이 클래스를 다른 파일로 분리하는 것이 애매해서 step2-index.js에 두었다.
이 부분도 더 고민해볼 필요가 있을 것 같다.

🔮 그냥 해보고 싶은 것..

• Toss/Slash 코드 보면서 선언형으로 작성한다는 것이 무엇인지 체감해보기.

🎯 다음주 Action Plan 은?

• 평일에 모은 키워드는 주말에 3시간 동안 집중 학습하기.
• 데일리 미팅에서 의견을 말할 때, 긴 글을 읽지 말고 키워드만 보고 사람들을 보면서 말하기.
  • (글을 정리해서 읽으면 오히려 시선이 글에만 집중되고, 횡설수설할 위험이 있음.)
• 말을 할 때 해명하지 않기.
  • (잘한 점을 말할 때, 쓸데없이 겸손하려고 해명하다 보면 말의 본질이 흐려지고, 나도 내가 무슨 말을 하는지 모르게 됨.)
  • 그냥 사실만 말하기.