[우아한 테크코스] 프리코스 4주차 회고

🍀 고려한 부분들

1. 테스트 네이밍 규칙

https://dzone.com/articles/7-popular-unit-test-naming

7 Popular Strategies: Unit Test Naming Conventions - DZone Agile

github discussion 에서 한 분이 공유해주셔서 참고했던 글이다.

 

이전까지는 테스트코드의 메서드명까지 신경써야겠다는 생각을 못해서 별다른 네이밍 규칙 없이 떠오르는 대로 메서드명을 지었었다. 그나마 규칙이 있다면 내가 사용했던 메서드명의 형태는 check + 확인하고자 하는 메서드명이었다. 그러나, 이렇게 될 경우에는

1. 메서드명을 리팩토링하거나 메서드의 역할을 수정할 때마다 테스트코드의 메서드명도 함께 수정해줘야 한다는 불편함이 있었다.

2. 또한, 이런 오류들은 컴파일 오류도 아니라서 내가 일일이 확인하고 수정해야 해서 놓치기 쉽다는 문제점이 있었다.

 

따라서 이번 주차에는, 아래의 규칙을 따라 테스트 메서드를 네이밍했다. 

is + 테스트할 기능 + (인자가 있다면) with ____ 이러한 형태로 진행했다. 

 

 

2. 반복되는 문자열을 효율적으로 활용해보자

 

이전주차에서는 [ERROR] 이라는 prefix 를 상수로 두고 단순 문자열 더하기 연산을 통해서 에러 메시지를 출력했다. 그러나 정말 이가 최선일지 의문이 들었다. 따라서 이번 주차에는 ErrorStatus 라는 Enum 을 두고, message 라는 멤버 변수를 두어 문구 반환 시에 [ERROR] 을 붙여서 반환하도록 했다. 이렇게 하니, 출력 형태는 지키면서도 에러 메시지 자체에 대한 수정과 하드 코딩 없이 해결할 수 있었다.

 

package bridge.validator;

public enum ErrorStatus {
    BRIDGE_SIZE_TYPE_ERROR("다리 길이는 정수만 입력 가능합니다."),
    BRIDGE_SIZE_RANGE_ERROR("다리 길이는 3부터 20 사이의 숫자여야 합니다."),
    BRIDGE_SIZE_BLANK_ERROR("다리 길이는 공백으로 둘 수 없습니다."),
    DIRECTION_SIGN_ERROR("이동할 칸은 U 혹은 D 만 입력 가능합니다."),
    GAME_COMMAND_SIGN_ERROR("재시작 여부는 R 혹은 Q만 입력 가능합니다.");

    private final String message;

    ErrorStatus(String message) {
        this.message = message;
    }

    public String getMessage() {
        return "[ERROR] " + this.message;
    }
}

 

3. static 키워드를 함부로 사용하지 않기

 

이번 주차에서 우아한 테크코스 측에서 미리 주어진 클래스가 이전 주차보다 확연히 많았고, 제한 사항도 늘어났다. 이 중 가장 인상적이었던 것은 OutputView 와 InputView 를 static 메서드로 사용하지 못하게 한 것이었다. 나의 경우에는 이전까지는 모델, 컨트롤러 가 아닌 경우에는 거의 다 static 으로 메서드를 두고 사용했었다. 그러나 이러한 제한 사항을 보며 static 을 남발해서는 안되는 것이었겠구나. 하는 생각이 들었다. 그래서 static 키워드가 어떤 단점이 있을지 찾아보았다.

 

https://velog.io/@yyy96/static

static 과 객체지향적 관점

 

1. 메모리 낭비

2. 캡슐화에 위반되는 키워드

- 캡슐화는 한 객체가 지니고 있는 데이터들을 외부에서 접근하지 못하도록 해야 하는데 전역변수이기 때문에 이를 지킬 수 없다.

3. 재사용성이 떨어진다. (interface 에 사용될 수 없음)

 

따라서 이번 주차에는, static 메서드의 사용을 줄이고 최대한 인스턴스 변수로 객체들을 주입받아 메서드를 사용할 수 있도록 노력했다. 또한, InputView, OutputView 의 경우에는 현재는 단 두개만의 view 가 존재하기 때문에 static 으로 사용해도 무관했었지만(객체를 생성하지 않고 사용할 수 있어야 한다고 생각했었다.) 컨트롤러가 여러개가 되고 view 도 여러개가 될 경우에는 컨트롤러마다 알맞는 view 를 주입시켜 주는 것이 맞는 수순이라는 생각도 했다.

 

