파일 시스템 구조를 문서화하는 표준화 된 방법


11

직장에서는 표준 파일 시스템에서 다양한 데이터를 관리하는 일을 담당하고 있습니다. 이것의 일부는 현명한 분류 (유사성, 필요, 읽기 / 쓰기 액세스 등)로 이루어 지지만 더 큰 부분은 실제로이를 문서화하고 있습니다. "약간 다른 점은 ../../other-dir"등을 참조하십시오.

현재 문서화 readme하려는 모든 디렉토리에 일반 텍스트 파일 을 사용하여 문서화했습니다. 어떤 디렉토리에 어떤 의미가 있는지 잘 모르는 경우 해당 파일을 읽습니다.

이것은 잘 작동하지만 사소한 디렉토리 구조의 모든 관리자가 경험 해야하는 문제에 대한이 기본 사용자 정의 솔루션을 가지고있는 것이 이상합니다. 예를 들어 내가 아는 모든 회사에는 분류에 대한 동의 된 용어가 중요한 일종의 공유 파일 시스템이 있습니다. 내 경험상 사람들은 시행 착오와 실험을 통해 무엇을 배우기 만하면됩니다.

더 나은 솔루션을 제안하고 솔루션이 존재하는지 알려주세요. 모든 파일 시스템의 모든 디렉토리는라는 숨겨진 일반 텍스트 파일을 가질 수 있습니다 .readme. 그 내용은 설명적인 인간 언어입니다. 다른 디렉토리에 굵게, 기울임 꼴 및 (상대) 하이퍼 링크가 거의없는 Markdown과 같은 일부 마크 업을 사용합니다. 이제 적절하게 활성화 된 파일 브라우저는 .readme디렉토리를 표시 할 때마다 이름이 지정된 파일을 확인합니다 . 존재하는 경우, 내용이 구문 분석되어 디렉토리 경로 위젯 근처의 눈에 띄지 않는 창에 표시됩니다. 그 안의 모든 링크를 클릭하면 해당 링크의 대상 디렉토리로 이동합니다.

그러한 표준을 구현하려는 노력은 유용성 이익을 여러 번 상환한다고 생각합니다. 예를 들어, 노틸러스, Konqueror 등을위한 플러그인이있을 것입니다. 웹 서버가 제공하는 표준 파일 목록에 디렉토리 정보를 표시하는 데 사용될 수 있습니다. 등등.

그래서 질문 : 그런 것이 존재합니까? 그렇지 않다면 왜 안됩니까? 사람들은 그것이 가치있는 생각이라고 생각합니까?


파일 시스템 (또는 특정 파일 시스템의 파일 브라우저), 특히 소스 코드에 대한 개선 사항을 언급 했으므로 파일 순서 지정에 필요한 기능을 언급 할 가치가 있습니다. 대부분의 파일 시스템에는 알파벳순과 정렬되지 않은 두 가지 순서가 있습니다. 그러나 사용자 지정 주문은 어떻습니까? 예를 들어 소스 코드의 경우 폴더 (모듈, 패키지, 상위 구성 요소)에 7 개의 파일 (클래스, 모듈, 구성 요소)이있는 경우 "논리적"순서는 알파벳 순서와 동일하지 않습니다. 그러나 오히려 "의존성 트리"의 순서입니다.
Sorin Postelnicu

따라서 최신 파일 시스템에 표준으로 추가되는이 세 가지 기능은 기본적으로 1) 파일 설명, 2) 폴더 내 사용자 지정 파일 순서 지정 및 3) 파일 태그 지정 / 레이블링입니다. 이 3 가지 "기본"기능을 활용하기 위해 CMS를 사용할 필요는 없습니다.
Sorin Postelnicu

답변:


5

내가 아는 한 표준은 없습니다. 내 경험에 대한 몇 가지 아이디어가 있습니다.

설정, 절대 변경하지 마십시오

이것은 대부분의 회사가 실패한 것입니다. 끊임없이 변화하는 파일 시스템 구조보다 더 나쁜 것은 없습니다. 그것을 일정하게 유지할 수 없다면 순수한 파일 시스템은 정보를 구성하는 잘못된 컨테이너 일뿐입니다. 데이터베이스 또는 컨텐츠 관리 시스템을 사용하십시오.

설명적이고 일관된 디렉토리 이름 사용

아무도 .filing파일이나 다른 것을 읽을 시간이 없습니다. 디렉토리 이름이 자체 설명이 아닌 경우 어쨌든 손실 될 수 있습니다.

