1단계 자동차 경주 회고

과정 소개

---

클린코드를 위한 TDD, 리팩토링 with java10 과정을 리뷰하려고 한다.
해당 과정은 순수 자바로 간단한 어플리케이션을 TDD로 만드는 과정이다. 자바를 어느정도 기본 문법만 안다면 초초초강추한다.
그 어디서도 배우기 힘든 교육이라고 생각한다. 왜냐하면, 능동적 학습을 할 수 있고, 코드 리뷰를 받을 수 있다.
그리고 운영하기 좋은 코드는 어떤 코드인가에 대해 집중하여 코드를 작성하다보니 자연스레 공부되는 점도 많다.

결과적으로 객체지향적으로 유지보수 하기 좋은 코드를 짜기위한 훈련을 하는 과정이다.

나는 서비스가 성장하기 위한 기본 베이스는 변화에 빠르게 대응할 수 있는 코드라고 생각한다. 변화에 빠르게 대응할 수 있는 코드는
클린 코드라고 생각한다. 물론 이상적으로 모두 완벽하게 할 수는 없다. 하지만 그 생각을 가진자와 가지지 않은자, 경험을 한 자와
경험을 하지 않은 자는 완전히 다른 세계에서 개발한다고 생각한다.

진행 과정

---

대략적으로 설명하자면 총 4개의 미션을 수강자 스스로 풀어가며, 코드 리뷰를 받으며 리팩토링을 하는 과정이다.
정말 생각보다 정말로 어렵다. 나는 뒤로 갈수록 점점 더 어려워서 3단계 미션 부터는 마음의 드는 코드를 보고, 한줄 한줄
모두 이해하며 개발 하기도 했다.

1단계 자동차 경주 미션

---

나는 처음에 2단계 미션까지 완료하고 나머지 단계를 하지 못했다. 회사를 다니면서 했는데 생각보다 너무 어려워서였다.
그리고 토이프로젝트를 리팩토링하려고 하는데 막막해서 과정을 다시 완료하자는 마음으로 다시 1단계 부터 시작하게 되었다.

1단계에서 배우는 내용은 테스트 코드 작성하는 것을 배운다. 절대 강의 형식이 아니고 스스로 힌트만 보고 해나아가야 한다.
정답은 없다. 하지만 결국 리뷰어분들이 꼼꼼하게 해주시기 때문에 조금 더 딮하게 들어가서 리뷰 해주시는 경우도 있기 때문에
사람마다 1단계 부터 조금 빡셀 수 있을 것 같다. 하지만 그럴수록 배울건 많아진다.

요구사항 분리하기

TDD를 하기 위해서는 요구사항을 잘게 분리할 줄 알아야 한다. 나는 개인적으로 이 것이 가장 어려웠다. 도메인 지식도 부족하고
뭔가 막막했다. 그래도 나름대로 요구사항을 최대한 분리했다. 분리를 하다보니, 중간에 또 분리할 것이 발견되는 것을 발견했다.
나는 두 번째 하는거라서 수월했는데 처음할 때는 요구사항 분리조차 어려웠다.

전략 패턴

전략 패턴이라는 것을 처음으로 알게 되었다. 평소에 디자인 패턴을 공부하지 않았는데 유연한 코드를 작성하기 위해서 전략 패턴은
아주 기본이 되는 것이다. 전략 패턴을 사용하면 테스트 하기 좋은 코드가 될 수 있고, 전략을 변경하고 싶을 때 갈아 끼워주기만 하면
되기 떄문에 아주 유용하다. 거의 클린 코드로 가는 근원이라고 생각한다.

변수명이나 클래스명에 콜렉션명은 자제하기

클린 코드 책에서 보았던 내용을 피드백 받았다. 변수명에 List, Map과 같은 컬렉션명이 들어가면 구현체 변경 시 변수명이 맞지 않게된다.
그렇기 때문에 자제하는 것이 좋다고 한다. 그래서 CarList 보다는 Cars와 같은 복수를 나타내는 것이 더 유연하다.

Collection<Car> carList = new ArrayList<>(); // 변경 전

Collection<Car> carList = new HashSet<>();   // 변경 후, 타입과 변수명이 맞지 않다.

박싱 타입 보다는 기본 타입 사용하기

이유는 크게 세 가지이다.(이펙티브 자바 참고)

1. 기본 타입은 값만 가지고 있으나, 박싱 타입의 두 인스턴스는 값이 같아도 서로 다르다고 식별될 수 있다.
   즉, == 연산 시 잠재적 예외
2. 기본 타입의 값은 언제나 유효하지만, 박싱 타입은 null을 가질 수 있다.
3. 기본 타입은 하는 일이 없고, 박싱 타입은 내부적으로 하는 일도 많고, 객체 생성도 하므로
   시간과 메모리 효율면에서 더 효율적이다.

모든 기본 타입은 포장하기

가장 신기?했던 부분이다. 포장하는 것이 SRP를 지키는 가장 1단계인 것 같다.
기본 타입을 무조건 포장해야 하는 것은 아니지만 연습이기 때문에 최대한 쪼갤 수 있는 만큼 클래스를 쪼개라고 피드백이 들어왔다.
포장을 하다보면 자연스레 SRP가 지켜지게 되면 SRP가 지켜지니 각자의 1가지 책임에만 몰두할 수 있는 객체가 탄생하게 된다.
하나의 클래스가 여러가지 일을 하다보면 코드는 점점 건드리기 어려워지는 코드를 많이 보았을 것 이다.
대표적으로 내가 회사에서 많이 보았던 Service에 1만 줄, 1천 줄 등과 같은 코드이다.