코드베이스에서 파일을 올바르게 구성하고 신체 상해를 피하는 방법-IT산업-php.cn

How to Properly Organize Files in Your Codebase & Avoid Mayhem 대형 코드 기반의 조직 및 유지 보수 : 메인 라이브러리, 데이터, UI, 문서 및 위키, 테스트, 레거시 구성 요소 및 타사 구성 요소 ...이 모든 컨텐츠의 순서를 추적하고 유지하는 방법? 코드베이스에서 파일 구성은 어려운 작업이 될 수 있습니다.

걱정하지 마세요 - 우리는 할 수 있습니다! 이 기사는 소규모 및 대형 프로젝트에 가장 일반적으로 사용되는 시스템을 검토하고 팔로우하기 쉬운 모범 사례를 제공합니다.

키 포인트

코드베이스에서 파일 구성은 나중에 컨텐츠에 액세스하고 검토해야 할 때 문제를 줄이고 시간을 절약 할 수 있습니다. 파일 명명, 프로젝트 문서화 처리 및 효과적인 워크 플로 구성에 대한 기본 규칙을 설정하는 것이 매우 중요합니다.

각 소프트웨어 프로젝트에는 readme, changelog, 복사 라이센스 및 .gitignore 파일이 있어야합니다. 프로젝트 상황에 따라 저자, 버그, 기고/해킹, FAQ, 설치, 뉴스, 감사, TODO/로드 맵, 버전/릴리스와 같은 다른 파일도 포함 할 수 있습니다.

파일은 구성 요소 또는 서브 시스템의 폴더로 구성되어야하지만, 관리가 가능한 상태를 유지하기 위해 디렉토리를 만들어야합니다. 데이터, 이진 파일 및 설정과 같은 특정 유형의 파일은 프로젝트에서 제외해야합니다.

문서 조직의 핵심은 일관성에 있습니다. 디렉토리 나 파일의 명명이든 프로젝트의 구조이든 일관성을 유지하면 코드 기반을 쉽게 탐색하고 이해할 수 있습니다.

왜 귀찮게합니까?

거의 모든 프로젝트 관리 관련 작업 (문서화, 소프트웨어 제출, 배포)과 마찬가지로 의식적이고 프로그래밍 방식의 접근 방식으로 큰 혜택을받을 수 있습니다. 이것은 현재 문제를 줄일뿐만 아니라 컨텐츠에 신속하게 액세스하고 검토해야 할 때 귀하와 팀의 귀중한 시간을 절약 할 수 있습니다.

당신은 지금 쓰고있는 내용의 기능 이름을 확실히 기억하고 편집하는 데 필요한 파일을 빠르게 찾아서 무엇이 작동하는지, 그렇지 않은 것 또는 생각하는 것을 명확하게 알 수 있습니다. 그러나 작년에 일한 프로젝트에 대해 똑같은 말을 할 수 있습니까?

인정하자 : 소프트웨어 프로젝트는 몇 달 또는 수년간의 무 활동이 지속될 수 있습니다. 간단한 README 파일은 동료 나 미래를 위해 많은 일을 할 수 있습니다. 그러나 프로젝트를 구축하고 파일 이름을 지정하고 프로젝트 문서를 처리하며 시간의 테스트를 의미하는 효과적인 워크 플로를 구성하는 몇 가지 기본 규칙을 구축 할 수있는 다른 방법을 고려해 봅시다.

사물 이해 우리는 조직 프로젝트의 문서에 대한 "기준"을 설정합니다. 소프트웨어 개발 범위 내에서 많은 상황에서 우리에게 도움이되는 논리입니다.

코드베이스 변경을 올바르게 제출하는 규칙과 마찬가지로, 이들 중 어느 것도 돌로 설정되어 있지 않으며, 그 가치면에서 귀하와 귀하의 팀은 다른 지침 원칙을 제안 할 수 있습니다. 어쨌든, 일관성은 게임의 이름입니다. 합의에 도달 한 후 규칙이 무엇인지 이해하고 논의하거나 논쟁하십시오.

필수 문서 이것은 거의 모든 소프트웨어 프로젝트가 가져야하는 파일의 참조 목록입니다.

