[사다리 타기 미션] 학습 내용 정리

사다리 타기 미션

🫡 구현 시  집중한 부분

1. TDD

테스트를 먼저 작성하고 기능 구현 후 리팩토링하는 과정

TDD는 사이클을 반복하여 구현하는 것을 말한다.

 

[개인적으로 느낀 장점]

• 그동안 나는 설계 단계에서 도출한 객체와 구조를 최대한 바꾸지 않도록 하려고 고민했었지만 스스로 스킬이 부족하다는 생각에 빠져있었는데, TDD는 초기 설계에 집착할 필요가 없어 심리적으로 편했던 것 같다.
• 정말 요구사항에만 있는 행위들만 테스트하고, 구현하기 때문에 불필요한 행위들이 추가적으로 구현되지 않았다.

2. 제어할 수 없는 부분 테스트

|-----|-----|-----|

 

처음 사다리를 구현할 때, 하나의 세로 줄을 Line이라는 객체를 통해 구현하고 객체 안에서 경로가 있는지 없는지를 나타내는 List<Boolean>를 Random으로 생성하여 가지고 있도록 설계했다.

 

그런데 요구사항 중 "사다리 타기가 정상적으로 동작하려면 라인이 겹치지 않도록 해야 한다."라는 부분이 있었기 때문에, 

이를 List<Boolean>에서 true가 연달아 나오는가?를 테스트하여 기능을 구현하고자 했다.

 

처음 코드는 List를 순회를 하면서 테스트 하도록 작성했다.

        // 수정 전의 LineTest.java
        Line line = new Line(personCount);
        for (int i = 0; i < personCount - 1; i++) {
            assertThat(line.get(i)).isNotEqualTo(line.get(i + 1));
        }

하지만 위 테스트는 제어할 수 없는 Random 때문에 신뢰할 수 없는 테스트라는 생각이 들었다...!

때문에 Line에서 랜덤하게 List<Boolean>를 생성하는 것이 아닌, 외부에서 주입받고 Ladder에서 전달을 하도록 했다.

또 Ladder에서 Random을 그대로 사용하기보다는 인터페이스를 받아서 상황에 따른 구현체를 사용하도록 수정하였다.

📖 미션을 진행하면서 학습한 것들

1. 서식 지정자

System.out.printf()

➡️ 출력 값을 서식에 맞춰서 출력할 수 있다.

주요 서식 지정자

서식 지정자 출력 데이터 형태

%c 하나의 문자

%s	문자열
%f	고정 소수점으로 표현한 실수
%o	부호 없는 8진 정수

 

2. 제네릭 타입 소거

제네릭은 컴파일 타임에만 타입 체크가 가능하고, 런타임에는 타입이 소거되기 때문에 타입 정보를 알 수 없다.

 

따라서 아래 코드를 구분하지 못한다.

Line(final List<Boolean> points) {}
Line(final List<Point> points) {}

3. static final과 상수

scanner는 상수일까?라는 생각에서 시작되어 static final은 항상 상수일까라는 생각까지의 나의 생각과 찾은 답을 정리한 글을 첨부한다.

https://mincanit.tistory.com/56

static final 변수는 항상 상수일까?

4. 매직 넘버

매직넘버란, 하드 코딩된 숫자를 말한다.

 

코드에서 매직넘버를 사용하게 되면, 의미를 파악하기 어렵고 요구사항이 변경되어 숫자의 값이 변경되었을 경우, 유지보수하기 어려워진다.

때문에 매직넘버를 사용하는 것보다는 의미 있는 상수를 사용하여 대체하는 것이 좋다.

---

수업 피드백

1. 컨벤션 준수

컨벤션 지키기는 어려운 게 아니다. 기본적인 것이다.

 

리뷰어들은 리뷰이가 흡수할 수 있는 10가지 정도만 리뷰하는데, 컨벤션 안지키면 컨벤션 리뷰만 받게 된다.

양질의 리뷰를 받고 싶다면 컨벤션 지키는 최소한의 성의를 보이자

https://google.github.io/styleguide/javaguide.html

Google Java Style Guide

2. TDD와 도메인

일단 큰 단위라도 구현해보면서 객체로 분리할 수 있는 것들을 찾기

객체 분리의 이유는 역할을 가지고 있는가, 책임을 가지고 있는가이다.

 

도메인에 대한 이해가 어느정도 된다면?

확실히 필요한 객체부터 테스트 시작하자.

이때, 객체의 상태보다는 어떠한 역할을 가지는가를 테스트하자.

 

도메인 설계에서 Object Graph 중 가장 마지막 노드(의존성을 가지는 객체가 하나도 없는 객체)부터 구현을 시작하는 것 이 TDD로 접근하기 수월하다.

👩‍💻 코드 리뷰

1. 파일끝에 개행을 추가해야 하는 이유

파일 끝에는 new Line을 추가해주어야 한다는 피드백을 받았다.

결론부터 말하자면 이유는 그게 표준이다.

IEEE라는 곳에서 텍스트 파일은 행의 집합이며 행은 반드시 개행으로 끝난다고 정의했기 때문에 그것을 따라야 하는 것이다.

 

2. 패키지 위치

이번 미션에는 출력에서 포매팅이 필요한 부분이 여러개 있었는데, 때문에 각 도메인에 대해 Formatter 클래스를 만들었다.

formatter라는 패키지에 각 클래스를 담았는데, 리뷰어께서 아래와 같은 피드백을 주셨다.

 

view 을 위한 객체이니 view 패키지에 위치시키는것은 어떻게 생각하시나요?

패키지를 사용처와 가장 관련된 곳에 위치시키면, 다른 개발자가 봤을 때 어디서 사용되는지 바로 눈치챌 수 있다.

 

패키지의 위치도 신경쓰도록 해야겠다!