[Go] 패키지 네이밍(package naming)

패키지 네이밍은 어떻게 해야하나

Go로 첫 프로젝트를 진행하면서 여러 고민이 있다.

• 코딩컨벤션
• 디렉터리 구조
• 패키지 네이밍
• 동시성과 성능
• 마이크로서비스에서 서비스를 나누는 기준과 repository의 분리
• 등등.. 당장 생각나는 것만 적어도 5가지나 있다.

다행이 Go는 컨벤션 같은 가이드라인이 문서로 잘 되어 있어서 궁금증을 쉽게 해결할 수 있다.

패키지 이름은 단순하게

협업을 한다면 패키지를 봤을 때 최대한 직관적이고 단순하게 작명하는 것이 좋다.

이를 위해 Go에서는 Snake case와 Camel case 네이밍을 사용을 하지 않는다.

• example
  • priority_queue
  • computeServiceClient

다른 언어에선 바람직하지만 Go에선 그렇지 않다.

이름이 길면 신중하게 줄여라

• strconv(string conversion)
• syscall (system call)
• fmt (formatted I/O)

개발자가 사용하기 좋은 네이밍을 뺏지 마라

buffer는 흔히 buf로 변수명을 짓곤 한다.

buffer에 관련된 패키지 명을 우리가 buf로 선점해버리면 개발자는 네이밍에 고통받게 될 테니 bufio (buffered I/O) 정도로 배려해주는게 좋다

패키지의 함수명은 단순하게 지어라

패키지의 함수를 접근할 때 패키지.함수명()으로 접근하게 된다. 패키지명이 rpc고 함수명을 RpcServer()면 rpc.RpcServer()가 된다.

최대한 단순하고 직관적으로 작성하기 위해서는 rpc.Server()로 짓는 것이 바람직하다.

또한 패키지를 분류할 수 있으면 디렉토리 쪼개듯이 분류 하는 것이 좋다.

encoding_base64 패키지보다 encoding/base64가 더 낫다.

encoding 패키지에는 encoding/json도 있다.

API를 한 패키지에 몰빵하지 말자

많은 프로그래머들이 api 패키지를 만들어서 API 들을 해당 패키지 안에 다 구현하는데 이건 문제가 있다. util이나 common과 같은 이름으로 패키지 만들 때도 마찬가지다. bound(영역) 없이 만들면 사용하는 개발자에겐 패키지간 의존성이나 import 할 때 가이드라인이 없는 문제가 발생한다. 디렉토리 분리하듯이 잘 분리하자

유명한 표준 패키지 이름을 사용하지 말자

이미 io나 http는 많은 개발자들이 사용하고 있다. 이는 피하는게 좋다.

Reference

https://blog.golang.org/package-names