2주차 공통 피드백 및 나의 회고

README에 문서화할 때, 구현해야 할 기능에 집중한다.

문서화를 통해 먼저 프로젝트에 대한 개요 및 내가 구현하고자하는 기능 목록을 정리하고 기능 구현에 들어갔는데, 여기에서도 피드백 받은 부분이 있었다.

가장 중요한 두 포인트는 다음과 같다. 우선, 첫째. 클래스/함수 설계 내용을 너무 상세히 적지 않는다는 것이다. 함수명, 함수 파라미터 및 반환값 등은 언제든 변경될 수 있기 때문에 초기 설계 때에는 지정해두지는 않는다.

대신, 예외 상황에 대해 정리를 상세히 해두자. 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에, 기능을 구현하면서 계속 추가해나간다. 이는 다른 피드백과도 이어져서, '죽은 문서가 아닌 살아있는 문서를 만든다'는 문장이 있었는데 무척 인상이 깊었다.

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

문자열, 숫자 등의 값을 하드코딩하지 않으려고 노력해보라는 것이었다. 이는 알고리즘 문제 풀이에 익숙해져있던 나인지라 매우 뼈를 때리는 조언이었다. 이 피드백을 본 후에는 Enum값이나 상수를 설정하여 하드코딩을 최대한 지양하고자 했다.

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

이 역시도 매우 새로운 사실이었다. 클래스는 상수/클래스 변수 -> 멤버 변수 -> 생성자 -> 메서드 순으로 작성하는 것 역시도 컨벤션이라고 한다.

class A {
	상수(static final) 또는 클래스 변수
    
    인스턴스 변수
    
    생성자
}

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

이 부분도 정말 생각지도 못한 부분이었다. Spring에서 자동으로 생성해주는 후보 이름 중에 예를 들면 member이면 memberList를 추천해주었고, 이를 정말 즐겨 썼기 때문이었다.

💡 자료형이 들어가면 왜 안 좋은 네이밍일까?

• 변수 이름에 자료형을 쓰지 않아도 타입을 통해 충분히 어떤 변수인지 파악이 가능하다.
• 만약 List를 쓰던 변수를 Set으로 자료구조를 바꾸게 될 경우, 기존 변수명이 적절한 의미를 나타내지 못하게 되므로 결국 변수명을 변경해야 한다. -> 이런 경우 방지!
• List, Collection 등의 자료형은 자료형을 네이밍에 그대로 쓰기보다는 복수형으로 표현하는 것이 좋다.

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

예를 들어, 한 함수의 길이가 길어진다면 한 함수가 여러 일을 하려고 하는 경우일 가능성이 있다.

• 변경 전 : 한 함수가 안내 문구 출력, 사용자 입력, 유효값 검증 등의 기능을 함

• 변경 후 -> 안내 문구 출력 함수, 사용자 입력 함수, 유효값 검증 함수 등

테스트를 작성하는 이유

• 기능을 점검할 수 있다. 특히, 나의 경험으로는 예외 경곗값들을 통한 예외처리를 많이 점검하고 고칠 수 있었다.

• 나의 코드에 대해 빠르게 피드백을 받을 수 있다. 단위테스트를 하다보니 더욱 클래스를 어떻게 나눌 것인가, 지금이 최선의 구조인가 등을 고민해볼 수 있었따.

• 학습 도구로 사용할 수 있다. 이번 주차의 미션 같은 경우는 우테코 측에서 제공하는 외부 라이브러리를 꼭 사용하여 구현하고 테스트해야 한다는 요구사항이 있었는데, 이를 통과하기 위해 테스트코드를 뜯어보면서도 많은 학습이 되었다.