1주차 피드백

• 요구사항을 정확히 준수한다.

• 커밋 메시지를 의미있게 작성한다.

• git을 통해 관리할 자원에 대해서 고려한다.
  .class 파일은 java 코드가 있으면 생성할 수 있다. 따라서 굳이 git을 통해 관리하지 않아도 된다.

• Pull Request를 보내기 전 브랜치를 확인한다.

• PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다.

• 이름을 통해 의도를 드러낸다.

• 축약하지 않는다.
  클래스 이름이 Order라면 shipOrder라고 이름 지을 필요가 없다. ship()이라고 하면 된다.

• 공백도 코딩 컨벤션이다.

• 공백 라인을 의미있게 사용한다.
  문맥을 분리하는 부분에 사용하는 것이 좋다.

• 의미 없는 주석을 달지 않는다.
  변수 이름, 메서드 이름을 통해 의도가 드러난다면 굳이 주석을 달지 않는다.

• Java에서 제공하는 API를 적극 활용한다.

• 배열 대신 Java Collection을 사용한다.

2주차 피드백

• README.md를 상세히 작성한다.

• 기능 목록을 재검토한다.
  기능 목록을 클래스 구현, 메서드 시그니처와 반환값과 같이 상세하게 적지 않는다. 언제든지 변경될 수 있기 때문이다.

• 기능 목록을 업데이트한다.
  시작할 때 모든 기능 목록을 완벽하게 정리한다는 부담 보다는 문서를 계속 업데이트한다.

• 값을 하드 코딩하지 않는다.
  상수를 만들고 이름을 부여하자.

• 구현 순서도 코딩 컨벤션이다.
  클래스는 상수, 멤버변수, 생성자, 메서드 순으로 작성한다.

• 변수 이름에 자료형은 사용하지 않는다.

• 한 함수가 한 가지 기능만 담당하게 한다.

• 처음부터 큰 단위의 테스트를 만들지 않는다.

3주차 피드백

• main( ) 함수도 길게 작성하지 않는다.

• 발생할 수 있는 예외 상황에 대해 고민한다.

• 비즈니스 로직과 UI 로직을 분리한다.

• 연관성이 있는 상수는 static final 대신 enum을 활용한다.

• final 키워드를 사용해 값의 변경을 막는다.

• 객체의 상태 접근을 제한한다.
  인스턴스 변수의 접근 제어자는 private

• 객체는 객체스럽게 사용한다.
  Lotto 클래스가 numbers 상태값을 가지고 getter로 꺼내기만 하지 않고, 메시지를 던지도록 구조를 바꿔 데이터를 가지는 객체가 되도록 한다. (숫자 확인 로직)

• 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다.
  필드의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다.

• 성공 케이스 뿐만 아니라 예외 케이스도 테스트한다.

• 테스트 코드도 코드다.
  테스트 코드도 리팩터링을 통해 개선해나가야 한다. 특히 반복적으로 하는 부분을 중복되지 않게 만들어야 한다.

• 테스트를 위한 코드는 구현 코드에서 분리되어야 한다.
  테스트를 위한 편의 메서드를 구현 코드에 구현하지 마라.

• 단위 테스트하기 어려운 코드를 단위 테스트하기
  테스트하기 어려운 것을 클래스 내부가 아닌 외부로 분리하려는 시도를 해본다.

• private 함수를 테스트하고 싶다면, 클래스분리를 고려해본다.
  테스트하기 쉽게 구현하기 위해서는 해당 역할을 수행하는 다른 객체를 만들 타이밍이 아닐지 고민해 볼 수 있다. 너무 많은 역할을 하고 있는 함수나 객체를 어떻게 의미있는 단위로 분할할지 초점을 맞춰보자.