위클리 우테코 1. 자동차 미션 1단계

Hyunta·2022년 2월 20일
0

위클리 우테코

목록 보기
1/18

자동차 경주 미션 회고

느낀점

  • 구현한 경험이 있는 미션이었기 때문에 부담이 별로 없었지만, TDD와 Pair 프로그래밍을 처음 해봤기 때문에 신경쓸 것들이 많았다.

  • git을 활용하는게 익숙치 않아서 힘들었다. 페어 프로그래밍을 하는 중에도 어떻게 다시 repository에 commit log를 받아올 수 있을까 걱정이 있었다.

  • 모든 기능에 대해 테스트를 구현하려다보니 기존 방법대로 코드를 구현했을 때 테스트하기 난감한 경우들이 생겼다.

    • Cars 에서 랜덤값을 생성하고 4 이상일 경우 전진하고, 4 미만일 경우 정지하는 기능을 한번에 구현을 했더니 랜덤에 대한 테스트가 막막해졌다.

    • Cars 에서 우승자를 찾는 기능을 테스트할 때 새로 생성하는 Cars 인스턴스의 위치값을 임의로 조작할 수 없어서 테스트할 수 없었다.

  • 페어와 프로그래밍을 하다보니 기존에 습관적으로 쳐왔던 코드들에 대해 재해석하고 상대방을 설득시키기 위해서 찾아보고 복습하는 시간이 잦았다. 그만큼 내가 알고 있던 내용들이 부실했다는 것을 깨달았고, 상대방의 구현방식에 의문을 가지면서 서로 성장할 수 있었다.


구현 피드백

1. Random에 대한 테스트

    public void move() {
        if (makeRandomNumber() >= 4) {
            position++;
        }
    }

랜덤값이 4 이상일 경우 자동차를 전진하고, 4 미만일 경우 자동차를 정지시키는 메서드이다. 이렇게 구현했을 때 기능상 문제는 없지만, move() 내부에서 랜덤값을 생성하기 때문에 테스트하기가 어렵다.

    public void move(int value) {
        if (value >= 4) {
            position++;
        }
    }

아래와 같이 코드를 수정하니 move에 대해서 테스트하기가 훨씬 수월해졌다.

2. 응집성이 높은 코드

  • 극단적으로, 클래스의 모든 필드가 getter로 노출되어있다면 어떻게 될까요?

  • static method는 어떻게 활용해야하는가? 사용하지 않는 것이 항상 좋은가?

getter를 과도하게 사용하면 일어나는 일, static 메서드를 자주 사용하게 되면 발생하는 구조에 관해서 질문을 드렸었는데 응집성이 높은 코드에 대해 조언을 해주셨습니다. 코드를 객체지향적으로 설계하게 된다면 특정 도메인과 관련된 핵심적인 로직들이 한 곳에 모여있을 수록 좋은 소프트웨어라고 합니다. 네오의 강의에서 static 메서드를 util성향이 강한 메서드에 활용하라고 했는데 도메인에 넣을 수 있다면 넣는것이 응집성이 강한 코드라고 생각합니다.

3. 테스트하기 좋은 메서드는 어떻게 만드는가?

메서드가 테스트하기 어렵다면, 메서드가 분리가 가능한지 확인해본다. 테스트를 위해서 코드를 추가하는 경우는 가급적 피해야 한다. 자동차 경주와 관련된 로직을 수행할 때 이 컬렉션을 통해 필요한 객체를 가져다 쓴다는 아이디어에서 시작해보시면 어떨까요?

4. 요구 사항이 콘솔 출력에서 웹 페이지 출력으로 바뀐다면 toString 의 반환값을 html로 나타내야할까?

toString 을 통해 최대한 객체의 중요필드들을 보여줘야한다. 출력형태에 대한 책임은 view에서 다루도록 하자.
아이템12. toString을 항상 재정의하라

profile
세상을 아름답게!

0개의 댓글