4. 인터페이스를 사용하여 재사용성을 높이기

 

요구 사항이었던 메서드의 길이가 10라인을 넘어가지 않기 라는 조건을 만족시키기 위해서 메서드를 분리하는 리팩토링 과정을 거쳤다. 이 과정에서 메서드마다 중복되는 코드를 뽑아내어 다른 메서드로 분리하게 되었고, 이 과정에서 validator/ 의 클래스들을 인자로 받아야 하는 상황이 되었다. 이 과정에서 고민을 했던 것이, validator 마다 다른 메서드를 만들어줘야 하는가? 였다. 코드도 똑같은데 단순히 인자가 다르다는 이유로 그런 과정을 거쳐야 하는 것일까? 하는 의문이 들었다. 그래서 Validator 라는 인터페이스를 두고, BridgeSizeValidator, DirectionValidator, GameCommandValidator 들이 모두 해당 인터페이스를 구현하도록 했다. 이렇게 하니, 인자를 Validator 라는 인터페이스로 묶어서 받을 수 있게 되었다.

 

private String readInputValue(Validator validator) {
        String inputValue;
        do {
            inputValue = Console.readLine();
        } while (!validateInputValue(inputValue, validator));
        return inputValue;
    }

또한, 기존의 해당 validator 클래스들은 모두 validate 라는 메서드를 갖고 있었다. 따라서 인터페이스에서 validate 메서드를 구현하도록 강제하게 했다.

 

public interface Validator {
    void validate(String input);
}

 

5. 커밋 메시지 작성 시 body 를 적극 활용

 

이번 주차에는 커밋 메시지에 body 를 적극적으로 활용하여 작성하고자 했다. 

 

특히 refactor 의 경우, 코드를 리팩토링 할 당시에는 리팩토링의 이유가 타당하다고 생각하여 진행하지만 추후에 다시 들여다봤을 때에는 어떤 부분이 어떤 이유로 수정됐는지 잘 파악되지 않았었기에 이번주차에는 이를 개선하기 위해 위와 같이 자세하게 body를 작성하고자 노력했다.

 

5. @ParameterizedTest 를 이용

테스트코드도 코드다 라는 지난 주차 피드백을 확인하고, 반복적인 코드를 지양하기 위해서 피드백 문서를 참고해 해당 어노테이션을 활용했다. 

 

🍀 소감문

 

이번 주차와 저번 주차의 가장 큰 차이점으로 느낀 것은 제약사항이 많아졌다는 점이었습니다.

 

1. 미리 주어진 코드가 상대적으로 많아졌다.

2. 메서드 라인을 10줄 이내로 제한해야 한다.

 

그 중, 첫번째와 관련하여 이번 주차에 학습한 것은 static 키워드 사용을 자제해야 한다는 것이었습니다. 우선, 이전 주차까지는 controller 와 model 을 제외하고는 모두 static 메서드로 두어 객체를 따로 생성하지 않고 사용해왔습니다. 이렇게 해왔던 이유는 유틸리티 메서드이기 때문이고, 클린코드를 위해서는 인스턴스 변수를 3개 이내로 두는 것이 좋은데 해당 객체까지 모두 인스턴스 변수로 두게 되면 인스턴스 변수가 너무 많아질 것을 우려했기 때문이었습니다. 그러나, 이번주차에는 특히 view 에 속한 메서드들을 static 메서드로 수정할 수 없게 되어 있어 왜 이렇게 우아한 테크코스 측에서 제한 사항을 두었을지 고민해보았습니다. static 메서드가 혹시 치명적인 단점을 안고있나? 하고 찾아보며 이가 객체지향적이지 않음을 학습했습니다. 따라서 최대한 이를 지양하며 코드를 짜고자 노력해봤습니다. 또한, 10줄 이내로 메서드 라인을 줄여야 하기 때문에 메서드마다 공통적인 코드를 뽑아내는 연습을 하게 되었습니다. 이 과정에서 유효성을 검사하는 클래스들을 하나의 타입으로 묶어 인자로 받아야 하는 경우가 발생했습니다. 따라서 유효성 검사하는 클래스들이라는 특성을 살려 해당 클래스들이 모두 하나의 인터페이스를 구현하도록 하여 코드의 재사용성을 높일 수 있었고 클래스의 분리와 명확한 역할의 분류를 할 수 있게 되었습니다. 또한, 논리적으로 따져 봤을 때도 같은 역할을 하는 클래스들이 같은 형태의 메서드를 구현하는 것이 맞다고 판단했습니다. 이를 통해 인터페이스는 이런 이유로 사용하는구나 체감할 수 있었습니다. 

 

