[Chapter 10] 이름 축약은 어느 정도까지가 괜찮을까?

[corock]

10.7 에서 기본적으로 이름은 축약하지 말자는 내용이 나옵니다. 그런데 개발하다 보면 메서드 시그니처 등이 너무 길어지는 경우가 생깁니다.
예를 들어, 자바의 경우 언어 특성상 축약을 지양하고 있으나 아래처럼 축약하지 않고 다 풀어쓰면 IDE 에 기본적으로 설정된 width 값을 넘깁니다.

@Service
public class OrderCompletionService {

    // (...)

    public OrderCompletionResponse retrieveOrderCompletionInformation(final OrderCompletionRequest orderCompletionRequest) {
        // (...)
    }

    // (...)

}

그래서 retrieveXxx 같은 용어도 길다고 보고 조회는 모두 getXxx 으로 바꾸면 조금이라도 길이가 짧아지니까 축약을 선호하는 분들도 있습니다.
저는 이름 축약을 하지 않는 것과 그로 인해 길이가 길어지는 현상 간 딜레마가 있다고 보는데요. 축약은 어느 정도까지 허용되면 좋을까요?
이와 관련된 좋은 아이디어가 있거나 경험이 있다면 공유해 주시면 좋을 것 같습니다.

[corock]

추가로 메서드 등에 calculate 가 들어가면 너무 길어지니까 calc 로 하는 경우도 있고,
특히 PG(Payment Gateway) 같은 약어는 대부분의 이해관계자끼리 PG 로 소통합니다.
그럼, PG 결제 수단이라는 클래스를 설계해야 한다면 PgPaymentMethod vs. PaymentGatewayPaymentMethod 중 어떤 이름이 좋을까요?

[coalong]

이름 축약을 할 경우 같이 일하는 동료들의 이해할 수 있는 범주내에서 하는 것이 좋다고 생각합니다.
(만약 사용하려는 약어가 여러 의미가 내포되어있지 않게 명확하다면..)

위에 예시로 주신 retrieveOrderCompletionInformation 은 경우 get 으로 사용해도 의미는 통하지만 길이를 위한 것이라면
retrieveOrderCompletionInfo 이렇게 통상적으로 이해할 수 있는 범주에서 사용하는 것이 좋다고 생각합니다.

사실 저는 pg 라는 약어가 생소하지만 같이 일하는 관계자들이 모두 소통한다면, 그리고 pg 의 다른 약어가 없다면 사용해도 된다고 생각합니다.

[firewoody237]

calc는 약간 극혐이네요..
저도 고민을 해봤는데..

• 비즈니스적으로 이미 잘 알려져있는 것(ex. PG) -> PG로 쓴다.
• 애매한데 너무 긴 것(ex. Korea Airports Corporation) -> KAC로 줄여쓰고.. README.md 와 같은 곳에 적기
  • 이게 한두개면 그냥 길게 쓰려고 했는데.. 비즈니스 도메인 자체가 되버리니까 보기만해도 피로해지더라구요.