Wikiは、ソフトウェア開発用のドキュメントの保存に本当に適していますか？[閉まっている]

よく文書化されたソフトウェア開発が成功につながることは誰もが知っています。ただし、通常は、プレーンテキストだけでなくバイナリコンテンツもUML図などのドキュメントに含まれることを意味します。そして、私は多くの人がそれを言うのを聞いたことがあります。バージョン管理システムは、バイナリファイルの適切な場所ではありません。私はこの問題を完全に理解し、同意します。文書を保管するのに最適な場所はどこにあるべきか、何人かのベテランの開発者に尋ねました。Wikiは良いですが、別の潜在的な問題を検討しました。バージョン管理システムに保存されているソースコードは、Wikiの関連ドキュメントにどのように接続できますか？誰かがgitまたはmercurialのリポジトリを複製したとしましょう。彼/彼女はどのようにしてドキュメントを簡単に見つけることができますか？または、私は何かを見逃しましたか？

一部のウィキシステムには、ソース管理システムと統合する機能があることを知っています。しかし、私の懸念は統合の能力に関するものではありません。gitリポジトリからソースコードのクローンを作成し、しばらくしてから電車に乗って、電車でオフラインで仕事を続けたい場合（これはDVCSの大きな機能です）。次に、電車でオフラインで作業しているため、ドキュメントにアクセスできないことに突然気付きます。一方、ドキュメントがgitリポジトリに保存されている場合、リポジトリが複製されたドキュメントにアクセスできます。

WIKIはソフトウェア開発用のドキュメントを保存するのに本当に適していますか？

ドキュメント、pdf、その他の種類のファイルを作成する代わりに、WIKIのコラボレーションツールとしての可能性を最大限に引き出してみませんか？そこにドキュメントを書いて、図を添付することができます。Fitnessを使用すると、Wikiページを実行可能な仕様にできるため、本当に便利で生き生きとしたドキュメントに変えることができます。

よく文書化されたソフトウェア開発が成功につながることは誰もが知っています

これに注意してください。文書は、がらくたコードを良いものに変えないので、成功することはありません。しかし、ドキュメントは成功するソフトウェアへの道の一部です。しかし、ほんの一部であり、彼らは良い習慣と良い人々を置き換えることはありません。

複数の回答がTracを提案として示しているので、同様の、しかし私の意見ではより良い代替案：Redmineを提案したいと思います。

Redmineは、Wiki、ドキュメントリポジトリ、バージョン管理の統合を含むプロジェクト管理ソリューションです。また、私の経験では、Ruby on Railsで書かれており、Tracより簡単に拡張およびハッキングできます。

何よりも、それは本当に使いやすく、チームがそれを使用するのは簡単です。

特徴：

• 複数プロジェクトのサポート
• 柔軟な役割ベースのアクセス制御
• 柔軟な問題追跡システム
• ガントチャートとカレンダー
• ニュース、ドキュメント、ファイル管理
• フィードとメール通知
• プロジェクトごとのwiki
• プロジェクトごとのフォーラム
• 時間追跡
• 課題、時間入力、プロジェクト、ユーザーのカスタムフィールド
• SCM統合（SVN、CVS、Git、Mercurial、Bazaar、およびDarcs）
• 電子メールによる問題の作成
• 複数のLDAP認証のサポート
• ユーザーの自己登録サポート
• 多言語サポート
• 複数のデータベースのサポート

オフラインでのニーズのために、デザインドキュメントでバージョン管理を乱雑にするという考えは好きではありません。質問する理由はあると思いますが、実際にはどれくらいの頻度でオフラインになっていて、デザインドキュメントにアクセスする必要がありますか？チャンスは本当にこれが角の場合です。

いくつかのウィキ（例えばIkiwiki）には、あなたが言ったように、Gitにデータを保存する機能があります。その場合、ドキュメントを通常のソースリポジトリの下のGitサブモジュールとしてリンクできます。

上記のセットアップでは、ソースを取得してサブモジュールを更新すると、ドキュメントの最新のコピーが取得されます。オフラインでは、それぞれを自由に編集できます。ネットワークに戻ると、使用している共有場所に両方をプッシュバックできます。

これの厄介な部分は、ドキュメントが更新されるたびに（Ikiwiki Webインターフェースを介しても）、Gitソースリポジトリの対応するサブモジュールも更新する必要があることです。ただし、これは簡単に自動化できます。

ドキュメントをソースコードと同じリポジトリに保存することは理にかなっています。スフィンクスは私にとって良い選択肢のようです。

• それはとりreStructuredTextのの編集、差分が容易で入力、としてファイルを
• ハイパーリンク出力（HTML、PDFなど）を生成します
• ソースコード（Python、C、C ++、JavaScript）を参照できます。

Tracは、統合されたWikiおよび便利なレポート機能であるSubversionへのインターフェースを提供します。 http://trac.edgewall.org/
しかし、インストールされたスタックについては知りません。

オフライン作業に準拠しようとはしません。誰にとっても使いやすいリソースを使用します。たとえば、PHPコードを記述している場合、PHPDocumentorで生成できるインラインドキュメントを使用することをお勧めします。どこでも生成でき、Trac用のプラグインがあります。その後、オンラインでもオフラインでも、ドキュメントにかなりすばやくアクセスできます。

重要なのは使いやすさです。維持するのが難しい場合、それは苦しみ始めます。ドキュメントの品質が低下すると、ドキュメントの品質が低下します。それが起こると、人々は不平を言い始め、それからすべてが下り坂になります。

Wikiを使用してドキュメントを保存することは、私にとって非常に理にかなっています。

正確性は、Wikiコンテンツとソースコードのより緊密な統合を可能にするDVCSの例です。