아이템 51 : 메서드 시그니처를 신중히 설계하라

[jinan159]

0. 들어가며

이번 아이템을 살짝 훑어보면, 좋은 메서드를 만들기 위한 규칙을 설명합니다.

먼저 규칙들을 설명하기에 앞서, 규칙들을 왜 제안하는지 생각해봤습니다.

1. 일관성 없는 메서드명
2. 메서드가 너무 많아서 뭘 써야할 지 모르는 상황
3. 매개변수가 너무 많아서 헷갈리는 상황

대표적으로 이런 경우들로 생각해볼 수 있고, 아마 다들 한번쯤은 겪어보셨을 것이라 생각합니다.

이제 필자가 어떤 규칙들을 제안하고, 그 규칙들을 지키면 위와 같은 상황을 해결할 수 있는지 살펴보겠습니다.

1. 메서드 시그니처 규칙

필자가 제안한 메서드 시그니처 규칙은 다음과 같습니다.

• 메서드 이름을 신중히 짓자
  • 표준 명명 규칙(아이템68)을 따르자
  • 같은 패키지 속의 다른 이름들과 일관되게 짓자
  • 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하자
  • 너무 긴 이름은 피하자
• 편의 메서드를 너무 많이 만들지 말자
  • 메서드가 너무 많은 인터페이스는 사용하기도, 구현하기도 힘듦
  • ‘확신이 서지 않으면 만들지 말자’
• 매개변수 목록은 짧게 유지하자
  • 4개가 넘어가는 순간 헷갈리기 쉬움
  • ‘같은 타입이 연속해서 나오는 경우는 아주 안좋음’
  • 이러한 문제를 해결하는 기술
    1. 여러 메서드로 쪼개기
    2. 매개변수 여러개를 묶는 클래스
    3. 빌더 패턴 사용
• 매개변수 타입으로는 인터페이스가 더 나음(아이템 68)
• boolean 보다는 원소 2개짜리 열거 타입이 더 나음

하지만 저는 이 보다 더 중요한 것이 있다고 생각하는데요.

그건 바로 내가 일하고있는 팀의 컨벤션 입니다.

2. 팀 컨벤션

저는 백엔드 개발자로 취업하여 2주 정도 일한 상태인데요.

적응 중이라 그런지 동료분들이 리뷰 해주실 때, 많이 알려주시는것 중 하나가 컨벤션 관련 내용입니다.

컨벤션을 유지하는 이유는 형식을 비슷하게 유지하면 코드를 읽을때 피로가 덜하고 가독성이 좋기 때문입니다.

그래서 제 경험을 바탕으로 어떤 부분들을 중점적으로 파악하면 좋을지 정리해봤습니다.

2.1 메서드명

메서드명은 보통 자주 쓰는 단어들을 많이 쓰게되니, 컨벤션을 딱 맞추지 않아도 됩니다.

하지만, 미묘하게 스타일이나 사용하는 단어가 다르기도 합니다.

길게 풀어쓰는 스타일 vs 짧고 제너럴한 단어로 표현하는 스타일

// 이렇게 길게 풀어쓰는사람이 있는가 하면
class Order {
	public static Order createOrderWithMenu(Menu menu) { ... }
}

// 이렇게 이펙티브 자바에서 제안하는 팩터리 메서드 방식으로 작성하기도 함
class Order {
	public static Order from(Menu menu) { ... }
}

영어 문장같은 메서드명 vs 가독성 좋은 짧고 간단한 단어

// 메서드의 동작을 영어로 풀어서 작성 하는가 하면
class ReviewService {
	public boolean isPossibleToCreateReview(Review review) { ... }
}

// 심플한 단어로 표현하기도 함
class ReviewService {
	public boolean canCreateReview(Review review) { ... }
}

메서드의 앞에 vs 메서드의 뒤에(boolean 반환 vs 예외 터트리기)

