위키가 소프트웨어 개발을위한 문서를 저장하는 데 정말로 적합합니까? [닫은]


18

잘 문서화 된 소프트웨어 개발은 ​​성공으로 이어진다는 것을 모두 알고 있습니다. 그러나 일반적으로 UML 다이어그램과 같이 일반 텍스트뿐만 아니라 이진 컨텐츠도 문서에 포함됩니다. 그리고 많은 사람들이 그렇게 말하는 것을 들었습니다. 버전 제어 시스템이 이진 파일에 적합한 장소가 아닙니다. 이 문제를 완전히 이해하고 동의합니다. 나는 여러 노련한 개발자들에게 문서를 저장하기에 가장 좋은 곳이 어디인지 물어 보았고 그 대답은 "wiki"였습니다. 위키는 좋지만 다른 잠재적 인 문제를 고려했습니다. 버전 관리 시스템에 저장된 소스 코드를 어떻게 위키에서 관련 문서에 연결할 수 있습니까? 누군가 git 또는 mercurial의 저장소를 복제한다고 가정 해 봅시다. 문서를 쉽게 찾을 수있는 방법은 무엇입니까? 아니면 방금 뭔가를 놓쳤습니까?

일부 위키 시스템에는 소스 제어 시스템과 통합 할 수있는 기능이 있습니다. 그러나 저의 관심사는 통합 능력에 관한 것이 아닙니다. git 저장소에서 소스 코드를 복제하고 잠시 후에 기차를 타고 기차에서 오프라인으로 계속 작업하려는 경우 (DVCS의 큰 기능). 그런 다음 기차에서 오프라인으로 작업하기 때문에 문서에 액세스 할 수 없다는 것을 갑자기 알게됩니다. 반면에 문서가 자식 저장소에 저장된 경우 저장소가 복제 된 문서에 액세스 할 수 있습니다.


3
참고 : 위키는 약어 가 아니며 , "빠른"을 의미하는 하와이 단어입니다.
Jörg W Mittag

문서에 바이너리가 포함되어 있다는 사실이 실제로 버전 관리 시스템에 문서를 저장하지 않는 좋은 이유는 아닙니다. VCS는 이진 파일을 쉽게 처리 할 수 ​​있습니다. 프로젝트의 VCS에 저장하면 프로젝트를 분기 할 때 문서를 분기 할 수 있다는 이점이 있습니다.
JW01

오프라인 작업과 관련하여 : 무차별 대입 솔루션은 일부 오프라인 리더기를 사용하여 원하는 페이지를 다운로드하는 것입니다. 더 우아한 방법은 실제 위키 전체를 복제하는 것입니다 (예 : 기본 데이터베이스를 복사하고 위키를 직접 설치). VCS 기반 위키는 훨씬 더 우아한 솔루션입니다. 나는 종종 오프라인에서 일하며 보통 정기적으로 필요한 페이지를 다운로드하는 것으로 충분합니다.
sleske

답변:


16

WIKI가 소프트웨어 개발 용 문서를 저장하는 데 실제로 적합합니까?

문서, PDF 및 기타 종류의 파일을 작성하는 대신 공동 작업 도구로서 WIKI의 잠재력을 최대한 활용하십시오. 거기에 문서를 작성하고 다이어그램을 첨부 할 수 있습니다. Fitnesse 를 사용하는 경우 위키 페이지가 실행 가능한 스펙이 될 수 있으므로 유용하고 실용적인 문서로 만들 수 있습니다.

잘 문서화 된 소프트웨어 개발은 ​​성공으로 이어진다는 것을 모두는 알고 있습니다

이것을 조심하십시오. 문서는 불량 코드를 좋은 것으로 만들지 않기 때문에 성공하지 못할 것입니다. 그러나 문서는 성공적인 소프트웨어로가는 길의 일부입니다. 그러나 일부는 좋은 관행과 좋은 사람들을 대체하지 않습니다.


8

여러 답변이 Trac을 제안으로 지적하기 때문에 비슷하지만 내 의견으로는 Redmine 을 제안하고 싶습니다 .

Redmine은 Wiki, Document Repository 및 버전 제어 통합을 포함한 프로젝트 관리 솔루션입니다. 또한 Ruby on Rails로 작성되었으며 경험상 Trac보다 쉽게 ​​확장하고 해킹 할 수 있습니다.

모든 것이 무엇보다 사용하기 쉽고 팀에서 쉽게 사용할 수 있습니다.

