소스 트리를 어떻게 구성해야합니까?

나는 주로 웹 프로젝트 (W / LAMP)와 때로는 평균 규모의 C / C ++ (비 GUI) 프로젝트에서 일하는 개인 개발자입니다.

나는 종종 소스 코드 트리를 구성하는 데 어려움을 겪습니다. 사실, 나는 보통 전체 트리를 버리지 않고 조각을 3-4 번 재 배열하지 않고 프로젝트를 완료하지 않습니다. 실제로 많은 노력을 기울이고 최종 결과는 타협처럼 보입니다.

때로는 소스와 폴더의 긴 폴더와 하위 폴더를 과도하게 분류하는 경우가 있습니다. 다른 경우에는 단순히 더 큰 목적에 따라 특정 폴더의 모든 파일을 집중시켜 소스의 '혼돈'폴더로 연결합니다.

나는 묻고 싶다 :

• 소스 트리를보다 잘 구성하는 데 도움이되는 원칙 / 논리 / 모범 사례가 있습니까?
• 프로젝트 분석을 기반으로 소스 트리를 미리 시각화하는 데 도움이되는 그래픽 / 다이어그램 기법 (예 : 데이터 흐름의 경우 DFD)이 있습니까?
• 프로젝트와 관련된 멀티미디어 파일 트리를 구조화하기 위해 채택 할 전략은 무엇입니까?

현상금에 관하여 : 나는 자신의 관행을 공유하는 회원들과 함께 기존 답변에 감사하지만, 더 일반적이고 유익한 답변 (또는 리소스)과 회원들의 더 많은 답변을 장려하고 싶습니다.

소스 트리 레이아웃은 아키텍처를 반영해야합니다. 결론적으로 잘 구조화 된 아키텍처는 체계적으로 구성된 소스 트리 레이아웃으로 이어질 수 있습니다. POSA1 Layers 패턴을 읽고 아키텍처를 계층 구조에 맞추고 각 결과 계층의 이름을 지정한 다음이를 소스 계층의 기초로 사용하는 것이 좋습니다. 일반적인 3 계층 아키텍처 를 기준으로 삼기 :

• presentation / webService (비즈니스 로직에 대한 웹 서비스 인터페이스 제공)
• logic / * (비즈니스 로직 모듈은 여기에 있습니다)
• storage / sql (여기서 백엔드 스토리지 API-SQL 인터페이스를 사용하여 데이터베이스에 저장)
• util / * (유틸리티 코드-다른 모든 계층에서 사용 가능하지만 유틸리티 외부를 참조하지 않는 여기로 이동)

레이어에는 코드가 직접 포함되지 않고 모듈을 구성하는 데 엄격하게 사용됩니다.

모듈 내에서 다음과 같은 레이아웃을 사용합니다.

• <module> (모듈 직접 경로; 모듈 식 인터페이스 정의)
• <module>/impl/<implName> (모듈 식 인터페이스의 특정 구현)
• <module>/doc (모듈 사용 설명서)
• <module>/tb (모듈의 단위 테스트 코드)

여기서는 <module>속한 계층에 따라 저장소에서 위치합니다.

웹 프로젝트와 관련된 많은 조언을 할 수는 없지만 프로그래밍 프로젝트에서 주로 트리를 구성하는 방법은 다음과 같습니다 (주로 C / C ++ 관점에서).

• /
  • src — 본인이 작성한 소스 파일
  • ext — 타사 라이브러리를 포함합니다
    • libname-1.2.8
      • 포함 — 헤더
      • lib — 컴파일 된 lib 파일
      • Donwload.txt — 사용 된 버전을 다운로드 할 수있는 링크가 포함되어 있습니다
  • ide — 프로젝트 파일을 여기에 저장합니다
    • vc10 — IDE에 따라 프로젝트 파일을 정렬합니다
  • bin — 컴파일 된 exe는 여기로 간다
  • build — 컴파일러의 빌드 파일
  • doc — 모든 종류의 문서
  • 읽어보기
  • 설치
  • 사자

몇 가지 참고 사항 :

1. 라이브러리를 작성 중이고 C / C ++를 사용하는 경우 소스 파일을 먼저 "include"및 "src"라는 두 개의 폴더로 구성한 다음 모듈별로 구성합니다. 응용 프로그램이라면 모듈별로 구성 할 것입니다 (헤더와 소스는 같은 폴더에 있습니다).

2. 이탤릭체로 위에 나열된 파일과 디렉토리 는 코드 리포지토리에 추가하지 않습니다.

