우아한테크캠프 Day04

오늘 오전에 우동소(우아한테크캠프 동기를 소개합니다)를 진행한 뒤, 멘토와의 점심시간을 가졌다.

우동소를 하며 든 생각은 동기들이 말을 정말 잘한다는 것이었다. 발표 실력이 다들 좋아 깜짝 놀랐다.

나도 더욱 분발해야겠다.

---

Day04 학습 내용

---

테스트 케이스는 기능 요구사항을 분석해 만든다.

기능 요구사항

1. 각 자동차에 이름을 부여할 수 있다. 전진하는 자동차를 출력할 때 자동차 이름을 같이 출력한다.

2. 자동차 이름은 쉼표(,)를 기준으로 구분한다.

3. 자동차 경주 게임을 완료한 후 누가 우승했는지를 알려준다. 우승자는 한명 이상일 수 있다.

테스트 케이스 (테스트 케이스를 만들 때는 "어떤 input이 들어왔을 때, 어떤 output이 나온다"는 포맷으로 만든다.)

1. 게임에 참여할 자동차 이름을 입력하고, 게임을 실행해 random값이 4이상이면 자동차는 전진한다.

2. 게임에 참여할 자동차 이름을 입력하고, 게임을 실행해 random값이 4미만이면 자동차는 정지한다.

※ 테스트코드를 많이 만든다고 해서 좋은 것이 아니다. (관리하고 유지보수 할 코드만 늘어날 뿐이다. 최소한의 개수로 최대를 커버할 수 있도록 만들어야한다.)

TDD 시작하기

TDD를 어디서, 어떻게 시작해야할지 막연하다면 Out -> In 방식으로 접근한다.

Out -> In 방식 : 사용자가 어떤 값을 입력할 때, 어떤 결과가 나와야 한다에서 시작 (전체적인 틀부터 설계하는 방식)

In -> Out 방식 : 세세한 구현부터 시작해서, 전체적인 것을 완성하는 방식 (처음부터 어떤 메소드가 있을지 생각하는 것은 쉽지 않다.)

오늘 수업 중 가장 와 닿았던 것은

읽기 좋은 코드, 다시 말해 유지관리하기 좋은 코드가 좋은 코드다. (성능을 너무 고려하지 말 것!!!) 

코드를 처음 보는 입장에서 메소드가 어떤 일을 하는지 명확히 들어나도록 코드를 작성해야한다.

즉, 코드를 읽는 입장에서 생각하며 코드를 작성한다. (세밀하게 코드가 어떻게 구현됐는지 궁금하면 그 때, 타고 들어가서 보면된다.)

return getSum(toInts(split(inputText)));

TDD 사이클

1단계 : fail 확인

2단계 : pass 확인

3단계 : 리팩토링

리팩토링 

리팩토링 할 때, 가능한 한 컴파일에러를 발생시키지 말고 리팩토링 진행할 것(이걸 연습해야 한다. 근데 이렇게 하기 진짜 어렵다)

따라서, Step by Step으로 점진적으로 리팩토링해야 한다.

안전한 리팩토링을 진행하려면 과도기적인 단계(중복 발생)가 반드시 발생하게 된다.

객체지향 생활체조 원칙

모든 원시값(primitive type)과 문자열을 포장한다.

ex) int number -> Positive 클래스로 포장

이렇게 했을 때 장점

예외처리를 안 해도 된다. 왜냐하면, Positive 객체가 만들어졌다는 것은 양수를 보장하기 때문이다.

일급 콜렉션을 쓴다. (= 콜렉션도 포장해라)

일급 콜렉션 정의 : 콜렉션을 감싼 객체  Why? 유효성을 보장하기 위해

일급 콜렉션을 쓴다는 의미는 "해당 클래스에 콜렉션 인스턴스만 있어야 한다"는 의미다.

객체지향 생활체조 원칙 1, 2 : 메소드 분리를 위한 규칙 (한 메소드에 오직 한 단계 들여쓰기만 한다, else를 쓰지 않는다.)

객체지향 생활체조 원칙 3, 8 : 클래스 분리를 위한 규칙 (모든 원시값, 문자열, 콜렉션을 포장한다.)

객체지향 생활체조 원칙에서 위의 붉은 2가지 규칙만 잘 지켜도 지금보다 훨씬 안전한 프로그래밍을 작성할 수 있다.

객체지향프로그래밍을 위한 팁

• 인스턴스 변수는 없을 수록 좋다.
  
  주의할 예)
  
  List<Car> cars;
  List<Car> winners; (중복)
  cars를 이용해 winners를 구할 수 있다. 이렇게 cars를 이용해 구할 수 있는 winners는 인스턴스 변수로 만들 필요가 없다. 이건 낭비다.
  
  
  
• 인스턴스 변수에 접근하는 인스턴스 메소드를 최소화한다.
• 모든 원시값, 문자열, 콜렉션을 포장한다.
• 메소드가 한가지일만 하도록 구현한다. (재사용성이 높아진다.)
• VO객체는 값이 변경되면 안된다. (Immutable Object)
• 객체지향프로그래밍을 할 때 상속은 진짜 필요한 경우가 아니라면 사용하지 말 것
  상속보다는 조합을 이용하는게 변경이 발생했을 때 훨씬 유연해진다.
  상속은 부모의 변경이 자식에게 너무 영향을 미치기 때문에

하지만,

프로그래밍 세계에는 정답이 없다.

다만, 현 시점에 최선의 답이 무엇인지 고려할 뿐이다.