👨‍🚀 첫 주차, 끝

첫 주차가 끝났다. 이번주는 자동차 경주 미션을 구현했다. 1단계, 2단계가 있었고, 1단계는 페어 프로그래밍으로 진행했다. 미션 자체는 이미 해봤던 문제라서 미션 프로그래스에 적응하는 기간이었다.

• 1단계 - 자동차 경주 기능 구현 (페어 프로그래밍)
• 2단계 - 자동차 경주 리팩터링 (개인)

👨‍🚀 Lv.1 공통 목표

레벨 1의 목표를 리마인드 해보자.

1. 요구 사항을 지키며 경험치 쌓기
   • 예) 테스트도 해보며 구현 역량 늘리기
2. 언어 이해 및 개념
   • 예) 생성자에서 안 쓰고 프라이빗으로 하면 어떻게 동작하는 걸까?
3. 마인드 셋과 소프트스킬
   • 예) 페어랑 어떻게 소통하면, 함께 잘할 수 있을까?
   • 예) 어떻게 피드백하면 좋을까?
   • 예) 어떻게 리뷰하면 주고 받으면 좋을까?
   • 예) 어떻게 내가 개발한 것의 의도를 전달할까?

👨‍🚀 이번주 핵심 질문

1. 왜 도메인 로직은 domain/ 하위로, UI 관련 로직은 view/ 하위로 관리하는 요구사항이 있을까요?
2. 도메인 로직은 UI 로직에 왜 의존하면 안될까요?
3. 왜 미션 요구사항에 테스트 코드의 mock을 제거하는 게 있을까요?
4. mock은 어떨 때 사용하는 게 좋을까요?
5. 이렇게 요구사항대로 하시면서 느낀 효용성이 있을까요?

👨‍🚀 인상 깊었던 일

🚀 큰 문제는 작게 쪼개자

"막연하다면, 9명이니까 3명으로 나눠서 주제를 정해보세요. 그리고 다시 9명이 모여서 합쳐보세요."

데일리 미팅을 처음해서 막연할 때, 코치인 준이 한 말이다. 막연하게 큰 문제를 작게 쪼개서 해결한 것이다. 일상에서도 프로그래밍 적으로 문제를 해결할 수 있다는 것을 느꼈다.

🚀 '내 기준에서는 이게 좋은 것 같다'라는 기준을 만들자

우테코에서 제공해주는 모든 강의, 자료, 조언에 정답은 없다. 심지어 코치마다 해주는 조언이 다르다. 결국에 이 모든 것을 가지고 나만의 방식을 찾는 게 나의 임무이다.

충분한 시행착오를 겪으며 '내 기준에서는 이게 좋은 것 같다'라는 기준을 만들자.

코드 리뷰 과정에서 리뷰어, 페어의 의견을 절대적으로 수용하지 말자. '왜 그렇지?'라는 의문을 가지며 설득도 해보고 설득도 당해보자.

'내가 테스트코드를 쓰면서 느꼈던 가장 중요한 강점은 뭘까?' '나는 테스트 코드를 짤 때 무엇을 가장 신경쓸까?' 라는 질문을 스스로에게 던지면서 나만의 정답을 찾아가면 되겠다.

👨‍🚀 기술적으로 배운 점

🚀 테스트는 뭘까?

• 테스트는 품질을 확인하고 보장하기 위한 작업이다. 테스트를 직접할 수도 있고 자동화할 수도 있다.
• 우리는 꼭 정상 케이스만 테스트할까? 예외 케이스도 테스트한다. 문제가 생겨야 할 때 잘 생기는지도 확인해야 한다.

🚀 UI와 Domain을 구분할 수 있을까?

• 자동차 경주를 예로 들면, Domain은 자동차 경주에 관련된 문제를 해결하기 위한 영역이다. 입출력 영역이 아니다.
• Domain을 구현하면서 UI를 함께 구현하지 말자. 예를 들어, 유효성 검증을 구현할 때 유효성 검증을 하는 부분은 Domain이지만, 안에 에러 메시지를 출력하는 부분은 UI이다. 경계를 명확히 하자.

🚀 클래스 내에서 get을 쓰는 것은 무조건 나쁠까?

get을 지양하라는 말을 자주 들었다. 그 이유가 무엇일까 고민해봤다.

우선, 클래스 내 변수를 public으로 선언하면 외부에서 직접 접근할 수 있지만, private으로 선언하면 직접 접근이 불가능하고 get 메서드를 통해서만 값을 가져올 수 있다. 그렇다면 private을 유지하면서도 외부에 값을 안전하게 전달하는 방법은 무엇일까?

