우테코 8기 신청 + 1주차 프리코스 후기 및 회고

우테코에 지원하게 되었다..

 

작년에는 지원에 대해서 꿈도 못꿨는데, 지원하게 된게 꿈만 같고 뭔가 많이 떨리고 드디어 지원을 했다는 설렘도 느껴졌다.

 

자기소개서 작성도 엄청 오래걸렸다. 추석이 겹쳐서 좀 느슨해지긴 했는데, 진짜로 시간 꽉꽉 채워서 적었던 것 같다.

상호 피드백도 받으며 주변 지인한테도 부탁해서 정말 많이 고쳐 나갔다.

여튼 자소서도 대학 수시때 빼고 거의 처음쓰는거라 많이 어색하고 헤매기도 했지만, 그래도 제출에 성공했다!!

자소서 거의 10번은 넘게 고침..

 

이 메일이 온 순간 시작됐다는 실감이 났다.

그리고 우테코 문제를 이때부터 풀지 않았다.

괜히 먼저 풀었다가 학습을 하기 보다는 틀에 갖혀서 이미 짜 놓은대로 코드를 적을 것 같았기 때문이다.

 

그리고 디스코드 추가 메일도 오고 드디어 대망의 미션 시작일이 다가왔다.

하지만 난 시작을 제대로 할 수 없었다.. 바로 중간고사 시즌이랑 정확히! 겹쳤기 때문이다ㅠㅠ

그래서 시간을 많이 투자하지 못한 아쉬움이 있다.

 

0. 목표

1. MVC 패턴 적용

2. OOP 적용

3. TDD 적용

 

이 세가지가 가장 주요한 이번 미션에 대한 내 목표였다.

이게 과연 잘 지켜질까? 고민하면서 코드를 짜가려고 노력했다.

그 과정에서 여러번의 리펙토링도 있었고, 후회를 하기도 했다.

아래에 그 내용을 적어 볼 예정이다.

 

1. 요구서 정의

문자열 계산기로 였는데 생각보다 쉽네? 라는 생각을 처음에 했지만, 점점 하다보니 까다로운 요구사항들이 생겨났다.

 

입력한 문자열에서 숫자를 추출하여 더하는 계산기를 구현한다.

쉼표(,) 또는 콜론(:)을 구분자로 가지는 문자열을 전달하는 경우 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
예: "" => 0, "1,2" => 3, "1,2,3" => 6, "1,2:3" => 6
앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다.
커스텀 구분자는 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.
예를 들어 "//;\n1;2;3"과 같이 값을 입력할 경우 커스텀 구분자는 세미콜론(;)이며, 결과 값은 6이 반환되어야 한다.

사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.

 

라는 요구사항이 있었다. 

 

먼저 하던대로 기능 -> 예외 순으로 작성을 해 나가기 시작했다.

기능도 제대로 되지 않는데 예외를 먼저 잡다 보면 이도저도 아니게 된다는 생각에

요구사항대로 원하는 기능을 먼저 만든 후 예외를 채워 나가는 걸 선호하게 되었다.

 

 

지금 봐도 그렇지만 너무 단순하다. 그래서 다음 미션때는 좀 더 세분화 해서 짜 볼 예정이다!

 

2. 코드

일급 컬렉션 사용하자..
책임 분류하자..
검증은 도메인 본인이 하자..

 

하면서 계속 생각한 부분이다. 

하지만 당연히 급하면 실수가 있는 법!!!!!

팩토리 메서드를 사용했으면서도.. 생성자를 public으로 열어놨다는 것이다.. 역대급 실수.ㅠㅜㅜ

코드 리뷰 받는 부분에서 알아채서 다시 한 번 꼼꼼하게 확인해야 쓰겠다는 생각이 들었다.

 

그리고 얻어 걸린 부분은 일급 컬렉션을 쓰면서 불변 리스트로 반환을 해주어야 하는데, stream의 toList()를 쓰면서 자동적으로 불변 리스트로 반환을 해주게 되었다. 이런 부분을 좀더 생각하면서 코드를 짜야 할 것 같다.

 

    public void execute() {
        Numbers numbers = Numbers.from(StringParser.from(
                view.inputNumbers()
        ));
        view.outputView(numbers.calculate());
    }

 

어떤 부분이 아쉬운 부분일까??

단지 한 라인에 코드를 넣으면 간결해서 보기 좋을 것이라고 생각하고 이렇게 했는데, 사실은 이게 디미터 법칙을 어긴 것이라는 피드백을 받았다. 

".get()" 과 같은 부분을 적게 사용해야 된다고만 알고 있었는데 "가까운 친구들과 얘기하라" 이런 걸 생각해 보면 Numbers는 StringParser과, view까지 알고 있기 때문에 결합도가 높아지는 문제가 발생하게 되는 것이다.

따라서 이는

public void execute() {
        String input = view.inputNumbers();

        // 1. 컨트롤러가 파서에게 파싱을 '지시'
        List<String> data = StringParser.from(input);
        
        // 2. 컨트롤러가 도메인에게 생성을 '지시'
        Numbers numbers = Numbers.from(data); 
        
        view.outputView(numbers.calculate());
    }

 

이렇게 바꾸면 디미터 법칙을 이행한다고 할 수 있다. (view는 생성자 주입한 상태)

 

3. 배운 부분

응집성 부분에서 내가 잘못 알고 있는 사실이 있었다.

Numbers 클래스에서 계산과 구분자 판별까지 하게 만들었는데, 이것이 Numbers가 모든 책임을 갖게 되니 응집성이 증가 된다고 생각했다.

하지만 오히려 하나의 클래스에 두개의 책임이 부여되면서 오히려, 당연하게도 응집성이 떨어진다는 사실을 새로 알게 되었다.

아직까지도 기초도 흔들리는 내 모습을 보고 다시 기초부터 다시 쌓아야 겠다는 생각이 들었다.

그리고 문자열 계산기에서 정규 표현식을 쓰신 분들이 보이는데, 이런 문자열이 들어오는 상황에서 정규표현식이 더 깔끔하고 예외 처리하기 더 쉬울 것 같다는 생각이 들었다. 

그래서 정규 표현식을 연습해야 겠다는 생각이 들었고, 다음 미션에 꼭 적용을 해야겠다는 목표가 생겼다.

 

4. 결과

OOP도 지키려고 노력하고, MVC 패턴도 지키려고 노력했지만 여기저기서 아직 아쉬운 부분이 보이는 것 같다. TDD도 지키려고 했으나, 코드를 리팩토링 하는 과정이나, 수정하는 과정에서 계속해서 테스트 코드 수정이 이루어 져서 쉽지 않다고 느꼈다. 

 

 

 

 

테스트 결과는 성공 했지만, 내가 생각한 예외들 말고 더 있었기 때문에 다음엔 요구사항을 더 잘 세분화 해 예외까지 더 많이 구상해야 겠다는 생각이 든다.

 

지금도 2주차 과제가 나와있는데 이번 주차도 파이팅!!!!!!!!!!!!

 

하던것만 하지 말고, 학습하며 성장하자