[우아한테크코스] 프리코스 3주차 리뷰

정말 슬픈 3주차가 드디어 지나가고 4주차가 오는 수요일이 돌아왔다. 😂

 

이번 3주차는 내가 얼마나 부족한지 알 수 있던 한 주였다.

 

우선 이번 3주차를 진행하는데 있어 리뷰내용으로는 부족함을 많이 느꼈기 때문에 나의 "실패"를 중점으로 블로그를 풀어나가려고한다.

 

와.. 고수가 너무 많아..

나는 모든 주차의 과제를 진행하면서 다른 사람의 코드를 일부러 보지 않았다. 볼수록 남의 코드에 영향을 받아 내가 온전히 생각하여 작성하는 방향을 지향한다.(물론 남의 코드를 본다는 것 자체가 좋지않다는 것이아니다. 타인으로부터만 온전히 배울 수 있는 것이 있다고 생각한다.)  그렇게 3주차를 종료하고 다른 사람들의 코드를 보았을 때 나는 내가 아직도 많이 모자라구나라는 생각이 들었다.

 

이번주차의 핵심은 OOP였다. 하지만 이를 단지 나는 객체화 시키는 것에 그쳤다.

여기서 우리는 의문을 가져야한다. '왜 객체지향을 사용하는가?'

나는 그 이유를 객체로 역할을 분리하여 각 객체가 하는 일을 명확히하고 재사용성을 높이기 위함이라고 생각한다.

 

하지만 나는 이를 알면서도 제대로 수행하지 못했다고 생각한다.

"객체를 객체스럽게 사용하였는가?" 라는 것에 대해 나는 그저 "기능구현과 테스트 코드를 구현하기 위한 작업에 치중"했다라고 밖에 대답을 하지못할거 같다.

 

주차가 끝나고 다른사람들의 프로젝트 진행을 살펴보았을 때 객체지향적 구조로 설계를 마친 후에 코드를 작업하거나 테스트 코드를 염려하여 메서드를 작성하는 등의 구현을 섬세하게 고려하는 모습을 보고 아직 발전을 더해야한다고 느꼈다.

 

하지만 발전을 더해야한다는 것은 아직 성장의 기회가 남아있다로 해석하고 더욱 정진해야하는 자세로 임하려한다.

그리고 그런 성장의 양분을 되도록이면 타인이 아닌 과거의 나로 삼으려고한다.

 

지옥의 TDD

테스트 코드를 평소 작성하지않다 저번주 프리코스를 계기로 테스트 주도 개발 책을 보면서 천천히 공부해 나가고있는 중이지만 여전히 너무 어렵고 어색하다.

 

내가 나의 기능에 대해 검증하고 어느 부분을 토대로 정확히 검증을 진행해야할지 갈피를 잡지 못하고 모호하게 행동했다.

 

이번 3주차 피드백을 기반으로 테스트 코드에 있어서 public의 이유와 private의 이유를 명확히하며 테스트 코드를 구현하기 용이한 객체로 사용을 하는 것이 목표이다.

 

사실 이번주차에서 가장 크게 범한 실수는 제출 사이트에서 예기치 못한 오류를 발견하고는 private로 작성하였던 메서드를 모두 public으로 변환한것이었다. 

 

사실 private이어도 함수의 호출이 명확히 이루어진다면 접근자는 크게 상관이 없는 것이고 private으로 설계한 이유가 명확히 존재하면서 테스트 클래스에서 사용하기위해 public으로 변환하는 등의 실수를 범했다.

 

이는 내가 나의 코드에 확신이 없고 설계가 미흡했기 때문에 벌어진 일이라 생각하고 이번 4주차에는 설계에 초점을 두어 진행하고자 한다.

 

 

MVC?

이번 3주차에 피드백 내용 중 하나인 비즈니스 로직과 UI로직을 분리하는것이 있었다.

물론 나는 이번 3주차를 MVC 패턴을 적용하지 않고 분리하지않고 구현하였지만 이에 대해 고민을 했었다.

 

MVC 패턴을 왜 적용하는가?

MVC(Model and View ,Controller) 패턴은 비즈니스 로직과 UI(출력구문) 비즈니스 로직에 출력 로직을 같이 사용할 경우 하나의 메서드에 부담이 커지기 때문에 이를 기피하고자 생겨난 패턴이다.

 

하지만 나는 그보다 한 가지 이유가 더 존재한다고 생각한다. 출력문의 재사용성을 높이기 위해, 단순한 반복된 코드를 지양하기 위한 이유가 더크다고 생각하여 적용하지 않았다.

 

이전 숫자야구의 경우 문제를 맞출때까지 진행해야한다는 반복적인 특성이 존재하였기에 입출력의 호출을 높이기 위해서 출력 로직 부분을 따로두어 고려했었다. 하지만 이번 로또의 경우 Application이 딱 한번만 실행되기 때문에 그 필요성을 딱히 고려하지 않았다. 하지만 아무래도 피드백을 미루어 보았을 때 아무래도 재사용성의 고려보다는 부담을 기피하는 것이 더 좋은 방법으로 고려되는 것 같아 이번 4주차 부터는 MVC 패턴을 적용하고자한다.

 

Static의 위험성

나는 1주,2주,3주까지 모두 과제를 구현할 때 관성적으로 변수들을 static으로 선언하여 사용하였다. 하지만 static을 사용할 경우 테스트 코드를 실행함에 있어 문제가 생기게 된다.

 

static은 공유자원이기 때문에 Application을 완전히 재시작하지 않는 이상 값이 남아있기 마련이다.

그렇기 때문에 여러 테스트를 진행할 경우 문제가 발생하게 된다. 테스트에서 내가 원하는 값이 나오지 않고 이상한 값을 만나게 될 수밖에 없는 구조이기 때문에 앞으로는 static을 사용하지 않고 4주차에 임하려고 한다.

 

아마 내가 예기치 못한 오류를 만난것도 이 때문일 것이다.

 

 

이번 4주차에서는

앞선 1주차에서는 기대와 배운다는 자세 , 2주차에서는 만족과 효율성, 3주차에서는 절망과 기초부터 시작한다는 마음을 배웠다. 이번 4주차에서는 여태까지 배우고 깨달은 걸 활용한다는 자세로 과제를 진행해보고자 한다.

설계부터 천천히 계획하여 객체지향을 하는 이유와 접근 제어자부터 내가 왜 이런 코드로 구성을 하였는지 한마디로

"설득할 수 있는 프로그래밍"을 하고자한다.