소프트웨어 엔지니어/일반

프로그램 디렉토리 구조?

shroomie 2024. 8. 9. 14:39

프로그램 디렉토리 구조? 나누는 기준은?

규모가 크지않은 프로젝트의 경우 오히려 디렉토리나누지 않는게 도움이 될수도 있어 (구조가 복잡해지지 않고 한곳에 필요한 파일이 다 있으니까) 
a flat structure 


그런데 규모가 커지고 일하는 사람이 많아지게 되면 하나의 디렉토리에 모든 파일을 다 담는건 비효율 적이지. 
그럼 어떤구조로 디렉토리를 나눌까?
내가 어떤 문제가 생겨서 코드를 봐야할 경우가 생겼을때 , 디렉토리 구조만 가지고도 아! 여기 보면 되는구나 라고 생각이 들도록 
만드는게 좋은 구조라고 생각해(이럴라면 같이 일하는 사람의 동의? 가 있어야겠지) 

예를 들어 리눅스 커널 구조를 살펴보자. 그리고 내가 만든 led 드라이버에서 문제가 생겼다면, 
아래에서 누가 봐도 /driver 안에서 뒤져야 한다고 생각할수 있지 않을까?
또 예를 들어서 arm64 -> x86 으로 변경하는 프로젝트를 진행한다고(이런건 없겠지만) 가정해 보면
/arch 디렉토리가 가장 먼저봐야 하는 디렉토리라고 생각하지 않을까?

 

├── COPYING
├── CREDITS
├── Documentation
├── Kbuild
├── Kconfig
├── LICENSES
├── MAINTAINERS
├── Makefile
├── README
├── arch
├── block
├── certs
├── crypto
├── drivers
├── fs
├── include
├── init
├── io_uring
├── ipc
├── kernel
├── lib
├── mm
├── net
├── rust
├── samples
├── scripts
├── security
├── sound
├── tools
├── usr
└── virt

 

그리고 golang 같은 경우는 개발자들끼리 어느정도 표준(?)처럼 정해놓은 디렉토리 구조가 있어. 

https://github.com/golang-standards/project-layout 참고해보고 

머 , 어플리케이션은 cmd 폴더에 넣고, 

configs 폴더라던가....

이런 layout 을 따라서 프로그램을 해 놓으면,

다른 개발자가 보더라도, "아 여기저기 보면 되는구나 생각할수 있어서 효율적이겠지~?"

(하지만 앞에서도 말했듯이 어느경우에는 그냥 한 폴더에 다 때려넣는게 오히려 더 효율적일수도있따는..

즉 정답은 없고 상황에 맞게~)

├── api
├── assets
├── build
├── cmd
├── configs
├── deployments
├── docs
├── examples
├── githooks
├── go.mod
├── init
├── internal
├── pkg
├── scripts
├── test
├── third_party
├── tools
├── vendor
├── web
└── website