<:> README : 이것은 소스 트리 아래에서 Github가 제공하는 것입니다. 이는 프로젝트의 내용, 파일 구성 방법 및 추가 정보를 찾을 수있는 위치를 설명하는 데 도움이 될 수 있습니다.

<:> changelog : 각 버전 또는 개정에 새, 수정 또는 비활성화 된 컨텐츠를 나열합니다. 일반적으로 편의성을 위해 반체 학적 순서로 (최신 변경 사항은 최전선에 있습니다).

<: :> 복사 라이센스 : 소프트웨어를 다루는 라이센스의 전체 텍스트를 포함하는 파일 및 필요한 경우 다른 저작권 정보 (예 : 타사 라이센스).

.gitignore : GIT를 사용한다고 가정하면 (가장 많이 사용 가능성이 가장 높음), 리포지토리와 동기화되지 않은 파일을 알리기 위해서도 필요합니다. (.gitignore에 대한 자세한 내용은 Jump Start Git Get Start Guide and Documentation을 참조하고 일부 아이디어는 .gitignore 템플릿의 유용한 컬렉션을 확인하십시오.)

지지자 프로젝트 상황에 따라 다른 문서를 포함시킬 수도 있습니다. 저자 : 코드를 작성하는 데 관련된 사람의 귀속. 버그 : 새로운 발견 오류를보고하기위한 알려진 문제 및 지침.
FAQ : 당신은 이미 이것이 무엇인지 알고 있습니다. ;) <..> 설치 : 다른 시스템에서 소프트웨어를 컴파일하거나 설치하는 방법에 대한 지침.

뉴스 : ChangeLog 파일과 유사하지만 개발자가 아닌 최종 사용자의 경우.

감사합니다 : 감사합니다.

TODO/RODMAP : 예정된 기능 목록.

<: :> 버전/릴리스 : 현재 버전 번호 또는 배포 이름을 설명하는 코드 줄.

구성 요소 또는 서브 시스템의 폴더 우리는 종종 단일 개념으로 결합 할 수있는 일련의 함수를 만납니다.

몇 가지 예는 다음과 같습니다

국제화 (I18N) 및 현지화 (L18N) 인증 모듈 타사 추가 기능
일반 도구 및 크론 과제 사용자 인터페이스 (UI) 및 그래픽 사용자 인터페이스 (GUI)
이 모든 것이 단일 "구성 요소"또는 "서브 시스템"디렉토리로 구성 될 수 있지만 미치지 마십시오!
우리는 루트 디렉토리 (주요 구성 요소가 여기에있을 것임) 또는 재귀 적으로 (각 디렉토리 내)를 관리 할 수 있도록 디렉토리 생성을 제한하려고합니다. 그렇지 않으면, 우리는 잘 조직 된 디렉토리로 파일을 정기적으로 탐색하는 데 많은 시간을 소비 할 수 있습니다.
소스 트리에서 를 제외하십시오 우리는 프로젝트가 깔끔하고 질서 정연하기를 원하지만 프로젝트에서 완전히 제외되기를 원하는 문서가 있습니다.

데이터. CSV 파일 등의 소스 트리에 데이터/디렉토리가있는 경우, 특히 몇 킬로바이트 만 차지하는 경우에 데이터/디렉토리가있는 유혹을받을 수 있습니다. 그러나 그들이 메가 바이트 나 기가 바이트를 섭취한다면 (요즘 드문 일이 아님)? 코드베이스와 마찬가지로이
를 코드에 제출하고 싶습니까? 아니요.
<..> 바이너리 파일. 비디오 렌더링 또는 컴파일 된 실행 파일이 소스 코드 옆에있는 비디오 렌더링 또는 컴파일을 원하지 않습니다. 이것들은 개발 파일이 아니며 여기에 전혀 속하지 않습니다. 데이터 파일과 마찬가지로 많은 공간을 차지할 수 있습니다.

