ペアプログラミングでは、チームの各メンバーの経験を新しいメンバーに広めることができます。ペアの「上級者」はコードがどのように機能し、設計が何であるかを知っているため、この経験は常にコードと同期しています。
では、この場合の設計文書の有用性は何でしょうか?
アップデート
私は設計がないことを暗示しているのではなく、ドキュメントがないことを暗示しています。ペアプログラミングを実践するチームでは、誰もがコードを知っているので、誰もが使い捨てだと思います。上級開発者が去った場合、コードを知っている人が少なくとも 1 人は必ずいると思います。経験は以前に共有されていたからです。
チームが 2 人を超える場合はどうなりますか?
2 人がシステムの一部を知っているからといって、それを文書化してはならないということにはなりません。
また、システムが頭の中にしか保存されていないという理由だけで、システムの細部をすべて覚える必要がないことを知ってうれしいです。
小規模なシステムではこれでうまくいくかもしれませんが、システムが大きくなるにつれて、自分自身と同僚を制限することになります。古いシステムのすべてを記憶するよりも、メモリ容量を新しいシステムに使用したい.
成果物のセットは、ペアプログラミングを使用するかどうかに関係なく決定する必要があります。
6 か月後または 2 年後には、関係者全員が別のプロジェクト (または別の会社) に所属している可能性があります。戻って設計ドキュメントを使用できるようにしたいですか? それから、それを生成します。戻ってきたくない場合、または明示的な設計ドキュメントの助けを借りなくても仕様とコードを理解できるほど設計が単純である場合は、スキップできます。
しかし、2 人が 1 年後にデザインを説明してくれることに頼らないでください。
「電話」をしたことはありますか？コードベースでプレイするべきではないと思います。
上級プログラマーが会社/プロジェクトを辞めたらどうなりますか?
メンテナンス。新しいメンバーがいなかったり、古いメンバーがいなくなったりすることがないため、チームが静的なままであるとは期待できません。設計文書は、プロジェクトに不慣れで何年も維持しなければならない人々が、下された決定、アプローチが選択された理由、およびそれがどのように実装されたかについての情報を確実に持っていることを保証します。プロジェクトが長期的に成功するためには、このドキュメントを用意することが非常に重要です。このドキュメントは、従来のドキュメント、ソース コメント、単体テスト、およびその他のさまざまな方法を組み合わせて提供できます。
ペア プログラミングによって設計ドキュメントが時代遅れになるとは思いません。私はすぐにトラックの要因について考えなければなりません。確かに、先輩はどんなデザインかわかるかもしれません。しかし、彼が病気のときはどうなりますか？彼がトラックに轢かれたらどうなりますか？彼が解雇されたらどうしますか？
ペア プログラミングは知識を広めますが、その知識を文書化することは決して悪いことではありません。
「設計ドキュメント」の意味によって異なります。
機能テスト、特にビヘイビア駆動開発（BDD）テスト、FitnessまたはFITテストがある場合、それらは確かに「アクティブなドキュメント」の形式です...そしてそれらは確かに価値があり、回帰テストでもあります。
ユーザーストーリーを書き、それらをタスクに分解し、それらのタスクをペアで行うためにカードに書く場合、あなたはある種のドキュメントを作成しています...
これらは、すべての製品コードでペアになるXPチームで使用した2つの主要なドキュメント形式です。
私が非常に便利だと思う他の唯一のドキュメントは、開発マシンのビルド環境をセットアップする方法を人々に示す半ページ程度の箇条書きのセットです。リストを使用しながら、リストを維持することになっています。
最初に書かれたコードについて誰が知っていますか? 答えは書かれていないので誰にもわかりません。それが書かれていない理由は、誰も何をすべきかわからないためです。したがって、設計文書が必要です。
おっしゃる通り、人の体験がコードとシンクロしているのかもしれません。しかし、設計上の決定事項のすべてがコードに取り込まれるわけではなく、行われた選択のみがコードに含まれます。
私の経験では、コードがこのように設計されている理由を本当に理解するには、選択されなかった設計上の選択肢、試みて失敗したアプローチなどについて知る必要があります。メモリを更新したりエラーを修正したりするためのコードにこれの記録がないことを考えると、正しく...
... または、設計とそれがどのように到達したかについてのドキュメントを作成することもできます。そうすれば、将来、メンテナンス プログラマーによって暗い路地に追いやられるのを避けることができます。
ペアプログラミングは、コーディングと論理的な側面のみを可能にします。
しかし、ドキュメンテーションは良い習慣です。いつもドキュメンテーション...
ワード プロセッサの代わりにスプレッドシート プログラムが必要な場合は、設計ドキュメントを使用すると便利です :-)
XP、ペア プログラミング、アジャイルなどは、計画がないという意味ではありません。それは、何が起こっているかについて (ミクロ レベルで) はるかに詳細でない計画にすぎません。ユーザーが選択するユースケースは、より設計的なものであり、他のスタイルの設計/プログラミングよりも生きたドキュメントです。
何か「クール」なことをしているからといって、もはや優れたプラクティスは必要ないという罠にはまらないでください。実際、このスタイルのプログラミングでは、成功するためには、より多くの規律が必要です。
いいえまた、ペア プログラミングがないからといって、ドキュメントが必要になるわけでもありません。書類が必要です！それがどのように見えるかは、あなたを驚かせるかもしれません!
アジャイル チームは、いつ、どのドキュメントが必要かを決定します。経験則として、誰も読まない場合は書かないでください。プロジェクトマネージャーがそう言っているので、アーティファクトを提供することでウォーターフォールアーティファクトの考え方にとらわれないでください。
ほとんどの人は、ドキュメントを Word で行うものと考えています。アジャイル チームが適切に機能している場合、コード自体は、TDD (テスト駆動開発) を使用して、要件を文書化して適用する一連の自動テストを持ちます。画像、コードと同期しているドキュメント...そしてそれはそのままです。
そうは言っても、ペアリングは、ドメイン、アプリケーション、プラクティス、およびスキルの知識がチーム全体に非常に迅速に伝播するのに役立ちます. ペアリングは、チームが TDD やその他の自動テストを含むエンジニアリング プラクティスに従うことを保証するのにも役立ちます。その結果、アプリケーションは健全な状態を維持し、将来の変更を容易に実現できます。
つまり、結論として、ペア プログラミングはより優れたドキュメントを作成します。ドキュメントがなくなるわけではありません (ただし、Word ドキュメントは見つからない可能性があります)。
私は支持者であり、ドキュメンテーションのファンです。ペアプログラミングは「上級開発者1人」を必要としません。ペア プログラミングに関する私の経験では、迅速な開発を目的として、あらゆるレベルの開発者がペアになります。後輩の開発者と一緒に仕事をしたことが何度もあり、キーボードで妥協しました。シニア アーキテクトと一緒に仕事をしたことが何度もあり、キーボードをトレードオフしていました。特にコア コンポーネントとデータベースに関しては、ドキュメントが依然として必要です。
コード ベースが非常に大きく、実装しようとしていた内容のすべての詳細を人間が思い出すことができない場合があります。この場合、参照が役立ちます。
また、他のコンポーネントなどとやり取りする場合はデザインが必要です。