점진적인 개선

Args 구현

매개변수에 파싱에 관한 인터페이스를 정의하고 구현체를 구현한 것인데 좋은 스타일인 것 같아 정리해보았습니다.

public interface ArgumentMarshaler {
    void set(Iterator<String> currentArgument) throws ArgsException;
}

public class BooleanArgumentMarshaler implements ArgumentMarshaler {
    private boolean booleanValue = false;

    public void set(Iterator<String> currentArgument) throws ArgsException {
        booleanValue = true;
    }

    public static boolean getValue(ArgumentMarshaler am) {
        if (am != null && am instanceof BooleanArgumentMarshaler)
            return ((BooleanArgumentMarshaler) am).booleanValue;
        else
            return false;
    }
}

이러한 방식의 장점은 새로운 타입이 추가되는 경우 해당하는 타입의 구현을 생성하고 타입 분기를 결정하는 메서드에 해당 타입을 결정하는 조건만 넣어준다면 손쉽게 확장이 가능하다는 점입니다.

 

예외 구현도 깔끔하게 정리되어 있기에 한번 따라 작성해 보았습니다.

public class ArgsException extends Exception {
    private char errorArgumentId = '\0';
    private String errorParameter = null;
    private ErrorCode errorCode = ErrorCode.OK;

    public ArgsException() {}

    public ArgsException(String message) {super(message);}

    public ArgsException(ErrorCode errorCode) {
        this.errorCode = errorCode;
    }

    public ArgsException(ErrorCode errorCode, String errorParameter) {
        this.errorCode = errorCode;
        this.errorParameter = errorParameter;
    }

    public ArgsException(ErrorCode errorCode, char errorArgumentId, String errorParameter) {
        this.errorCode = errorCode;
        this.errorParameter = errorParameter;
        this.errorArgumentId = errorArgumentId;
    }

    //Getter, Setter 생략

    //errorCode 분기별 에러 메시지 출력 코드 생략
}

public enum ErrorCode {
    OK, INVALID_ARGUMENT_FORMAT, UNEXPECTED_ARGUMENT,
    INVALID_ARGUMENT_NAME,
    MISSING_STRING,
    MISSING_INTEGER, INVALID_INTEGER,
    MISSING_DOUBLE, INVALID_DOUBLE
}

에러 또한 추가되는 에러가 존재한다면 에러 코드를 추가하고 분기 메서드에 해당 에러에 대한 동작을 추가해주면 쉽게 확장할 수 있습니다. 위에서 보는 예시처럼 코드는 점진적인 개선이 가능하도록 작성해야 합니다.

 

깔끔한 코드를 처음부터 작성하기는 매우 어렵고 바라지도 않습니다. 물론 수십 년 경험이 쌓인 프로그래머라면 가능할 수도 있습니다. 하지만 그런 전문가들도 먼저 지저분한 코드를 짠 뒤 정리한다는 교훈을 깨달았다고 합니다. 정리하는 과정을 통해 코드를 작성하면서 놓친 부분에 대해서도 다시 한번 생각해볼 수 있습니다.

점진적으로 개선하다

프로그램을 망치는 가장 좋은 방법은 개선이라는 이름 아래 구조를 크게 뒤집는 행위입니다. 개선 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문입니다. 이를 예방하기 위해 TDD 기법을 사용할 수 있습니다. TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따르기에 시스템을 망치는 행위를 허용하지 않습니다.

 

소프트웨어 설계는 분할만 잘해도 품질이 크게 높아집니다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 쉬워집니다. 나쁜 코드는 많은 비용이 들고 점점 썩어갑니다. 그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하도록 해야 합니다.