이렇게 리팩토링을 거치는 과정에서 학습하는 부분이 많았으나 어떤 이유로 리팩토링을 진행했고, 어떤 부분이 수정되었는지 까먹기 일쑤였습니다. 따라서 이번 주차에는 깃헙 커밋 메시지의 바디 부분을 적극적으로 활용하여 수정 내용과 수정 이유를 나름대로 적어보았습니다. 이 과정을 통해 내가 하고 있는 리팩토링이 타당한 것인지에 대해서도 한번 더 고민을 거치게 되었습니다. 

 

또한 이번주차에 배운 점은, 테스트코드도 코드다. 라는 것이었습니다. 테스트코드 역시도 효율적인 구조와 반복적인 코드가 존재하지 않는 것이 좋다는 것을 배웠고, 메서드 네이밍을 고민하게 되었습니다. 이전까지는 별다른 규칙을 생각하지 않고 단순히 check+확인하고자 하는 메서드명 과 같은 규칙으로 네이밍해왔습니다. 그러나 이 방법은 메서드명을 수정할 때마다 메서드명도 수정해줘야했고, 이는 로직이 바뀌지 않았음에도 테스트코드를 수정해야 하는 아이러니와 번거로움을 느끼게 했습니다. 그러던 중, github discussion 을 통해서 다른 참가자분께서 테스트 메서드 네이밍과 관련하여 좋은 자료를 올려주신 것을 확인했고, 이를 통해 테스트 코드 역시도 네이밍 규칙이 필요하다는 것을 체감하고 적용해봤습니다. 또한, 반복적인 코드를 줄이기 위하여 @ParameterizedTest 를 이용했습니다. 

 

🍀 4주간의 프리코스를 마치며

한마디로 압축한다면 코딩의 코어힘을 기른 것 같습니다.

 

프리코스 이전의 저는

1. 좋은 코드란 무엇일지 알 수가 없었습니다.

2. 고민하는 힘이 없었습니다.

 

그러나 프리코스를 통해서 좋은 코드에 대한 기준이 생기고 가만히 앉아 나의 코드를 들여다보며 문제점을 파악하고자 하는 좋은 습관이 들었습니다. 무턱대고 코드를 짜던 저는, 매주 기능 구현 사항들을 정리하고 이를 차근차근 해결해 나가며 체계적인 계획과 실천이 중요하다는 것을 깨달았습니다. 또한 코드를 어느 정도 짜고 난 뒤에는 한 발치 물러나서 메서드, 클래스간의 결합도와 네이밍, 변수명, 상수로 어떤 것들을 빼야 할지, 캡슐화가 잘 실천되어 있는지 등을 고민하는 사람이 되었습니다. 또한 요구사항과 제한사항이 명확한 상황 속에서 이를 유념하며 코드를 짜야 한다는 의식이 생기게 되었습니다. 요구사항과 제한 사항이 명확한 것은 어려움을 주기도 했지만, 그 제한 속에서 나의 한계를 경험해보고 더 나은 결과를 고민하게 했습니다.

제가 이러한 4주간의 프리코스의 과정에서 큰 배움과 깨달음을 얻을 수 있었던 것은 함께 참여했던 분들 덕분도 크다고 생각합니다. 같은 요구사항과 제한사항 속에서 탄생하는 참고할만한 다양한 코드들을 통해 나의 코드에 대해서도 돌아보고, 다른 코드들을 학습하면서도 더 많이 성장할 수 있었습니다. 또한, discussion 이나 slack 을 통해서 좋은 참고 자료들을 공유해주시는 분들 덕분에도 더 나은 방향으로의 성장이 가능했던 것 같습니다. 프리코스를 통해 형성한 좋은 습관들을 저의 앞으로의 코딩 생활에도 계속 이어나가고 싶습니다.