어떤 값이든 외부로 노출해야 하는 상황이 분명히 존재한다. 그렇다면 단순히 get을 사용하면 되는 것 아닐까? 무조건 막을 이유가 있을까?

내가 생각하는 핵심 조건은 두 가지다.

1. 해당 변수를 포함한 클래스가 본연의 역할을 다한다.

   • 즉, 값을 가져오는 쪽에서 이 클래스의 책임을 빼앗지 않는다.

2. 해당 값이 불변성을 보장한다.

   • 값을 변경할 필요가 없고, 변경될 위험도 없다.

이 두 가지 조건을 만족한다면 get을 통해 값을 제공하는 것도 충분히 합리적이라고 생각한다.

🚀 테스트로 어느 범위까지 확인해야 할까?

• 모든 케이스가 그렇지 않지만, 경계값만 확인해도 좋다.
• 예를 들어, 자동차 이름은 5자 이하여야 한다면 5와 6만 확인한다. 0부터 4까지는 안해도 당연히 된다고 생각하는 것이다.
• 예들 들어, 공백은 안된다고 하면 0과 1만 확인한다. 2부터 4까지는 경계 범위에 있지 않기에 생각하지 않는다.

🚀 테스트를 하는데 의존성 때문에 테스트가 어렵다? 목킹을 해도 되는 가?

• 테스트를 하는데 의존성 때문에 테스트가 어렵다면, 목킹을 하지 말고 의존성이 생기는 아이를 밖으로 분리하자. 그리고 그 분리된 부분을 어디에 놓을 지 위치를 고민해보자.
• 예를 들어, 랜덤 값 생성 부분에 의존성이 생기는 함수가 있다면, 랜던 값 생성 부분을 분리한다. 그리고 그 함수는 해당 클래스 안에 두지 않고 유틸함수로 뺄 수 있다.
• 하지만 아무리 해도 의존성이 안 빠진다면, 그럼 그 영역까지 무리해서 테스트하지 않는다. 모든 영역을 테스트할 필요없기 때문이다.
• 랜덤 값을 뽑아내는 걸 굳이 테스트해야 하는가?
  • 우린 자동차가 정해진 범위의 숫자를 받으면 전진하는지만 테스트하면 된다.

👨‍🚀 Action Plan

🚀 1. 이번 달 안에 코치인 크론에게 원오원 신청하기

나는 회고를 좋아한다. 그래서 이렇게 회고 글도 쓴다. 야생학습은 '내가 할 수 있는 모든 수단을 해보는 것'이다. 회고를 위해서 야생학습 정신으로 이번 달에는 코치인 크론에게 원오원을 신청해보겠다.

🚀 2. 다음주 미션에서 리뷰어를 덜 수고롭게 하기

리뷰어(동료)는 바쁘다. 그러니 셀프체크를 하고 리뷰를 요청하고, 친절하게 하고, 명확하게 설명이 필요하다.

실행 방법, 실행 결과, 기능 명세서, 고민했던 점, 질문 등을 첨부해서 리뷰어가 바쁜 상황에서도 빠르게 리뷰할 수 있도록 한다.

👨‍🚀 추가 학습 리스트

• Jest를 사용해서 테스트 코드를 작성할 때, 리팩토링 시에 안 써본 Jest 함수를 사용해보기. 예를 들어, beforeAll, beforeEach 등.

🍵 마무리

오늘 준과 함께 점심을 먹었다. 준을 통해 프로그래머의 길을 걷기 시작했기 때문에 역사적인 날이었다. 존경하는 사람 밑에서 배울 수 있다는 게 너무 행복하다.

나의 올해 목표는 '나에게 다정하기, 남에게 다정하기'이다.
그래서 나의 팀원, 페어, 코치, 모두에게 다정하고 싶다. 예를 들어, 페어가 PR을 잘 제출했는지 챙겨주고, 생일인 팀원이 있으면 먼저 축하해주고, 코치님께 먼저 인사하고. 조금의 센스로 모두를 따뜻하게 할 것이다. 그리고 다정은 체력에서 나온다는 말이 있으니 운동도 계속 꾸준히 할 생각이다.

나에게 다정할 수 있는 방법은 아직 찾고 있지만, 나를 타인으로 생각하고 함부로 대하지 않을 것이다. 칭찬하고 격려하고 존중하며 지켜줄 것이다.

• 다음주 액션 플랜
  • 이번 달 안에 코치인 크론에게 원오원 신청하기
  • 다음주 미션에서 리뷰어를 덜 수고롭게 하기