디렉토리 구조에 대한 문서 작성

모든 디렉토리의 역할을 설명하는 문서를 작성하십시오. 많은 예를 제시하십시오. 구조를 다루어야하는 사람이라면 누구나 사용할 수 있지만 아무도 읽지 않을 것이라고 생각하십시오. 그것은 당신 에게 성경 과 같아야 합니다. 회사가 문서를 공개하지 않기 때문에 그러한 문서에 대한 예제를 찾는 것은 쉽지 않습니다. 오픈 소스 소프트웨어의 예는 Filesystem Hierarchy Standard 입니다.


이것이 조금 부정적으로 들리면, 그렇지 않습니다. 필자는 실제로 5 명 이상의 사용자가 실제로 파일 시스템을 기반으로하는 사소한 저장소를 본 적이 없습니다. 문제는 어떤 카테고리를 설정하든 사람들이 완전히 다른 아이디어를 갖게된다는 것입니다. 마지막으로 귀하의 질문에 대답하십시오 :

그런 것이 있습니까?

아니요, 그렇게 생각하지 않습니다.

그렇지 않다면 왜 안됩니까?

내 의견으로는 : 소수의 사용자가있는 작은 정적 계층의 경우 과잉입니다. 사용자 수가 많은 대규모 변경 계층 구조의 경우 범주 (= 디렉토리, 폴더) 아이디어가 확장되지 않기 때문에 작동하지 않습니다.

사람들은 그것이 가치있는 생각이라고 생각합니까?

흠, 그것은 흥미로운 아이디어입니다. 사람들이 그것을 사용할지 확인하려면 누군가 그것을 사용해야합니다. .filing파일 대신 해당 정보를 대체 데이터 스트림에 저장할 수 있습니다 (예, 폴더에도 ADS가있을 수 있음). Linux 및 OSX에서 확장 된 속성을 사용할 수 있습니다. 가장 큰 문제는 아마도 파일 브라우저를 패치하는 것입니다.


1
"더 이상 변화가없는 파일 시스템 구조보다 더 나쁜 것은 없습니다."구조가 더 이상 의미가 없어도 단호하게 변경을 거부하는 구조는 예외입니다.
jameshfisher

1
"설명적이고 일관된 디렉토리 이름 사용"-반드시 필요합니다. 예. 불행히도 서술 성과 간결함이 충돌합니다. 아무도 / srv / all-hierarchical-data / accessible-only-by-office-and-admin / letters-but-not-public에 파일 경로를 입력하고 싶지 않습니다. -공지 사항 / 학년 -2009 / ... 등.
jameshfisher

"디렉토리 구조에 대한 문서를 작성하십시오"– 또한 좋은 생각입니다. 그것은 본질적으로 내가 제안하는 것입니다. 단지 문서가 모 놀리식이 아니라 배포 될 것입니다.
jameshfisher

"카테고리 (= 디렉토리, 폴더)에 대한 아이디어는 확장되지 않습니다."-때로는 필요로하는 경우를 제외하고는 참으로 그렇습니다. 큰 소프트웨어 소스 트리 ( git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree )를 가정 해보십시오 .
jameshfisher 12

" .filing파일 대신 해당 정보를 대체 데이터 스트림에 저장할 수 있습니다 (예, 폴더에도 ADS가있을 수 있습니다). Linux 및 OSX에서 확장 된 속성을 사용할 수 있습니다." 가능하다고 생각하지만 이식성과 투명성을 떨어 뜨려서 그렇게 중요하다고 생각합니다. git repo에 모든 것을 배치하려면 어떻게해야합니까? 일반 텍스트 파일은 디렉토리 별 구성에 사용됩니다 (예 : htaccess).
jameshfisher

2

와사비 는 한 번의 가치가 있습니다. 프로젝트 루트에서 일반 텍스트 소스 는 견고한 프로젝트 개요로 사용되며 브라우저에서 동일한 문서를 던져보다 멋진 결과를 얻을 수 있습니다.

물론 파일 시스템 기반 솔루션은 아니지만 모든 파일 시스템이 공통적 인 것을 지원할 때까지 와사비 (또는 자체 구현)가 최선의 선택이 될 수 있습니다.


1

귀하의 아이디어에는 장점이 있지만, 이와 같은 것이 필요할 때 더 구조화 된 것이 필요하다는 것을 두려워합니다. 즉 CMS는 가벼운 것일 수도 있지만 텍스트 파일 이상의 것이 아닙니다.