그동안 메이븐 표준 디렉토리 레이아웃 자바 가지 특정하지만, 그것뿐만 아니라 프로젝트의 다른 유형을위한 좋은 기반이 될 수 있습니다.

기본 구조는 다음과 같습니다 ( 'java'디렉토리를 'php', 'cpp'등으로 대체 할 수 있음).

src/main/java       Application/Library sources 
src/main/resources  Application/Library resources  
src/main/filters    Resource filter files 
src/main/assembly   Assembly descriptors 
src/main/config     Configuration files 
src/main/webapp     Web application sources 
src/test/java       Test sources 
src/test/resources  Test resources 
src/test/filters    Test resource filter files 
src/site            Site 
LICENSE.txt         Project's license 
NOTICE.txt          Notices and attributions required by libraries
README.txt          Project's readme

구조는 기본적으로 'src / main'과 'src / test'로 분류 된 다음 유형별로 그룹화됩니다.

나는 실제로 규칙에 대해 알지 못하지만 모든 주요 프로젝트는 Symfony Framework를 사용하여 수행되며 다음과 같은 트리 구조에 익숙해졌습니다.

뿌리/

• 앱
• app_name
  • 구성 (앱 특정 구성 파일)
  • lib (앱 특정 PHP 파일)
  • 모듈 (기능의 모듈 식 배포)
    • module_name
      • 템플릿 (html)
      • 액션 (php 코드)
• 혼동 (프로젝트 구성 파일)
• lib (홀 프로젝트에서 사용할 수있는 PHP 코드)
• 모델 (프로젝트 정보를 나타내는 클래스)
  • 베이스
• form (폼을 다루는 PHP 파일, 심포니 없이는 달성하기가 매우 어려울 수 있습니다)
  • 기본 (기본 양식 클래스)
• 편물
• CSS
  • 이미지
  • file.css
• js
• 로그 (생성 될 수있는 로그 파일)
• 데이터 (SQL 패치와 같은 데이터 특정 정보 등)
• SQL
• 플러그인 (프로젝트의 모든 앱과 병합 할 수있는 사용 된 라이브러리)

관심이 있으시면 추가 문의 사항에 대한 심포니 문서를 읽으십시오 ( MVC 및 Symfony의 코드 구성 ).

이상적으로 조직에는 엔지니어링 및 비즈니스 간의 참여를 늘리고 재사용을 촉진하기위한 단일 저장소가 있습니다.

...\products\
...\products\productName\
...\products\productName\doc\

...\systems\
...\systems\systemName\
...\systems\systemName\doc\
...\systems\systemName\res\
...\systems\systemName\build\
...\systems\systemName\test\

...\library\
...\library\libraryName\
...\library\libraryName\doc\
...\library\libraryName\build\
...\library\libraryName\test\

...\devops\

제품

제품 당 하나의 폴더; 소프트웨어가 비즈니스를 지원하는 방법을 전달하는 데 도움이됩니다.

이상적으로, 각 "제품"은 호출 할 시스템 및 구성 방법을 나타내는 구성 파일에 지나지 않습니다 . 문서 하위 폴더에는 최상위 요약 및 사양 및 프로모션 자료 등이 포함될 수 있습니다.

제품과 시스템을 분리함으로써 재사용 가능성을 비즈니스의 고객 대면 측에 전달하고 제품 별 사일로를 분류합니다. (이는 동일한 문제에 대한 "제품 라인"접근 방식과 대조됩니다)

시스템

시스템 당 하나의 폴더; 리포지토리 내용의 주요 기능 및 기회 / 값을 전달하는 데 도움이됩니다.

1. 빌드 및 배치 환경을 지정하는 "구성 관리"파일
2. 시스템 수준 테스트 구성 (대량 일 수 있음).
3. 최상위 논리 및 기능; 대부분의 무거운 리프팅은 라이브러리 기능에 의해 수행됩니다.

도서관

다양한 시스템에서 호출 한 재사용 가능한 구성 요소. 대부분의 개발 활동은 시스템이 아닌 라이브러리 제작을 중심으로 구성되므로 재사용은 개발 프로세스에 "구속됩니다".

devops

빌드, 지속적인 통합 및 기타 개발 자동화 기능.

결론

소스 트리는 주요 문서로, 독점 기술과 비즈니스 관계의 접근 방식, 구조 및 심리학을 형성합니다.

