이름 짓기
단수와 복수를 구분하기
이름 줄이지 않기
은어/방언 사용하지 않기
좋은 코드를 보고 습득하기
메서드와 추상화
•
잘 쓰여진 코드라면, 한 메서드의 주제는 반드시 하나다.
메서드 선언부
메서드명
•
추상화된 구체를 유추할 수 있는, 적절한 의미가 담긴 이름
•
파라미터와 연결지어 더 풍부한 의미를 전달할 수도 있음
파라미터
•
파라미터의 타입, 개수, 순서를 통해 의미를 전달
•
파라미터는 외부 세계와 소통하는 창
반환타입
•
메서드 시그니처(메서드명+파라미터)에 납득이 가는, 적절한 타입의 반환값 돌려주기
- ex) 반환타입이 boolean인데, 이 메서드에서 무엇을 의미하는지
•
void 대신 충분한 반환할만한 값이 있는지 고민해보기
- 반환값이 있다면 테스트도 용이해짐
매직 넘버, 매직 스트링
•
의미를 갖고 있으나, 상수로 추출되지 않은 숫자, 문자열 등
•
상수 추출로 이름을 짓고 의미를 부여함으로써 가독성, 유지보수성↑
사고의 depth 줄이기
•
중첩 분기문, 중첩 반복문
무조건 1 depth로 만들어라 ⇒ X
•
보이는 depth를 줄이는 데에 급급한 것이 아니라,
추상화를 통한 사고 과정의 depth를 줄이는 것이 중요
•
2중 중첩 구조로 표현하는 것이 사고하는 데에 도움이 된다고 판단한다면, 메서드 분리보다 그대로 놔두는 것이 더 나은 선택일 수 있다.
•
때로는 메서드를 분리하는 것이 더 혼선을 줄 수도 있다.
•
사용할 변수는 가깝게 선언하기
공백 라인을 대하는 자세
•
공백 라인도 의미를 가진다.
◦
복잡한 로직의 의미 단위를 나누어 보여줌으로써 읽는 사람에게 추가적인 정보를 전달할 수 있다.
부정어를 대하는 자세
•
부정어구를 쓰지 않아도 되는 상황인지 체크
•
부정의 의미를 담은 다른 단어가 존재하는지 고민 or 부정어구로 메서드명 구성
(부정연산자(!)의 가독성↓)
해피 케이스와 예외 처리
•
예외가 발생할 가능성 낮추기
•
어떤 값의 검증이 필요한 부분은 주로 외부 세계와의 접점
→ 사용자 입력, 객체 생성자, 외부 서버의 요청 등
•
의도한 예외와 예상하지 못한 예외를 구분하기
→ 사용자에게 보여줄 예외와, 개발자가 보고 처리해야할 예외 구분
Null을 대하는 자세
•
항상 NullPointerException을 방지하는 방향으로 경각심 가지기
•
메서드 설계 시 return null을 자제
→ 어렵다면 Optional 사용을 고민
•
Optional에 관하여
◦
Optional은 비싼 객체. 꼭 필요한 상황에서 반환 타입에 사용
◦
Optional을 파라미터로 받지 않도록 한다. 분기 케이스가 3개나 됨
(Optional이 가진 데이터가 null인지 아닌지 + Optional 그 자체가 null)
◦
Optional을 반환받았다면 최대한 빠르게 해소
•
Optional을 해소하는 방법
◦
분기문을 만드는 isPresent() - get() 대신 풍부한 API 사용
ex) orElseGet(), orElseThrow, ifPresent(), ifPresentOrElse()
◦
orElse(), orElseGet(), orElseThrow()의 차이 숙지
