우테코 프리코스 공통 피드백 정리

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

git을 통해 관리할 자원에 대해서도 고려

• .idea, .metadata, .class 등의 파일을 굳이 관리하지 않아도 됨

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

이름을 통해 의도를 드러내기

• 연속된 숫자나 불용어(info, data, a, an, the) 사용 지양, 축약 금지
• 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하기
• 문맥을 중복하는 이름 자제
  • order.shipOrder()보다 order.ship이 더 적절

공백도 코딩 컨밴션

• if, for, while문 사이의 공백도 코딩 컨벤션

공백 라인을 의미 있게 사용

• 문맥을 분리하는 부분에 사용

space와 tab을 혼용하지 않는다.

의미 없는 주석을 달지 않는다

• 주석 대신 변수명, 메서드 명을 통해 어떤 의도인지 드러내기
• 의도를 드러내기 힘든 경우에만 주석 달기

코드 자동 정렬 기능 활용

• IntelliJ IDEA: ⌥⌘L, Ctrl+Alt+L
• Eclipse: ⇧⌘F, Ctrl+Shift+F

자바 제공 API 적극 활용

• 리스트, String 등의 API
  • 예) Arrays.asList(), String.join()

배열 대신 자바 컬렉션 사용

• 데이터 조작 시 다양한 API 사용 가능

README.md 상세히 작성

• 해당 프로젝트가 어떤 프로젝트이며, 어떤 기능을 담고 있는지 기술하기

기능 목록을 재검토

클래스 설계나 구현, 함수 설계와 구현 등 너무 상세하게 작성 금지

기능 목록을 업데이트

처음부터 기능 목록을 완벽하게 정리하기보다 기능을 구현하면서 문서를 업데이트

값을 하드 코딩 금지

구현 순서

• 상수(상수 - static final) 또는 클래스 변수
• 인스턴스 변수
• 생성자
• 메서드

변수 이름에 자료형은 사용 금지

한 함수 한 가지 기능만 담당

• 함수가 길면 한 함수에서 여러 일을 하려고 하는 경우 이를 적절하게 분리
• 함수가 한 가지 기능하는지 기준 세우기
  • 예) 15라인 넘어가지 않기

테스트 작성 이유 정리

• 기능 점검 목적뿐만 아니라 코드에 대한 빠른 피드백을 받을 수 있고 학습 도구로도 활용이 가능함
• https://techcourse-storage.s3.ap-northeast-2.amazonaws.com/9b82d8a360c548fcadd14c551dbcbe06

처음부터 큰 단위의 테스트 작성 금지

• 테스트 목적 중 하나는 작성 코드에 대해 빠르게 피드백받기
• 테스트가 작아야 빠르게 피드백을 받을 수 있음
• 문제를 작게 나누고, 그중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나가기

발생할 수 있는 예외 상황에 대해 고민하기

비즈니스 로직과 UI 로직 분리

• 비즈니스 로직과 UI 로직을 한 클래스가 담당 금지(SRP 위배)

연관성이 있는 상수는 static final 대신 enum을 활용하기

final 키워드를 사용해 값의 변경을 막기(변수, 매개 변수)

객체의 상태 접근을 제한

• 인스턴스 변수의 접근 제어자는 private으로 구현

객체는 객체스럽게 사용

• 객체에서 데이터를 꺼내지(get) 말고 메시지를 던지도록 구조를 바꿔 데이터를 가지는 객체가 일하도록 하기

필드(인스턴스 변수)의 수를 줄이기 위해 노력

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

성공하는 케이스뿐만 아니라 예외에 대한 케이스도 테스트하기

• 특히 결함이 자주 발생하는 부분 중 하나인 경곗값을 꼼꼼하게 확인하기

테스트 코드도 점진적인 리팩터링 필요

테스트를 위한 코드는 구현 코드에서 분리하기

• 테스트를 위한 편의 메서드를 구현 코드에 구현 금지
• 테스트를 위해 접근 제어자 변경 금지
• 테스트 코드에서만 사용되는 메서드 구현 금지

단위 테스트하기 어려운 코드 단위 테스트하기

A. 단위 테스트가 어려운 경우

import camp.nextstep.edu.missionutils.Randoms;

public class Lotto {
    private List<Integer> numbers;

    public Lotto() {
        this.numbers = Randoms.pickUniqueNumbersInRange(1, 45, 6);
    }
}

——————

public class LottoMachine {
    public void execute() {
        Lotto lotto = new Lotto();
    }
}

B. 테스트가 가능하도록 수정한 경우

public class Lotto {
    private List<Integer> numbers;

    public Lotto(List<Integer> numbers) {
        this.numbers = numbers;
    }
}

——————

import camp.nextstep.edu.missionutils.Randoms;

public class LottoMachine {
    public void execute() {
        List<Integer> numbers = Randoms
            .pickUniqueNumbersInRange(1, 45, 6);
        Lotto lotto = new Lotto(numbers);
    }
}

메서드 시그니처를 수정하여 테스트하기 좋은 메서드로 만들기

private 함수를 테스트하고 싶다면 클래스 분리 고려

• private 함수가 가독성 이상의 역할을 하는 경우 새로운 객체 만들 타이밍이 아닌지 고민 필요