우테코 3주차 - [로또] : 회고

현재 우테코 3주차 기능 구현을 모두 끝내고

pull request로 제출도 완료한 상태이다.

 

원래 구현하면서 했던 생각을 하나하나 다 정리해볼 생각이었지만

생각보다 구현시간이 너무 오래걸렸고 내용도 많아서

차후로 미뤄두고 우선 마감이전까지 회고만 정리해보고자 한다.

 

---

 

- 에러에도 내용이 담겨져 있어야 한다.

이전 주차까지는 예외사항 발생시 IllegalArgumentException만을 던져줌으로써 조건을 만족시켰으나, 이번 주차부터 어떤 상황에서 예외가 발현되었는지를 명시하라는 요구사항이 있었다.  이에 각 오류 유형별로 메소드를 분류하고 오류메시지를 던져주는 식으로 에러 안에 왜 에러가 발생되었는지 내용을 담으려 노력했다.

    public static void rangeException() {
        System.out.println(RANGE_ERROR);
    }

    public static void cntException() {
        System.out.println(NUMBER_SIZE_ERROR);
    }

    public static void overlapException() {
        System.out.println(OVERLAP_NUM_ERROR);
    }

    public static void typeException() {
        System.out.println(NOT_NUMBER_ERROR);
    }

    public static void numberFormatException() {
        System.out.println(INPUT_FORMAT_ERROR)

 

이런 방식으로 에러를 발생시켰을 때 좋았던 점은 다음과 같았다.

 

- 의도한 에러가 처리가 되는 것을 TDD과정에서 더 직관적으로 볼 수 있었다.

- 협업과정에서 에러처리의 의도를 더 잘 전달할 수 있다.

- 유저 인터페이스를 더 유연하게 처리할 수 있다.

 

이후 1/2주차의 에러 처리도 다음과 같이 수정해보는 시간을 가질 생각이다.

 

- 하드코딩 방지를 위한 Constants 클래스 생성

: 2주차 피드백 중 하드코딩을 하지 말라는 피드백이 있어 하드코딩이 무엇인가 했다. 알아보니 직접 프로그램에 값을 넣는 행위를 하드코딩이라 칭했다.

예를 들어 숫자야구 게임에서 우린 3자리 숫자로 게임을 진행했으나 프로그램을 5자리 숫자야구게임으로 확장시켜야 한다고 가정해보자. 만약 하드코딩되어 있는 프로그램이 있다면 모든 3을 5로 수정해주어야 할 것이다. 이런 과정은 프로그램의 유동성이 떨어지며, 무엇보다 그 과정에서 자릿수와 상관없는 3이란 숫자가 5로 수정되는 치명적인 실수를 범할수도 있다.

 

이에 되도록 간단한 메시지와 값들이더라도 프로그램 확장과정에서 변형의 가능성이 있는 값들은 모두 상수처리를 해주었다.

public class Constants {
    public static final int NUM_OF_LOTTO = 6;
    public static final int MIN_NUM = 1;
    public static final int MAX_NUM = 45;

    public static final int LOTTO_PRICE = 1000;
}

 

이렇게 상수처리를 했을 때 좋은 점은 다음과 같았다.

- 값에 의미를 부여함으로써 이 값이 무엇을 의미하는지 파악가능해졌다.

- 프로그램의 유동성이 더 커졌다.

- 같은 값을 사용해야하는 경우 Constants 클래스 상수를 사용함으로써 같은 의미의 인스턴스 변수를 반복적으로 선언하지 않아도 되었다.

 

 

- TDD 작성의 중요성 

단위 테스트 작성에 신경을 쓰면서 커밋을 진행했다.기능 하나를 완성하고 그 기능을 테스트하는 코드를 꼭 작성해주었다.

 

그 과정에서 얻은 점은 다음과 같다.

- 미래를 예측하기보다 현재 구현 기능에 집중하면서 차근차근 설계해나간다는 느낌을 받았다.

- 구현을 하나하나 완성하고 test case를 통과할 때마다 쾌감이 있었고 자신감이 생겼다.

- 추가 요구사항이 생겼을 때, test case 추가를 통해 빠른 피드백이 가능했다.

- 실패한 테스트로부터 디버깅이 가능했다.

- 리팩토링 과정에서 혹여나 프로그램 구현에 치명적 영향을 주지 않았는지 재점검이 가능했다.

- 버그가 확연히 줄어들었고 코드길이가 간결해져서 함수 길이 조건을 더 쉽게 충족할 수 있었다.

 

 

- Controller / View의 구분

우선 MVC 패턴에 익숙하지 않은 만큼 어느정도까지를 Controller에 넣고 어떤 인터페이스를 View에 넣어야할지 감이 잡히지 않는 부분이 있었다.  우선 구분된 형태를 보면

 

Controller

-> 프로그램 시퀀스를 순차적으로 구현

- model과 view를 이어주는 과정

 

View

- InputView : 구현에 필요한 값을 받아오는 과정에서 ui 기능 구현

- OutputView: 프로그램 구현 이후 수익률 출력 및 결과 안내 메시지

- Message : 오류 및 안내 메시지 관리 클래스

 

이렇게 ui와 주요 프로그램 흐름인 controller를 구분함으로써 얻게되는 장점은 다음과 같았다.

- 각 클래스의 의존도가 낮아졌다. : 결국 자신 기능만 수행하면 되기에 클래스가 영향력이 줄어들었다. 이는 유지보수가 편해졌다는 의미로 받아들일 수도 있다.

- 메소드 소스코드가 짧아졌다. : 기능들을 단위별로 잘라서 구분해놓다보니 메소드 축약이 가능해졌다.

이러한 이유로 코드의 가독성, 확장성, 재사용성 이렇게 3가지 측면에서 긍정적 효과를 보았다.

 

 

- 중복되는 기능을 클래스로 분리

: 메소드는 함수의 직선적인 목표 중 하나는 코드의 재사용성이라 생각한다.

: 그런 측면에서 예외사항 처리에서 비슷한 코드들이 필요했고,

처음엔 각 클래스에서 유효성 검사 및 예외처리를 해주었으나 이내 같은 코드임을 깨닫고

NumValidator 클래스를 아예 분리해주었다.

 

예를 들어 앞선 예외사항 기능 목록에 있어서

 [0] 로또 구입 입력받기
    - [0] 1000원으로 나누어 떨어지지 않을 경우
    - [0] 양수가 아닌 수를 입력했을 경우
    - [0] 숫자가 아닌 경우

- [0] 당첨번호 입력받기
    - [0] 중복되는 숫자가 있을 경우
    - [0] 6개보다 많거나 적은 숫자를 입력할 경우
    - [0] 범위를 넘어선 숫자가 있을 경우

로또 구입 번호 뿐만 아니라 당첨번호 입력 사안에 있어서도

- 숫자가 아닌 문자일 경우

- 숫자인데 음수거나 0일 경우

- 범위를 넘어선 숫자(45 초과)일 경우

 

이런 사안들은 공통적으로 검열되어야 하는 요소였다.

 

이렇게 NumValidator 클래스를 분리함으로서 얻은 장점은 다음과 같았다.

- 중복 코드를 줄임으로써 코드 재사용성이 증가함.

- 클래스 의존성이 줄어듦(상수 사용이 하나의 메소드에만 들어감으로)

 

 

 

 

-