소스 트리를 어떻게 구성해야합니까? ++ (비 GUI) 프로젝트에서 일하는 개인

나는 주로 웹 프로젝트 (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