サンプル実装

プロトタイプを作る。と読み替えてもらってもよいです。
よく機能の検証や、画面の動きや連携などでサンプルを作成する機会があると思います。
このときに、どのように作るでしょうか？
どうせサンプルなのでという考えで、ざっくりと画面直下やビハインドコードに押し込めてしまったりしていませんか？
この方法だと結局作り直すことになってしまいます。その作り直し方も切り貼りが中心になり、データのハンドリングで苦労して、結局時間を浪費することになってしまう可能性が高いです。もっと悪いことに偶然動いてしまい、深刻なバグの表出の発見が遅れてしまうことにもなりかねません。

サンプル実装とは言え、手を抜くべきではないです。
したがってあえてプロトタイプと読み替えても構わないということを書きました。
実はサンプルだからこそ、しっかりと検証すべきなのです。ここでいう検証はアーキテクチャや設計、パターン、抽象化、データの表現、通信などが含まれます。
つまりシステムに関するほとんどの現象がこのときに確認されるべきなのです。
しっかり作りこんでしまったら本番と変わりなくなってしまうではないか？　という意見も当然ながら出てくると思います。
ここで検証すべき本質はデータのハンドリングの妥当性、アーキテクチャのバランス、また、とくに通信系は本当に接続が可能なのか？という点について入念に検証すべきです。

ここまできて気がついた方は多いかもしれませんが、サンプル実装（プロトタイプ）は、ほとんど本番です。プロトタイプで幾十にも検証されて本番に発展してゆくのです。ここで検証の状態や意図した設計がよくなければほかの手段を検討することになります。
このプロセスの段階で再検討は許容範囲です。この段階でしっかり根拠をつかむことなく、いい加減な状態で本番実装に入ると、ある程度実装が進んだ段階で問題が発露します。
これは、いわゆる手遅れの状態です。
ここで本来の姿に戻すには、結局ごまかすか、作り直すか、の選択になると思います。

結局、プロトタイプの考え方が生産性や安定性に大きな影響を与えるのです。

よく、こんなことを聞きませんか？
「これで、きっと出来るはず。」
これは根拠のない、ただの願望です。