설정. 이것은 또 다른 큰 금기입니다. 코드 기반에 자격 증명, 암호 또는 보안 토큰을 배치해서는 안됩니다. 여기서는이 문제에 대한 해결책을 다룰 수 없지만 Python 개발자 인 경우 Python Decouple 사용을 고려하십시오.
사례 1 : 웹 애플리케이션 데스크탑이나 모바일 장치에서 브라우저를 통해 액세스 할 수있는 웹 서버에서 실행되는 소프트웨어 인 웹 응용 프로그램을 고려해 봅시다. 또한 멤버십을 제공하는 웹 애플리케이션이라고 가정합니다. 멤버십은 독점적 인 보고서, 여행 팁 또는 비디오 라이브러리 등 일부 프리미엄 서비스에 액세스 할 수 있습니다.
파일 구조

분석 이것은 두 가지 언어 (영어 및 단순화 된 중국어 (Locale Directory)를 지원하는 기본 웹 응용 프로그램 구조입니다. 청구 및 회원의 두 가지 주요 구성 요소도 있습니다.
웹 사이트 개발에 조금 더 익숙하다면 정적 및 템플릿 폴더의 내용이 익숙해 보일 수 있습니다. 아마도 유일한 특이한 요소는 AWS (Amazon Web Services) 용 배포 파일을 저장하는 .elasticbeanstalk 일 수 있으며, 데이터베이스 자격 증명과 같은 프로젝트 온-프레미스
에 대한 설정 만 저장하는 .env. Readme 및 Todo와 같은 나머지는 논의했습니다.
도구 디렉토리는 흥미로운 디렉토리입니다. 예를 들어 스크립트를 저장하거나 데이터베이스를 다듬거나 결제 상태를 확인하거나 정적 파일을 캐시로 렌더링 할 수 있습니다. 기본적으로 응용 프로그램 자체가 아니라 작동하는 데 도움이됩니다.
이름 지정과 관련하여 이미지 디렉토리를 이미지/ 또는 IMG/로 지명하거나 스타일 디렉토리를 스타일/ 또는 CSS/ 또는 JavaScript/ 디렉토리의 이름으로 JS/로 지명하면 차이가 없습니다. 가장 중요한 것은 구조가 논리적이라는 것입니다. 우리는 항상 긴 설명 이름이든 짧은 컨벤션이든 항상 특정 협약을 따릅니다.
<code>├── .elasticbeanstalk ├── .env ├── billing ├── changelog.txt ├── locale │ ├── en │ └── zh_Hans ├── members ├── readme.txt ├── static │ ├── fonts │ ├── images │ ├── javascript │ └── styles ├── templates │ ├── admin │ └── frontend ├── todo.txt └── tools</code>
로그인 후 복사
케이스 2 : 데스크탑 응용 프로그램 이제 컴퓨터에서 다운로드하여 설치할 수있는 응용 프로그램을 고려해 봅시다. 또한 응용 프로그램에 CSV 파일과 같은 일부 입력이 필요하다고 가정하고 일련의 보고서를 렌더링합니다.
이 예에서는 소스 트리를 약간 더 크게 만듭니다.
파일 구조

분석 ui/폴더는 본질적으로 응용 프로그램의 핵심입니다. 하위 폴더의 이름은 거의 자명합니다 (또 다른 좋은 습관). 웹 애플리케이션 예제와 달리 여기에서 약어 이름 (예 : JavaScript 대신 JS)을 선택했습니다. 다시 말하지만, 실제로 중요한 것은 우리가 프로젝트에서 일관성이 있다는 것입니다.
이전에는 소스 트리에서 데이터 파일을 제외 할 것을 제안했지만 데이터/폴더가 있습니다. 어떻게 이런 일이 일어날 수 있습니까? 이 트리를 응용 프로그램을 올바르게 테스트하기 위해 데이터가 필요한 개발자 상자로 생각하십시오. 그러나 .gitignore 파일에 설정된 규칙에 따라 데이터는 여전히 저장소 동기화가 아닙니다. 레거시/ 폴더는 중단 될 애플리케이션의 일부에 사용되지만 새 시스템으로 완전히 리플렉스 될 때까지 유용 할 수있는 몇 가지 기능을 제공합니다. 따라서 이전 코드를 현재 코드와 분리하는 좋은 방법을 제공합니다.
여기에 새로 추가 된 것은 테스트/로, 단위 테스트를 사용하여 품질을 보장 할 수있는 장소와 소프트웨어가 요구하는 외부 라이브러리를 저장할 수있는 장소를 제공합니다.
는 Doc/
및 wiki/ 폴더가 있으며, 이는 복제본처럼 보일 수 있습니다. 그러나 최종 사용자를위한 문서 폴더와 개발 팀을위한 Wiki, 심지어 합리적인 문서 폴더가있을 수도 있습니다.

요약 반복 할 가치가있는 좋은 소식은 다음과 같습니다. 혼자 일하더라도 조직되어야합니다. 이 기사가 응용 프로그램의 파일 수가 증가함에 따라 혼란을 방지하기 위해 워크 플로에 즉시 적용 할 수있는 아이디어를 제공하기를 바랍니다. 앞에서 언급 한 바와 같이, 가이드 라인은 때때로 변경 될 수 있습니다. (거의) 거의 모든 프로젝트가 다르기 때문에 팀도 마찬가지입니다. 이상적으로, 귀하 또는 귀하의 팀은 프로젝트를 구축하는 방법을 결정할 것입니다.이 구조의 이유를 설명하기 위해 작은 문서를 추가 한 다음 지금부터 이러한 규칙을 고수하게됩니다. 여기에 많은 가이드 라인에 대해 파일을 이름으로 선택하거나 밑줄을 선택하더라도 중요하지 않다는 점을 기억하십시오 (많은 주제 중 하나를 선택하십시오). 핵심은 일관성입니다.

추가 읽기
"Python Getting Start Guide"의 프로젝트 구조.
UX Collective에서 프로젝트 폴더 구조를 관리하는 시스템 방법.
<:> 효과적인 프로젝트 관리 : 전통, 민첩한, 극단, 하이브리드
프로젝트 문서 구성 (FAQ) FAQ 구조화 된 방식으로 프로젝트 문서를 구성하면 어떤 이점이 있습니까?
프로젝트 문서를 구성된 방식으로 구성하면 많은 이점이 있습니다. 먼저 코드의 가독성과 유지 가능성을 향상시킵니다. 파일을 논리적으로 구성하면 개발자가 코드 기반을 이해하고 기존 기능을 위반하지 않고 변경하는 것이 더 쉽습니다. 둘째, 팀워크를 향상시킵니다. 여러 개발자가 동일한 프로젝트를 수행하면 잘 조직 된 파일 구조를 통해 모든 사람이 특정 스 니펫을 찾을 수있는 곳을 알고 있습니다. 마지막으로 개발 프로세스 속도를 높입니다. 개발자는 파일 검색에 시간이 줄어들고 코드를 작성하고 최적화하는 데 더 많은 시간을 소비합니다.
프로젝트 파일의 최적 구조를 결정하는 방법은 무엇입니까?
프로젝트 파일의 최적 구조는 프로젝트의 특성과 복잡성에 따라 다릅니다. 소규모 프로젝트의 경우 간단한 디렉토리 구조로 충분할 수 있습니다. 그러나 여러 구성 요소가있는 대규모 프로젝트의 경우보다 복잡한 구조가 필요할 수 있습니다. 사용중인 프로그래밍 언어, 사용중인 프레임 워크 또는 라이브러리 및 팀의 선호도와 같은 요소를 고려하십시오. 프로젝트가 성장함에 따라 구조가 개발 될 수 있도록 구조를 유연하게 만드는 것이 중요합니다.
코드 구성을위한 일반적인 전략은 무엇입니까?
코드를 구성하기위한 몇 가지 전략이 있습니다. 일반적인 방법은 기능별로 파일을 그룹화하는 것입니다. 이는 특정 기능과 관련된 모든 파일이 동일한 디렉토리에 저장됨을 의미합니다. 또 다른 방법은 CSS, JavaScript 및 HTML 파일 분할과 같은 유형별 파일을 다른 디렉토리로 그룹화하는 것입니다. 일부 개발자는 두 전략의 요소를 결합하여 하이브리드 접근법을 사용하는 것을 선호합니다. 핵심은 프로젝트와 팀에 맞는 전략을 선택하는 것입니다.
코드 기반이 성장함에 따라 조직을 유지하는 방법은 무엇입니까?
코드 기반이 커지면 파일 구조를 정기적으로 확인하고 리팩터링하는 것이 중요합니다. 여기에는 대형 파일을 더 작고 관리하기 쉬운 파일로 나누거나 디렉토리를 재구성하여 프로젝트의 현재 상태를 더 잘 반영하는 것이 포함될 수 있습니다. 자동화 도구는 서투르거나 유지하기 어려운 코드베이스의 영역을 식별하는 데 도움이 될 수 있습니다. 정기적 인 코드 검토는 또한 새로운 코드가 확립 된 파일 구조를 준수하도록하는 데 도움이 될 수 있습니다.
파일 조직에서 이름 지정 규칙은 어떤 역할을합니까?
명명 규칙은 문서 조직에서 중요한 역할을합니다. 일관되고 설명적인 파일 이름을 사용하면 각 파일이 한 눈에 포함 된 내용을 쉽게 이해할 수 있습니다. 이는 특히 대규모 프로젝트를 처리하거나 팀과 협력 할 때 개발 프로세스 속도를 크게 높일 수 있습니다. 이름 지정 규칙은 프로젝트의 시작 부분에서 합의해야하며 항상 일관성을 유지해야합니다.
모든 팀원이 내 파일 조직 전략을 따르도록하는 방법은 무엇입니까?
모든 팀원이 파일 조직 정책을 따르도록하려면 정책을 명확하게 문서화하고 문서에 액세스 할 수 있도록하는 것이 중요합니다. 정기적 인 코드 검토는 또한 정책을 시행하는 데 도움이 될 수 있습니다. 또한 문서 조직 규칙을 준수하는지 확인할 수있는 자동화 도구를 사용하는 것을 고려하십시오.
프로젝트 중간에 파일 조직 정책을 변경할 수 있습니까?
예, 프로젝트 중간에 파일 조직 정책을 변경할 수 있지만 워크 플로를 방해하지 않도록주의해서 수행해야합니다. 변경하기 전에 제안 된 새로운 전략을 팀과 논의하고 모든 사람이 변경의 이유와이를 구현하는 방법을 이해하도록하십시오. 새로운 정책을 반영하기 위해 관련 문서를 업데이트하는 것이 중요합니다.
프로젝트 파일을 구성 할 때 종속성을 처리하는 방법은 무엇입니까?
프로젝트 파일을 구성 할 때 의존성을 처리하는 것이 어려울 수 있습니다. 한 가지 방법은 모든 종속성을 별도의 디렉토리에 저장하는 것입니다. 이를 통해 쉽게 관리하고 업데이트 할 수 있습니다. 일부 프로그래밍 언어 및 패키지 관리자는 대부분의 프로세스를 자동화하는 종속성을 관리하는 도구를 제공합니다.
프로젝트 파일을 구성 할 때 어떤 일반적인 실수를 피해야합니까?
프로젝트 파일을 구성 할 때 피해야하는 일부 일반적인 실수에는 다음이 포함됩니다. 파일 구조를 미리 계획하지 않고 일관된 이름 지정 규칙을 따르지 않고 파일 조직 정책을 기록하지 않고 파일 구조의 불규칙한 점검 및 리팩토링. 이러한 오류를 피하면 코드 기반을 깔끔하고 정리하고 쉽게 탐색 할 수 있습니다.
문서 조직의 모범 사례에 대해 더 많이 배우는 방법은 무엇입니까?
문서 조직을위한 모범 사례를 배우는 데 사용할 수있는 많은 리소스가 있습니다. 온라인 자습서, 코딩 부트 캠프 및 개발자 포럼은 귀중한 통찰력을 제공 할 수 있습니다. 또한 오픈 소스 프로젝트의 폴더 구조를 연구하면 프로젝트 파일을 효과적으로 구성하는 방법에 대한 실제 예를 제공 할 수 있습니다.