[우테코 5기 프리코스] 피드백 정리

(* 피드백의 전문이 아닌, 일부를 발췌하여 정리하였습니다.)

📌 정리 내용
- 1주 차 공통 피드백
- 2주 차 공통 피드백
- 3주 차 공통 피드백

🎯 정리 목적
공부해야 할 것이 무엇인지 피드백을 통해 방향성을 잡고, 부족한 부분에 대한 학습을 진행하는 것을 목적으로 함.
- 미션 구현에서 놓친 부분을 확인하고 보완하자.
- 피드백과 함께 제공된 자료를 복습하자.

 

---

[ 1️⃣ 1주 차 공통 피드백 ]

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

커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성하자.

 

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

연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 않다.

이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하자.

 

- 축약하지 않는다

클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자.(객체 지향 생활 체조 원칙 5)

 

- IDE의 코드 자동 정렬 기능을 활용한다

놓친 공백도 잡아주어 더 깔끔한 코드를 볼 수 있다.

 

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

함수(메서드)를 직접 구현 전에 Java API에서 제공하는 기능인지 검색을 먼저 해보자.

Ex: List에서 join

 

- 배열 대신 Java Collection을 사용한다

Java Collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 API를 사용할 수 있다.

Ex: List에서 contains

 

---

[ 2️⃣ 2주 차 공통 피드백 ]

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

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

 

- 기능 목록을 재검토한다

기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다.

정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다.

 

- 기능 목록을 업데이트한다

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

죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

 

- 값을 하드 코딩하지 않는다

상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내자.

 

- 구현 순서도 코딩 컨벤션이다

클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성하자.

 

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

변수 이름에 자료형, 자료 구조 등을 사용하지 말자.

 

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

함수 길이가 길어진다면 한 함수에서 여러 일을 하는 경우일 가능성이 높으니 잘 확인하고 적절하게 분리해보자.

함수 길이는 10-15라인으로 작성해보자.

 

- 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다

테스트를 작성하는 과정을 통해 나의 코드에 대해 빠르게 피드백을 받을 수 있고, 학습 도구로도 활용할 수 있다.

 

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

테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다.

문제를 작게 나누고, 그 중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.

 

+ ) 피드백 첨부 자료 공부 및 정리

1) '숫자 야구 with 자바 기초 강의' 정리

    노션에 정리한 것 다시 복습 겸 정리
2) '학습테스트를 통해 JUnit 학습하기' PDF 정리

    assertj: contains(), containsExactly()

    JUnit: @DisplayName, @ParameterizedTest, @CsvSource

    위주로 정리

 

---

[ 3️⃣ 3주 차 공통 피드백 ]

- 함수(메서드) 라인에 대한 기준

main() 함수에도 해당되고, 공백 라인도 한 라인에 해당하니 조심하자.

 

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

예외 상황을 여러가지 고민해 보고 이에 대해 처리하도록 하자.

 

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

단일 책임의 원칙에 위배되지 않도록 하자.

객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString()을 통해 구현하자.

View에서 사용할 데이터라면 getter 메서드를 통해 데이터를 전달한다.

 

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

 

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

자바의 final 키워드를 활용하여 값의 변경을 막도록 하자.

 

- 객체의 상태 접근을 제한한다

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

 

- 객체는 객체스럽게 사용한다

상태 값으로 가지는 객체는 데이터를 get으로 꺼내지 말고 메시지를 던지도록 구조를 바꿔 데이터를 가지는 객체가 일하도록 하자.

+ ) 피드백 첨부 자료 공부 및 정리

1) 'getter를 사용하는 대신 객체에 메시지를 보내자' 정리하기

https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/

 

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

필드에 중복이 있거나, 불필요한 필드가 없는지 확인해 필드의 수를 최소화하자.

 

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

특히 프로그램에서 결함이 자주 발생하는 부분 중 하나는 경계값이므로 이 부분을 꼼꼼하게 확인하자.

 

- 테스트 코드도 코드다

테스트 코드도 코드이므로 리팩터링을 통해 개선해나가자.

특히 반복적으로 하는 부분이 중복되지 않도록, @ValuseSource와 @ParameterizedTest를 사용하자.

 

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

주신 예시 이미지를 참고해보고, 테스트하기 어려운 것을 클래스 내부가 아닌 외부로 분리하는 시도를 해보자.

+ ) 피드백 첨부 자료 공부 및 정리

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

https://tecoble.techcourse.co.kr/post/2020-05-07-appropriate_method_for_test_by_parameter/