풍모:

  • 여러 프로젝트 지원
  • 유연한 역할 기반 액세스 제어
  • 유연한 문제 추적 시스템
  • 간트 차트 및 달력
  • 뉴스, 문서 및 파일 관리
  • 피드 및 이메일 알림
  • 프로젝트 별 위키
  • 프로젝트 별 포럼
  • 시간 추적
  • 이슈, 시간 입력, 프로젝트 및 사용자를위한 사용자 정의 필드
  • SCM 통합 (SVN, CVS, Git, Mercurial, Bazaar 및 Darcs)
  • 이메일을 통한 이슈 생성
  • 다중 LDAP 인증 지원
  • 사용자 자체 등록 지원
  • 다국어 지원
  • 여러 데이터베이스 지원

오프라인 요구 사항을 위해 디자인 문서를 사용하여 버전 제어를 어수선하게 만드는 것을 좋아하지 않습니다. 이 질문을해야 할 이유가 있다고 확신하지만 실제로 얼마나 자주 오프라인 상태이며 디자인 문서에 액세스해야합니까? 기회는 이것이 실제로 코너 사례입니다.


+1 직장에서 레드 마인을 사용하는데 정말 훌륭한 시스템입니다.
Luiz Damim

5

일부 위키 (예 : Ikiwiki )에는 언급 한대로 데이터를 Git에 저장할 수 있습니다. 이를 감안할 때 문서를 일반 소스 저장소에서 Git 서브 모듈 로 링크 할 수 있습니다 .

위의 설정에서 소스를 가져 와서 서브 모듈을 업데이트하면 최신 문서 사본을 가져옵니다. 오프라인에서는 마음대로 편집 할 수 있습니다. 네트워크로 돌아 오면 사용중인 공유 위치로 둘 다 되돌릴 수 있습니다.

이것의 어색한 부분은 문서가 업데이트 될 때마다 (Ikiwiki 웹 인터페이스를 통해조차도) Git 소스 저장소에서 해당 하위 모듈도 업데이트해야한다는 것입니다. 그러나 이것은 쉽게 자동화 될 수 있습니다.


흥미 롭군 git 저장소에 문서를 저장하고 ikiwiki를 통해 문서를 저장하는 것에는 차이가 있습니까?
Edison Chuang

1
@Edison Chuang : 아니요. 없습니다. 실제로, ikiwiki 저장소의 복제본이 주어지면, 원하는 텍스트 편집기를 사용하여 페이지를 편집 할 수 있습니다 (크 래피 브라우저 기반 텍스트 입력 상자를 사용할 필요는 없습니다). 오래된 문서 나 다른 것의 스냅 샷을 유지하기 위해 위키의 다른 브랜치를 가질 수도 있습니다.
Greg Hewgill

이진 파일을 사용하더라도 문서를 문제없이 버전 제어 시스템에 저장할 수있는 것 같습니다. 개발자는 필요에 따라 ikiwiki와 같은 도구를 사용하여 위키 페이지를 HTML 페이지로 변환 할 수 있습니다.
Edison Chuang 1

Ikiwiki 위키 엔진의 경우 +1; 하타 위키 엔진은 의욕 저장소에 대한 비슷한 생각이다.
David Cary

또한 ISTR Fitnesse는 위키 페이지를 텍스트 파일로 저장하므로 원하는 경우 버전 관리 시스템에 보관할 수도 있습니다. 주요 목적은 테스트이지만, 문서를위한 범용 위키 시스템으로 사용하지 않는 이유는 없습니다.
Jules


2

Trac은 통합 Wiki 및 편리한보고 기능인 Subversion에 대한 인터페이스를 제공합니다. http://trac.edgewall.org/
그러나 설치된 스택에 대해서는 모르겠습니다.


그리고 Mercurial에 대한 훌륭한 인터페이스입니다. 그리고 그것은 분명히 해킹 가능합니다.
Frank Shearar

0

오프라인 작업을 따르려고하지 않습니다. 모든 사람이 가장 쉽게 작업 할 수있는 리소스를 사용합니다. 예를 들어, PHP 코드를 작성하는 경우 PHPDocumentor에서 생성 할 수있는 인라인 문서를 사용하는 것이 좋습니다 . 어디서나 생성 할 수 있으며 Trac 용 플러그인이 있습니다. 그런 다음 온라인 또는 오프라인으로 문서에 빠르게 액세스 할 수 있습니다.

열쇠는 유용성에 관한 것입니다. 유지하기 어려운 경우 어려움을 겪기 시작합니다. 문제가 발생하면 문서 품질이 저하됩니다. 그렇게되면 사람들이 불평하기 시작하고 모든 것이 내리막으로 진행됩니다.


-1

위키를 사용하여 문서를 저장하면 나에게 많은 의미가 있습니다.

Veracity 는 위키 컨텐츠와 소스 코드를보다 강력하게 통합 할 수있는 DVCS의 예입니다.

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