// isValid 라고 명명하고 boolean 을 반환하도록 구현하거나
class Something {
	public boolean isValidSomething() { ... }
}

// 검증하여 메서드 자체에서 예외를 발생시키기도 함
class Something {
	public void somethingValidation() { ... }
}

이 외에도 상황에 따라 컨벤션에 따라 다양한 단어들을 선택해서 사용합니다.

• find~ vs get~
• create~ vs get~
• sort vs orderBy

등등..

2.2 파라미터

파라미터는 보통 개수에 따라 어떻게 달라지는지 확인해볼 수 있습니다.

적당한 파라미터는 괜찮 vs DTO 조아

// 이렇게 4개 정도는 그냥 쓰는가 하면
class Something {
	public void doSomething(int num, String str, char chr, boolean isReal) { ... }
}

// 2개 이상만 되도 DTO 로 만드는 사람도 있음
class Something {
	public void doSomething(Dto dto) { ... }
}

record Dto(int num, String str) { }

왼쪽에서 오른쪽으로 vs 위에서 아래로

// 끝을 모르게 쭉쭉 붙이는 사람이 있는가 하면
class Something {
	public void doSomething(int num, String str, char chr, boolean isReal, long howLong, short howShort) { ... }
}

// 이렇게 세로로 쭉 내려 쓰느 사람도 있음
class Something {
	public void doSomething(
		int num, 
		String str, 
		char chr, 
		boolean isReal, 
		long howLong, 
		short howShort
	) { 
	// 구현부 ... 
	}
}

// 그리고 이렇게 첫번째 인자 이후로만 내려쓰는 경우도 있음
class Something {
        public void doSomething(int num, 
                                String str, 
                                char chr, 
                                boolean isReal, 
                                long howLong, 
                                short howShort) {
	// 구현부 ...
	}
}		

위 예제의 3번째 경우는 회사에서 동료분이 쓰시는 스타일을 보고 배웠는데요.

2번째는 구현부와 들여쓰기가 같아 한눈에 들어오지 않을 수 있는데요.

3번째는 구현부와 들여쓰기 차이가 있기 때문에 파라미터 선언과 구현부가 확실히 구분된다는 장점이 있습니다.

이 외에도 다음과 같은 고려사항이 있을 수 있겠네요!

• Wrapper type 사용 여부
• Primitive type을 앞에 vs Reference type 을 앞에

등등

[Irisation23]

컨벤션을 보다보니 프로젝트 진행하면서 받았던 피드백이 기억나네요.

팀 컨벤션을 토대로 코드를 작성하기를 약속하고 프로젝트를 진행했었습니다.
저희는 모두다 똑같은 규칙을 특히 컨벤션 관련으로 엄격하게 적용하며 코드리뷰를 했었습니다.
다같이 하나가 되어 코드를 만들 수 있다면 가장 이상적이지 않을까? 라는 기대를 하며 코드리뷰에 대한 피드백을 기다렸습니다.

하지만 돌아온 피드백은 '너무 엄격하게 컨벤션을 지키며 하나의 코드 스타일대로 코드를 짜게 된다면 개인의 스타일을 담지 못한다.' 라는 피드백이 왔었습니다.
피드백 후에는 약간 느슨하게 컨벤션을 지키는 구조로 가게 되었고, @jinan159 정리해 주신 글을 쭉 읽다보니 어느정도는 개인의 스타일을 담는게 좋아보이네요.

정리 감사드립니다.

여담으로 팩터리 메서드 패턴도 블로크 형님이 좋아하는 패턴인 것 같습니다.

[YuDeokRin]

최근에 진행된 프로젝트에서 구글 컨벤션을 보고 그걸 따라서 하는데, 어렵더군요. 어려운 이유 중 하나가 습관이 안 들어서인 것 같습니다. @jinan159 님처럼 회사에서 코드 리뷰를 통해서 고쳐나가는 게 좋긴 한 것 같습니다.