이 접근법의 드라이버는이 질문에 대한 대답에서 조금 더 깊이 설명되어 있습니다.

각 프로젝트마다 내가하려고하는 것은 다음과 유사합니다.

• src- 소스 파일, 각 네임 스페이스 / 패키지에서 파일을 쉽게 검색 할 수있는 폴더 (C / C ++ 용 헤더 파일 포함)
• ext- 외부 / 타사 라이브러리의 경우 외부 (예 : SVN 리포지토리)를 추가하는 것이 간단합니다. 내부, 각 라이브러리의 폴더 (바이너리 및 포함 파일)
• bin- 빌드 된 바이너리의 경우 릴리스를 위해 빠르게 내보낼 수 있습니다.
  • inc -C / C ++ 헤더 파일 (IDE / makefile / etc로 복사)
• 에서 - 모든 임시로 생성 된 파일 (을 .class, .OBJ 등) 및 것이 (SVN에 의해 예를 들어) 무시 될 수있다
• doc- 일반적으로 Doxygen으로 생성 된 모든 문서
• res- 리소스를 여기에두면 프로그램에서 사용하는 텍스트 소스 파일과 바이너리 리소스를 분리 할 수 ​​있습니다. 내부에 특정 계층 구조가 없습니다.
  • config- 일부 구성 파일
  • 드로어 블 -일부 사진 또는 아이콘

모든 IDE 파일 또는 make 파일은 그 중 하나만 사용하는 경우 루트에 직접 저장됩니다.

나는 이런 식으로합니다. 여가 시간에 크로스 플랫폼 게임에 적합합니다. 불행히도 직장에서는 상황이 훨씬 덜 체계적입니다 ...

Output                      <-- Build outputs
Docs
External
   <libname>
      Include
      Lib
Data
<ProjectName>.xcodeproj
<ProjectName>VS2010
Source
Temp                        <-- Intermediate stuff from builds and other tools
Tools

팀의 경우 팀이 상황을 전환하고 매번 다시 학습하지 않아도되는 것을 쉽게 찾을 수 있도록 프로젝트 전체에 표준 구조를 적용하려고합니다. 모든 프로젝트에 모든 시스템이 필요한 것은 아니므로 최소 세트로 시작합니다.

/ 소스 / 구성 요소 / 언어

/ 소스 / 구성 요소 / 3 자 /

/ 문서 / 요구 사항

/ 문서 / 디자인

/ 테스트 / 자동 / 단위

/ 테스트 / 자동 / 도구 이름

/ 테스트 / 수동

이로 인해 특히 제 3 자 코드 및 라이브러리에서 중복이 발생하지만 적어도 "RogueWave 편집기는 무엇을 사용합니까?"

나는이 페이지 www.javapractices.com/topic/TopicAction.do?Id=205에 제시된 아이디어를 좋아한다 . 기본적으로 권장 사항은 프로젝트를 기능 (또는 모듈, 구성 요소)으로 구성하는 것입니다. 거기에 제시된 이유 외에도 :

1. 작업중인 기능의 코드가 "기능 전용"임을 보증하므로 작업중인 코드의 범위에 대해 생각할 때 인지력이 떨어집니다.
2. 특정 기능에 대한 코드 만 수정한다고 보장 할 경우 보안에 대한 추가 인식이 있습니다. 예를 들어, 작업중인 기능 이외의 다른 기능은 중단하지 않습니다. 다시 이것은 "기능-개인"때문입니다.
3. 주어진 패키지에 대해 볼 수있는 파일이 적기 때문에인지 부하가 ​​적습니다. 모든 사람이 15 개가 넘는 파일이 포함 된 패키지를 보았을 것입니다.

이것은 Java 패키지 (일명 네임 스페이스)에 중점을 둡니다. 큰 프로젝트의 경우 같은 이유로 비즈니스 기능을 나타내는 여러 프로젝트 (여러 메이븐 프로젝트에서와 같이)로 프로젝트를 나누는 것이 좋습니다. maven 프로젝트의 경우이 독서를 권장합니다 .

지금까지 내가 참여한 프로젝트는 이러한 프로젝트를 따르지 않습니다. 여러 가지 이유가 있지만 몇 가지가 있습니다.

