느낀점

로또를 드디어 마무리를 했다. 마무리를 했다는 것도 중요하지만 마무리를 하는 과정에 크게 깨닫고 배운 점이라고 하면 바로 TDD를 이용을 해서 개발을 한다는 점이다. 이전에는 보통 개발을 하는 경우 메서드를 만들고 클래스를 분리를 하고 main 문에서 끊임없이 테스트를 했었다. 그렇게 개발을 하다 보니 상대적으로 메서드에 많은 인자들을 전달을 했었고, 메서드와 메서드가 물리고 물리는 과정이 반복이 발생을 했었다. 예를 들면 이전에는 Lotto와 당첨번호를 비교를 했을 때, List lotto와 List rightNum이라는 것을 통해 비교를 했었다. lotto에 있는 문장을 반복문을 돌려서 각각의 값을 비교를 하고 비교를 할 때 발생하는 문제는 Integer.parseInt(rightNumber.get(i))와 같이 일일이 정수형으로 변환을 하는 경우가 발생을 했었고, 여기서는 count의 값을 리턴을 했었다. 그리고 그 count를 인자를 받아서 Rank 값을 리턴해주는 메서드의 경우 void 타입으로 2중 for 문이 아닌 단일 for 문이 2개가 돌았었다. 한 개는 count의 값을 받아서 rank를 리턴하는 것이었고 다른 한 가지는 ranks에 rank를 전달을 해주는 경우였다.  그렇다 보니 설계가 굉장히 복잡해졌었다. 너무나도 많은 메서드 너무나도 많은 클래스가 생성이 돼서 나 역시도 어떤 메서드들이 존재하는지에 잘 몰랐다. 지난주 화요일 오후 개발을 하면서 큰 결단을 했다. 포비와 면담을 하기 전에 나는 로또 4단계 구현만.. 하고. PR을 보내고 포비와의 면담을 했다. 면담시간에 들은 내용을 정리를 하자면 객체에 대한 이해가 부족하고, 클래스와 인스턴스에 대한 이해 부족, 구조적인 이해 부족, 의존성 문제 등을 들 수가 있다. 그나마 내가 이해를 할 수 있었던 부분은 구조에 대해서 내가 잘못 이해를 하고 있었다는 부분이다.  예를 들면 A라는 메서드를 내가 만들었을 때,public void aMethod(int a, int b)로 정의를 했다. 클래스를 구조적으로 변경을 해보라는 피드백을 받았을 때 나는 단지 a 메 서드를 A 클래스에서 B 클래스로 복사 붙여넣기를 해서 이동을 시키는 것이 구조적으로 변경을 한다는 것으로 알고 있었다. 면담을 통해서 내가 구조를 변경한다는 것에 대한 잘못된 이해를 하고 있다는 것을 깨닫고, 객체지향에 대한 나도 모르는 잘못된 인식을 가지고 있다는 것을 알게 되었다. 내가 끊임없이 객체지향에 대해서 고민을 하는데 변화가 없다는 것은 분명 나의 생각 속에 잘못된 오해가 있다는 점이었다. 면담을 마치고 나서 step4를 중도에 멈추고, 로또를 step1부터 다시 시작을 하자고 마음을 먹었다. 그 전날 TDD에 대한 강의를 들었다. 이전에는 TDD라고 했을 때 단순히 테스트 코드를작성하는 것이라고 생각을 했었고, 이전 레이싱카, 사다리 프로젝트를 했을 때는 지금보다 더 클래스와 메서드, 객체를 생성하고 전달하는 것에 대해서 더 몰랐던 시절이었다. 그때는 cow의 도움으로 겨우겨우 테스트 코드를작성했었지만, 나는 테스트 코드에 대한 두려움이 강했었다. 그때 테스트 코드를 작성하기 위해서 메서드를 너무나도 많이 바꿨기 때문이다. 그러다가 강의를 듣고 나서 TDD에 대한 방법을 라이브 코딩을 통해서 조금씩 습득을 했었다. 그래서 로또 프로젝트를 완전 TDD를 통해서 구현을 다시 해보자는 생각이 들었다. 아무래도 그날 면담을 하고서 로또를 다시 시작 안 하고 그대로 4단계로 넘어갔다면 훗날에 더 큰 고통이 따랐을 것이라는 생각이 들었다. 우선 LottoTest라는 테스트 파일을 생성을 하고 머릿속으로 차근차근 가설을 세워가면서 코드를 작성을 했다. TDD 때문인지는 모르겠지만, 테스트를 하기 위해서 메서드를 만들게 되면 인자를 굉장히 적게 전달을 하는 경우가 많았다. 예를 들면 이전에는 decisionRank라는 메서드는 Rank를 정하기 위해서 3가지 인자 List lottos , Lotto rightNum, String bonusNum를 전달을 하게 되고 여기 내부적으로는 rankLoop라는 메서드를 호출하고 여기서도 3가지 인자를 전달하고 내부에 또 다른 메서드를 호출을 하게 설계가 되어있다. 테스트 기반으로 작성을 하다 보니 생각보다 단순해졌다. 로또가 자동으로 생성이 됐는지 확인하면 되고, 수동으로 생성이 됐는지 확인하면 되고, 단순히 당첨번호랑 로또만 있으면 바로 Rank를 리턴해주는 메서드를 만들게 되었다. 이리저리하다 보니 인자도 최대한 많이 줄이게 되고 이전 코드와 비교를 했을 때, 메서드가 굉장히 많이 줄어들고 단순해졌다는 사실을 알 수 있었다. 무엇보다도 main 문을 작성을 할 때 이전에는 main 문에 많은 메서드들을 조합을 해서 이리저리 시도를 하면서 테스트를 했다면 바뀌고 나서는 테스트 코드를 작성하고 통과를 다 시키면 main 문에서는 그저 만든 메서드들을 나열을 하면 될 뿐이었다. 이 방법으로 계속하다 보니 엄청 오래 걸렸던 로또 step1, step2, step3, step4, step5를 굉장히 빨리 진행을 하고 피드백도 많이 단순해졌다. 처음에는 면담에서 너무 많이 깨져서 통과를 잘 시켜주시나라는 생각이 들 정도였다.  이제 비로써 로또를 마무리를 하게 되었다.  길고 긴 여정이었고 중간에 많이 힘들다기보다는 많은 고민을 했었다. 마무리를 하면서 TDD를 통해 개발을 한다는 점이 가장 크게 얻어 간 점이다. 가장 느릴 거 같았던 길이 결국에는 가장 빠른 지름길이었다. 나에게는 앞으로도 어려움에 봉착을 하게 되면 다시 처음부터 시작을 할 수 있도록 용기를 주는. 프로젝트로 기억이 남을 거 같다.