특히 특정 문서 (및 그에 포함 된 폴더 포함)의 쓰기 (또는 액세스)를 일부 사용자 기반으로 제한하려는 경우.

OS를 지정하지 않았지만 현재 설정보다 더 나은 서비스를 제공 할 수있는 alfresco 와 같은 우수한 (무료) 제품 이 있습니다.


다양한 CMS를 다루었지만 이식성, 단순성 및 투명성이 가장 뛰어난 CMS 인 디렉토리 트리와 비교할 때 지불하는 데 큰 비용이 든다는 것을 알았습니다. 관리해야하는 대부분의 데이터는 계층 구조에 맞을 수 있습니다. 최후의 수단으로 심볼릭 링크가 있습니다. 디렉토리 구조는 때때로 유일한 솔루션입니다. 예를 들어 소프트웨어 개발에서 소스 코드는 기본적으로 디렉토리 트리입니다. (그러한 디렉토리를 문서화한다는 것은 일반적으로 단단하고 암호화 된 스키마를 고수한다는 의미입니다. 결국 고장납니다. 제 솔루션도 여기에서 도움이 될 것 같습니다.)
jameshfisher

내가 말했듯이, 당신의 아이디어는 장점이 있지만 다른 포스터의 저자와 마찬가지로 이것이 주어진 수준 이상으로 확장 될 수 없다고 생각합니다. 소스 코드를 언급했지만 매우 특수한 경우입니다. 코드를 추가 할 때 기존 디렉토리를 조사하여 "적합한"위치를 찾지 않습니다. CMS는 일반적으로 항목에 태그를 지정할 수있는 기능을 제공하므로 솔루션과 같은 "디렉토리"(폴더, 공백, 페이지)와 "올바른"디렉토리를 찾을 필요없이 항목을 찾을 수있는 태그 시스템을 제공합니다. 이것은 심볼릭 링크보다 유연하고 오류가 적습니다 (IMHO).
p.marino

1

여기 아이디어가 있습니다. 사용자에게 파일에 대한 다양한 질문을하고 /하거나 파일 내용 자체에서 일부 일치를 수행 한 다음 파일을 넣거나 파일을 넣을 위치를 권장하는 스크립트를 작성하십시오. 스크립트는 원하는만큼 간단하거나 복잡 할 수 있습니다.

이 스크립트는 파일 관리 시스템, 의사 결정 지원 시스템 및 파일 시스템 계층의 실제 문서 역할을합니다. Linux 파일 시스템 계층 표준은 생각할 때 약간의 신화입니다. 왜냐하면 배포판간에 매우 큰 차이가 있기 때문입니다. 그러나 대부분의 Linux / Unix 사용자는 시스템에 설치된 다양한 소프트웨어가 존재하므로 표준 방식 (패키지 관리자, 구성 도구 등)으로 계층을 관리하기 때문에 파일 시스템 계층 자체에 대해 실제로 배울 필요가 없습니다. 다양한 애플리케이션 프레임 워크는 디렉토리를 관리하기위한 스크립트를 생성합니다. 예를 들어 django는 새로운 프로젝트, 새로운 앱 모듈 또는 스쿼시 마이그레이션 파일 등을 생성하는 관리 명령을 가지고 있습니다.

파일 작성자 나 작성 날짜 또는 비즈니스 규칙에 기반한 색인과 같이 여러 가지 방법으로 파일을 검색해야하는 경우 스크립트가 다양한 심볼릭 링크를 작성할 수 있다는 추가 이점이 있습니다. 심볼릭 링크를 사용하여 태깅을 시뮬레이션 할 수 있습니다. 태그는 tags디렉토리의 단순한 심볼릭 링크 이므로에 tags/mytag/myfile대한 심볼릭 링크 일 수 있습니다 actual/myfile.

또한 사용자 인터페이스를 변경하지 않고 파일 시스템 계층 구조를 변경할 수도 있습니다.

파일 시스템은 데이터베이스입니다. 관계형 데이터베이스는 아니지만 계층 적 데이터베이스입니다. 데이터베이스 관리와 같은 것을 생각하십시오. 사람들이 관계형 구조를 배우도록 요구하지 않고 응용 프로그램이 사용자가 수행해야하는 다양한 작업으로 사용자에게 제시하기를 원합니다 (예 : 월간 작업을하고 있습니까) XYZ 보고서를 입력 한 다음이 폴더에 넣고이 심볼릭 링크를 만든 다음이 달에 대한 보고서를 수행했음을 기록하도록 다른 파일을 수정해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.