Facts (사실, 객관)

  1. 코드숨 5주차 완료
  2. 테스트 주도 개발 1장, 2장 공부 및 실습, 3장 내용 일부 발췌독
  3. 테스트 주도 개발 1장 다중 통화 예제 짝 프로그래밍
  4. 김창준님 강의 중 정보 수집 대화에서 피해야 할 것들, 안부 묻기 에 대해 친구와 토론, 역할 연기
  5. 파이썬 개발환경(pyenv, virtualenv) 설정
  6. 커스텀 훅을 사용하는 구조와 컨테이너 컴포넌트를 사용하는 구조를 여러번 시도해보고 고민
  7. jest custom matcher 작성법 공부하고 직접 작성
  8. 더 나은 구조와 네이밍에 관해 고민하고 트레이너님께 집중적으로 리뷰받음
  9. 익스트림 프로그래밍(Extreme Programming Explained 2판) 5장 원칙까지 읽음

Feelings (느낌, 주관)

  1. 애자일에 최근 계속 관심을 두고 있었고, 이젠 익스트림 프로그래밍까지 공부하고 있다. 짝 프로그래밍과 테스트 주도 개발도 하고 있다. 처음에는 잘 이해되지 않았던 것이 점점 이해되기도 하고, 긍정적인 내적 변화가 이루어지고 있는 것 같아 기분이 좋다.
  2. 요즘 전역 직후보다는 여러모로 시간을 충분히 활용하지 못하고 있는 것 같아 괴롭기도 하고 고민이 많았다. 하지만 이제는 즐기면서 성장을 이어나가려고 한다. 예전에 계획은 자신을 제한하려고 세우는 것이 아니라 자신이 원하는 삶을 스스로에서 선물하기 위해서 세우는 것이라는 말을 들었다. 내가 시간을 사용하는 곳이 꼭 기술 습득이나 개발 공부여야 하는 것은 아니다. 다양한 경험을 하고 다양한 사람을 만나고 폭넓은 배움과 생각을 얻는 것이 중요하다는 생각이 든다. 어짜피 내가 원하는 일, 잘할 수 있는 일이 무엇인지는 알고 있으니 멈추지만 않으면 삶은 그쪽으로 흘러가게 되어있다. 복학 전까지는 이때에만 할 수 있는 일을 위주로 하려고 한다. 예를 들어 테스트 주도 개발이나 과학적 정보 수집 대화법, 글쓰기, 애자일과 익스트림 프로그래밍의 가치 등은 앞으로 시간을 내어 공부하고 연습하기 어려울 것이다. 이런 것들은 빨리 접하고 앞으로의 경험을 이용해 숙성시키는 것이 좋다고 생각한다.

Findings (배운 점)

일일 회고에 적은 내용은 다시 적지 않는다. 여기서는 한 주간 코드리뷰를 받으며 배운 점을 정리하겠다. 또 익스트림 프로그래밍을 공부하면서 배운 내용은 더 읽고 생각하고 따로 글로 작성하려고 한다.

  1. Presentational 컴포넌트의 핵심은 퓨어 컴포넌트 것이다.
  2. 커스텀 훅을 도입하는 문제는 container 컴포넌트를 도입하는 문제와 큰 관련이 없다. 커스텀 훅을 도입한다고 컴포넌트가 퓨어 해지는 것은 아니다.
  3. 처음부터 어떻게 해야겠다고 정하기보다는 TDD를 하면서 자연스러운 사고의 흐름에 따라 필요에 따라 구조를 바꿔나가는 것이 바람직하다.
  4. it을 describe의 대상으로 계속 치환해서 읽어보는게 좋다.
  5. context를 테스트 코드 리펙터링할때만 도입하는 것이 아니라 테스트 코드를 작성하면서 자연스럽게 도입할 수 있도록 하는 것이 좋다.
  6. 매서드를 만들때는 그것의 인터페이스부터 정해야하는 것처럼, 이름을 정할 때는 그것이 사용되는 곳을 고려해야한다.
  7. 이름에 내부 구현에서 드러나는 내용을 반영하는 것은 좋지 않다.
  8. 구조분해할당을 잘 활용하면 네이밍에 대한 부담을 덜 수 있다.
  9. 리덕스 툴킷을 사용하면 액션생성함수를 테스트할 필요가 없으며, 커버리지에도 영향을 주지 않는다.
  10. 테스트에도 독자가 있다. 테스트를 일종의 설명서라고 생각하면서 작성하면 좋다.
  11. 테스트에 사용되는 값은 실제 (여기에서도 그 코드가 사용되는 맥락을 고려해서) 값을 사용하는 것이 좋다.
  12. 의미상으로 구분되는 경우 빈줄을 넣어서 구분해주는 스타일을 유지하는 것이 전반적인 가독성에 좋다.
  13. beforeEach, beforeAll은 단순히 중복을 제거하려고 사용하는 것이 아니다. 따라서 테스트가 1개라도 따로 빼는 것이 좋다. before의 의미를 고려해서 코드를 읽는 입장에서 생각하면 이해가 된다.
  14. 라이브러리를 사용할 때는 그 라이브러리를 검증하는 테스트는 작성할 필요가 없다. 다만 그 라이브러리의 동작을 학습하기 위해 테스트를 작성할 수는 있다.
  15. redux-mock-store 참고 링크
  16. mock하는 부분은 (당연히 상황에 따라 다르지만) 이왕이면 테스트코드에 함께 두는 것이 좋다.
  17. 테스트 픽스쳐는 테스트를 위한 최소한의 내용만 담아야한다. 그래야 의도가 잘 드러나고, 원하는 대로 테스트됨을 더 확신할 수 있다. 뭐든 필요한 것만 필요할 때 작성해야한다.

Affirmation (자기 선언)

  1. 나는 계속 배우고 성장하는 사람이다.