ベストプラクティスとしてのサンプルについて -「ユーザさん/開発者にとって」シリーズその3-

シリーズ3回目はまたもサンプルです。
ただし今回はサンプルはサンプルでもショウケースとしてのサンプルではありません。
ベストプラクティスとしてのサンプルです。

前回はミクロな視点で各機能のディティールを紹介するショウケースの意義について
書きました。今回はマクロな視点であるベストプラクティスとしてのサンプルの意義について書きます。

ベストプラクティスとは何でしょうか？
それは言葉を変えれば勝ちパターンといえます。
このような方針でこんな全体像であればアプリケーションを構築するのが成功するんだという
メッセージを伝えるのがベストプラクティスです。
細かい機能が知りたいのであればショウケースを見るべきです。
製品が提供するサンプルアプリケーションには、このベストプラクティスを伝える
意味合いがあるものがなければいけないと思っています。
言い方を変えれば、成功疑似体験を伝えるべきといえます。
（この後このようなベストプラクティスを伝えるサンプルアプリを
ベストプラクティスアプリと呼びます）

ユーザさんにとっては、非常に効率的に全体感覚をつかむことが出来るのが
最大のメリットです。通常仕事で作るWebアプリケーションには大体のカテゴリ
（たとえばBtoC向けショッピングサイトなど）が存在するので、
そのユーザさんが作ろうとしているWebアプリにマッチするかを
瞬時に判断したい場合にはベストプラクティスアプリを見てみるのが最適でしょう。
カテゴリにかなり近いサンプルアプリがある場合にはかなりの確度で
使えるか・使えないかを的確に判断できるんじゃないでしょうか。

また開発者にとっては、ベストプラクティスアプリは自分たちが伝える
開発のしやすさ・全体感などを作って体感してみるよい機会です。
ベストプラクティスアプリを作ってみるまでは決して自分でイメージしたものに
近いかどうかを確信を得ることが出来ないように思います。
また、近代的なフレームワークであれば他のフレームワークとの連携機能も非常に重要です。
実際に組み合わせて動かしてみてわかることも多いので、
このような全体としての気づきを得るためにとても重要な意味をもつのが
ベストプラクティスアプリであるといえます。

このようにベストプラクティスアプリは全体感をつかむには非常に重要です。
ユーザさんの側にたつと、「全体とおしたらどんな感じになるの？」、
「コードの記述量は？」「連携部分は？」「View、Service、Daoの切り分けは？」など
全体を通しての疑問や適切な責務の配置を必ず考えるので、そういった点で
作る側がこれがお奨めですよ、というのを形に示すのがベストプラクティスとしての
サンプルアプリケーションであると考えています。

次回はUTについて考えてみます。