Example A Working Prototype of th e Warehouse Packer(P238〜P241) †
要約 †
倉庫梱包ソフトを最適なロジックで作成するのは大変だ。開発者と業務専門の小チームが分離されその仕事に割り当てられるが、、まだコーディングには取り掛かっていない。それまでの間、他の小チームはデータベースから一覧を取り出してPackerに引き渡し、結果を解釈するアプリケーションを開発する。彼らは求められるPackerを設計しようとするが、せいぜいUIのモックアップをつくり、データベースと結合して動くようにするぐらいしかできない。本当に意味のある振る舞いをするインターフェイスを見せて、良いフィードバックを得ることはできないだろう。
同じ理由でPackerチームもまた孤立した状況で作業する。
倉庫梱包の例で示されたドメインオブジェクトとSERVICEインターフェイスによって、アプリケーションチームはPackerの簡単な実装を実現し、開発を円滑に平行して進め、フィードーバック循環を終わらせることができる。それが一貫したシステムへの唯一の効果的な方法である。
（Containerコード例）
（PrototypePacker?コード例）
コメント：このメソッドは書かれているとおりASSERTIONの役割を果たしている。しかし、例外がスローされるとコンテナの内容は変えられてしまうかもしれない。ロールバックはより高位で処理される
このコードは求められたものの多くを取り除いているとはいえ、少なくとも砂を専用のコンテナに梱包して有害化学薬品を梱包する前に部屋から出したりするだろう。収入を最適化したりはしない。しかし、多くの最適化問題は完全には解決しない。この実装はこれまで提示してきた規則に従っている。
プロトタイプによって、外部システムとの接続など、開発者はすばやく動ける。Packer開発チームは業務専門家がプロトタイプから得たフィードバックを受けて、要件を明確化、プロトタイプを微調整してアイデアを試したりする。
また、インターフェイスを最新の状態に保ち、アプリケーションとドメインオブジェクトのリファクタリングを進め、早期に統合に関する問題に取り組む。
Packerが洗練されてくると、統合はスムーズに進むはず。アプリケーションがプロトタイプとやりとりするように書かれているため。
専門家でも正しく最適化するには数ヶ月かかる。ユーザがプロトタイプとやりとりして得たフィードバックのおかげである。その間、他システムは開発中、何かしらやりとりするものを持っている。
「動作する元も簡単なもの」の例を見てきたが、より洗練されたモデルにより実際に可能となる。簡単に理解できる数十行のコードからなる、（複雑なコンポーネントに対する）機能的なプロトタイプを作れる。MODEL-DRIVENアプローチを小さくすると理解が困難になり、変更も困難になる（Packerは設計の停止と連動しているため）。そして、このケースではプロトタイプにより時間がかかってしまうだろう。
（左側注釈）
プロトタイプにまつわる停滞
フル実装がでてくるまで待つのか。MODEL-DRIVENプロトタイプのキーコンポーネントでも簡単になる。インターフェイスと実装が分離されていれば、何らかの動く実装がプロジェクトを並行的に進める助けになる。時が来ればプロトタイプはより適正なものに置き換わる。
担当者のつぶやき †
直訳っぽく、なおかつ後半意味がよくわかっていません。
みんなのつっこみ †
- 全体としては、「インターフェイスの仕様がしっかり決まっていれば、プロトタイプとして適当な実装を提供おくことで他チームとのやり取りをスムーズに行なうことができる。」というお話だと思います。
- 「このコードは求められたものの」の部分で言わんとしているのは「いろいろ問題はあるけれど、一応仕様は満たしているんだよ」ということではないでしょうか。以下拙訳です。
- 確かにこのコードには多くの課題が残されている。砂を特殊なコンテナに詰めた上で有害物質を詰める前に部屋から出てきてしまうかもしれない。これでコストが最適化されることはまず無いだろう。しかし、最適化に関する多くの問題はどのみち完全には解決されない。この実装は確実にこれまで述べられてきた規則には従っているのだ。 -- 和智?
