私のチームには偉大なソース管理システムがあり、優れた仕様があります。私が解決したい問題は、コードを最新の状態に保つことです。時間が経つにつれてスペックは年齢になる傾向があり、日付コードと仕様を同期させるには？ - 良いツールはありますか
の外になるスペックを作る人々は、ソースコントロールを嫌う傾向にあるとプログラマーは、SharePointを嫌う傾向にあります。
私は他のソリューションの使い方を知りたいですか？どこかで幸せな中間があるのですか？
私は非Sharepointのwikiがドキュメントを最新の状態に保つのに良いと思います。ほとんどの非技術者はwikiの使い方を理解することができ、ほとんどのプログラマは良いwikiを使うことに満足しています。私の意見では、Sharepointのwikiとドキュメンテーションコントロールシステムは使いこなすのが難しいです。
Mediawikiです。
私は本当にウィキが好きです。なぜなら、彼らが採用し、追いつくのに一番低い痛みであるからです。彼らはあなたに自動バージョン管理を提供し、通常は皆が使いやすいように非常に直感的です。多くの企業では、Word、Excelなどの種類のドキュメントを使用したいと考えていますが、すべてをオンラインにして共通のインターフェイスからアクセスできることが重要です。
私はあなたが何を記述しているかに関して特に良い解決策は何も知らない。一般的に、この種のものを同期させて見た唯一の解決策は、ソースコード（doxygen、Javadoc）からドキュメントを生成するツールです。コードと同期してドキュメントを維持するために使用
一つの技術はliterate programmingです。これにより、コードとドキュメントは同じファイルに保持され、プリプロセッサを使用してドキュメントからコンパイル可能なコードが生成されます。私が知っている限り、これは技術の1つですDonald Knuth - 彼は彼のコードでバグを見つけるとpay peopleお金に満足しています。
これは本当に確かな仕様テクニックではありません。常に一致するコードとドキュメントを作成するのに最適です。誰かがプログラムを書くのに役立つ仕様を作るのはあまり良くありません。 –
私はこれが別のものだからオプションとして与えています。しかし、私は、文章題のプログラムは、コードの仕様からの情報を埋め込むのが良いと思う。 [tangle] [1]のコードを見ると、非常にスペックのようなセクションがあります。文字の表現方法に関する議論には、設計上の決定の理由が含まれています。しかし、違いは実際に強調の1つであり、優れた文章のプログラミングツールの欠如はインラインコメントをはるかに便利にすると思います。 [1]：http://tug.org/texlive/devsrc/Build/source/texk/web2c/tangle.web – garethm
いいえ。幸せな中間はありません。彼らは異なる観客と異なる目的を持っています。
私が建築家とスペックライターとして学んだことは次のとおりです。仕様には長期的な価値はほとんどありません。それを乗り越える。
仕様は、素敵なプログラミングを始めるためにいる間、あなたが何で時間をかけてその価値を失うことはありません。仕様の読者は、多くの洞察力を持たないプログラマです。これらのプログラマーは、もはやスペックを必要としない深く知識のあるプログラマーに変身します。
仕様の一部（特に概要）には、長期的な価値があるかもしれません。
仕様の残りの部分に価値があった場合、プログラマは最新の状態に保ちます。
よく機能するのは、コードに埋め込まれたコメントとそのコメントを抽出し、現在のライブドキュメントを作成するツールを使用することです。 Javaはjavadocでこれを行います。 PythonはepydocまたはSphinxでこれを行います。 C（およびC++）はDoxygenを使用します。多くの選択肢があります：http://en.wikipedia.org/wiki/Comparison_of_documentation_generators
概観は、元の仕様から取り出してコードに配置する必要があります。
最終的な文書を抽出する必要があります。この文書では、仕様の概要とコードの詳細を使用して仕様を置き換えることができます。
大きなオーバーホールが必要な場合は、新しい仕様があります。既存の仕様を改訂する必要があるかもしれません。ジャンプオフポイントは、自動生成された仕様書です。仕様。作者はそれらのものから始めて、心のコンテンツに追加/変更/削除することができます。
私は、仕様には長期的な歴史的価値があることをお勧めします。デザインの選択肢が最初に作られた理由を理解することは、プロジェクトの後のポイントで非常に役立つことがあります。しかし私はあなたに非常に同意します。 –
デザインの決定が重要です。それらは、詳細なプログラミング仕様ではなく、概要（特にアーキテクチャの概要）に属します。 –
可能な限り、スペックはrspec、doctest、および類似のフレームワークを介して実行可能でなければなりません。コードの仕様は、単体テストと、よく名付けられたメソッドと変数を持つコードで文書化する必要があります。
スペックのドキュメント（ウィキであることが望ましい）は、物事の上位レベルの概要を提供する必要があります。それは、あまり変化しないか、速やかに同期が外れることになります。
このような方法では、仕様とコードを同期させておくことができ、同期が外れるとテストが失敗します。
これは、多くのプロジェクトで、上記はパイのようなものだと言われています。その場合、S.Lottはそうです、それを乗り越えてください。彼らは同期していない。スペックを開発者が与えたロードマップとして見てください。彼らが行ったことの文書ではありません。
現在の仕様を持つことが非常に重要な場合は、コードの後に仕様を書き込む（または書き換える）ために割り当てられたプロジェクトに特定の時間が必要です。そうすれば、（コードが変更されるまで）正確になります。
これに代わる方法として、仕様とコードをソース管理下に置き、チェックインをレビューして仕様がコードと共に変更されていることを確認することができます。それは開発プロセスを遅くしますが、それが本当に重要なのであれば...
ええ。仕様のスペック！ – Sake
これは大きな問題です。ここで問題を提起してくれてありがとう、クリス。 – DOK
私は2番目のDOKに加えて、SharePointも嫌いです。 +1 –