Conwayの「Game of Life」がコードリトリートに使用されるのはなぜですか？

Code Retreatは、ソフトウェア開発の基礎に焦点を当てた終日トレーニングイベントです。「グローバルな」コードリトリート日が近づいています。私はそれを楽しみにしています。とは言うものの、私は以前に1つに行ったことがあり、膨大な量の混乱があったと言わざるを得ません...それは問題ありません。

私がまだ理解していないことの1つは、「ゲームオブライフ」がTDDにとって良い問題である理由と、TDDの良い点と悪い点がどのように感じられるかということです。

これはかなり開かれた質問であることに気づきますので、気軽にコメントしてください。

もともと、2009年1月の最初のcoderetreatで作業するJavaアプレットが手元にあったため、ConwayのGame of Lifeが選ばれました。 GoLアプレットがありました。

しかし、その後、アクティブなファシリテーター（特に2009年の旅人ツアーでの私とブカレストのAlex Bolboaca）がGoLの学習ツールとしての使用を調査しました。同時に、私たちはcoderetreat形式を現在の形式に進化させていました。2009年、Alexは少なくとも1つの他の問題（ポーカーハンドスコアリング）を試みましたが、GoLほど有用ではありませんでした。あなたはhttp://coderetreat.org/historyで歴史の詳細を見つけることができます

Coderetreatは、シンプルなデザイン（特にシンプルなデザインの4つのルール）、テスト駆動開発、およびソフトウェア開発の他の基本的な側面の理解を向上させることに重点を置いています。GoLには、構造的な観点から非常に豊富でありながら、理解するのが非常に簡単な問題であるという利点があります。coderetreatで実践しているすべてのトピックの例として使用できるシステムの一部を容易に提供します。たとえば、複数のメソッドで（x、y）パラメーターを使用する一般的な実装は、DRYの原則（すべての知識がシステム内で唯一の表現を持っている必要があります）のトポロジに関して話す絶好の機会ですシステム。変更のコストを最小限に抑える設計を構築する例として使用できる他の多くの側面があります。

現在、複数のコードリトリートを行った人がかなりいますが、彼らはまだ問題の興味深い側面を見つけて練習として使用しています。

ConwayのGame of Lifeは、非常に強力な結果をもたらすかなり単純なコーディングセットであるため、ぴったりです。テスト駆動開発を駆動するためにそれを使用することに関しては、あなたが探している結果があなたが書いているコードから明らかではないので、テストは書くのがかなり難しいので、私はそれを賭けました。グライダーを取得するコードを作成するのは、以前にそれをやったことがない場合や、長期間行っていない場合には非常に重要です。したがって、特にTDDがそうであるようにペアプログラミングで実行される場合、その分野の技術を拡張するのに適しています。

役に立つことを教える限りでは。それは一種のラテラル思考の練習です。コードがどのように機能するかを概念化し、それを実行し、それが失敗するのを確認し、データを収集し、リファクタリングし、繰り返し続ける必要があります。これらはすべて、TDDにとって非常に重要です。それを現実の世界にリンクすると、クライアントが「Xが欲しい」というあいまいな要件ドキュメントを渡すようなものです。したがって、Xを指定しますが、Xに到達するのは難しい場合があります。ConwayのGame of Lifeはそれを教えるのが得意です。また、コーディングはかなり簡単で、通常、そうするのに大量のコードを必要としません。（APLは実装のより極端な例の1つです。）したがって、通常実稼働環境で見られるような1週間または2週間の反復ではなく、リトリートの短いセッションに非常に適しています。

Game of Lifeは一方では非常にシンプルなルールのセットであり、他方ではスケーラビリティに関連する高度なプログラミングの最悪の警告のいくつかを含んでいます。結果は決定論的ですが、無限のプレイフィールドと処理する無限のセルという課題があります。

チャレンジスペックに最小パフォーマンスと最大メモリフットプリントが含まれる場合、テストには急速に成長するパターン、またはさまざまな方向に広範囲に移動するパターンが含まれ、これは非常にイライラするチャレンジになる可能性があります。

X回の反復後に既知の入力と既知の出力を取得し、そこに到達するためのすべてのステップを知っています...ステップが多すぎて長すぎます。仕様に収まるように、かなり極端な最適化を実行する必要があります。サイズのO（n ^ 2）でパフォーマンスが低下するため、固定サイズのダブルバッファリングされたビットの2次元配列をスキャンする単純なアルゴリズムは完全に不適切になります。いっぱいになったブロックを新しいスポーンオブジェクトとして扱うと、突然大量のメモリが消費されて遅くなります。限られたサイズのボードにすべてを分けることは時々機能し、時々失敗します...

また、ほとんどの「グローバル」テストはパフォーマンス標準に失敗するため、より小さな目標、より小さなサブテストを開発して、警告を解決する必要があります...

それはすべて、プロセスのどの側面を練習/トレーニングしたいかによって異なります。

選択したアプローチ/プロジェクト管理パラダイムに関係なく、1日だけではソフトウェアエンジニアリングのすべての側面をカバーするのに十分ではありません。したがって、それを効果的にするには、おそらく全体の小さなサブセットに集中する必要があります。

たとえば、TDDの技術的な側面に焦点を当てる場合は、要件と顧客との関係の周りの大きな灰色の領域を手放し、ソリューションのコーディングに直行することができます。

この点で、ゲームオブライフはシンプルで、よく理解されており、議論の余地がある要件に多くの灰色の領域がないため、Game of Lifeは良い候補です。したがって、すぐにテストの記述を開始し、それらに対してコードを作成できます。

一方で、TDDを使用して要件を改善する方法を確認することが目標だった場合、人生のゲームを選択した可能性がありますが、これが私が望むものであることを開発者に伝えなかったでしょう。代わりに、実際に名前で言及することなく、ヒントやアイデアを提供することを一周しました。人生のゲームは、参加者がほとんどすぐに策略を見る可能性が高いため、この種のエクササイズには少し簡単すぎると証明されるかもしれないと言いました。

このような総合的なエクササイズでは、例を見つけるのは必ずしも簡単ではありません。1日でできるようにシンプルである必要がありますが、1日を過ごせるほど単純ではありません。面白くて無意味ではない...しかし、私にとっては少し独創的でなければなりません。宿題用のビデオクラブ管理システムを生徒に作ってもらうように言われた回数を思い出せません。...iiirch。