1. Java 기본 액세스 수정 자의 오해 (이 책에 따라 대부분의 오해 수정 자 )
2. "Argumentum ad populum": 일반적인 패키지 별 문화 (이유 # 1이 원인 일 수 있음)

건축가 Alexander가 말한 것처럼 프로젝트 시작시 프로젝트 소스 구성을 심각하게 고려하지 않으면 복잡성을 방지 할 수있는 기회가 없다고 생각합니다.

"어떤 디자이너라도 당신에게 말하듯이, 그것은 가장 중요하게 생각되는 디자인 프로세스의 첫 단계입니다. 양식을 만드는 처음 몇 번의 스트로크는 나머지 운명을 전달합니다." -크리스토퍼 알렉산더

프로젝트의 규모와 복잡성에 따라 비용이나 ROI를 줄일 수있는 기회를 놓칠 수 있습니다. (정확한 숫자를 확인하기위한 연구를보고 싶습니다)

다양한 프레임 워크 또는 엔진을 다운로드하고 대규모 개발 팀이 폴더 레이아웃을 어떻게 처리했는지 확인하는 것이 좋습니다.

파일을 구성하는 방법은 너무 많아서 하나를 선택하고 주어진 프로젝트에서 고수하는 것이 좋습니다. 버그를 피하고 불필요한 시간을 잃지 않도록 완료 또는 수정 될 때까지 특정 규칙을 준수하십시오.

웹 프로젝트 용 Laravel, Symphony 또는 Codeigniter 프레임 워크를 다운로드하여 즉시 폴더 레이아웃을 사용할 수 있습니다.

따라서 모든 개발에 공통적 인 폴더 레이아웃을 전달하려고합니다.

MVC (Model View Controller)는 조직의 좋은 패러다임을 제공합니다.

루트 소스 코드는 src (C ++) 또는 앱 (웹 개발) 일 수 있습니다.

그룹화하는 클래스에 대한 명확한 목표가없는 파일 구조는 확실히 혼란을 야기 할 것입니다. 코드를 구성 할뿐만 아니라 자동 로더, 클래스 팩토리, 로컬 스토리지 랩, 원격 스토리지 및 네임 스페이스를 유지할 수 있습니다.

이 폴더 구조는 Laravel Framework 에서 파생되고 단순화되었습니다 . 이 게시물에 대한 선호는 복수 명명이지만 프로젝트에서 단수형을 사용합니다.

src / storage (모델 / 파일 저장 / api / mysql / sql-lite / memcached / redis 구현)

src / repositories (일부 스토리지 로직, 공통 인터페이스 및 리턴 결과 규칙이있는 '스토리지 구현'래퍼)

src / 서비스 | 논리 | 엔티티 (앱 비즈니스 로직)

src / controllers (웹 개발에서 서버 요청을 서비스로 라우팅하는 데 사용)

src / 모듈 | 시스템 (프레임 워크 일반 기능을 확장하는 모듈 형 시스템. 서비스는 모듈을 사용할 수 있지만 그 반대는 아닙니다)

src / helpers (예 : 문자열 조작과 같은 도우미 또는 래퍼 클래스. 많은 경우 타사에서 libs | vendor에있을 수 있음)

src / types (명명 된 열거 형)

공개 | 빌드 | 출력 (웹 또는 C ++)

config (설정 파일. YAML은 플랫폼 간 구성 파일에 널리 사용됩니다)

은닉처

로그

랭 (en / es / ru / ...)

부트 스트랩 (프레임 워크 및 앱 시작)

docs (마크 다운 형식 .md로 작성된 문서)

테스트 (단위 테스트)

데이터베이스 / 마이그레이션 (처음부터 데이터베이스 구조 작성)

데이터베이스 / 시드 (테스트 할 더미 데이터로 데이터베이스를 채 웁니다)

라이브러리 | 공급 업체 (모든 타사 소프트웨어. C ++의 'libs'및 일반적으로 PHP의 'vendor')

자산 | 리소스 (이미지 / 사운드 / 스크립트 / json / 모든 미디어)

객체 지향 언어를 사용하면 네임 스페이스를 만들 수 있습니다. 커플 링을 피하기 위해 애플리케이션의 일부를 분리하는 데 사용되는 논리적 분석은 논리적 파일 위치 분석의 주요 소스입니다. 네임 스페이스를 분리하는 이유로 커플 링을 사용하는 것이 http://en.wikipedia.org/wiki/Software_package_metrics 를 시작하기에 좋은 장소 입니다.

다른 사람들은 빌드와 관련하여 프로젝트를 설정하는 것에 대해 이야기했지만 소스 자체에 들어가면 의미가 있습니다. 어쨌든 논리적으로 코드를 분리하는 방법을 사용하십시오.