2012

フレームワークという考え方、そして使い方三か条

設計の概念としてフレームワークというものがあります。
ざっくばらんに言うと、開発を楽にするツール、といったところでしょうか。
いくらなんでもこれはざっくりしすぎですが。

フレームワークとは
ソフトウェアの世界では、アプリケーションソフトを開発する際に頻繁に必要とされる汎用的な機能をまとめて提供し、アプリケーションの土台として機能するソフトウェアのこと。アプリケーションの雛型。開発にフレームワークを利用すると、独自に必要とされる部分だけを開発すれば済むため開発効率の向上が見込める。具体的なソフトウェアだけでなく、汎用的に適用できるプログラムの設計モデルや典型的な処理パターンなどを含めてフレームワークと呼ぶ場合もある。

出典元：IT用語辞典 – フレームワーク

効率的な考え方なので、理解しておくと作業が捗ります。
勿論、知らずにやっておられる方もいるのではないでしょうか。
例えばコーダーの方で、制作に入る際にテンプレートを用意して制作する方。
いわばこのテンプレートもフレームワークと言えます。

フレームワークは開発における土台ですので、テンプレートとも言えるわけです。
ただ、それだとテンプレと何が違うの、という話になるので、もうちょっと突っ込んでみます。

1.フレームワークは品質維持に用いる

有名どころで言うと、フレームワークはいくつかあります。
PHPのフレームワーク「CakePHP」やJavaのフレームワーク「Struts」など。
大体はプログラミング言語の土台として使われることが多いですね。

その理由としては、品質維持や開発効率向上といった目的があります。
設計をするのは仕事として当然になってくるのですが、その品質をある水準に保つ。
そういったことがフレームワークでは出来るわけですね。

例えばですが、あるプログラムを複数人に依頼したとします。
当然、ソースコードはバラバラ、なんてことが起こります。
こんなのは頻発していたのでは、プログラマーによってバグが生み出されることになります。
案件が大きくなり携わる人数が増えれば増えた分だけ、バグ修正が大変になります。
そこでフレームワークを用います。

フレームワークを使う事はテンプレートとしての開発効率向上以上に
バグを抽出する、もしくはそもそもバグを生み出さないプログラミングの仕方を提供してくれます。
つまり言語ではなく、フレームワーク自身が判断してソースコードを訂正するよう求めるのです。
ソースの書き方は千差万別ですが、その千差万別を数通り、場合によっては一つに絞ってくれます。
これが非常に便利。

ソースコードによる、品質のばらつきがなくなる、という事です。
品質のばらつきがなくなることは設計者にとって、とてもありがたい事になります。
人材の選別に力を入れる必要がなく、また人材を投入しやすい。
これがまた開発効率を援助していることにも繋がっていますね。

2.フレームワークにも得手不得手はある

しかし当然、フレームワークにも苦手な事はあります。
簡単なことですが、ソースを含め、品質維持や効率重視の為、限定される事が多くなります。
なので場合によっては効率的なことを、フレームワークによって否定される事もあります。

しかし土台がそうなってしまっているので、プログラマーは従う必要性があります。
そこでプログラマーがフレームワークを書き換えてしまっては意味がありませんからね。
本来多種多様なプログラマーの性質を一方向にしてしまうのがフレームワーク。
これはこれで諸刃の剣とも言えるわけです。

そこで当然、設計者はよりやりやすいようにフレームワークをスーパープログラマーなどと一緒に改変したりするのですが、これまた難しい。土台を改変するという事は、一部を修正すると他を修正する必要もあり、結局全体的な修正が必要になってきます。
最終的にプロジェクト内で、まずフレームワークの作成から、なんていう話もあります。
そしてフレームワークを作るというのは、相当なレベルを持った人材が必要になりますので、かなり大変です。

大抵のところはそんな予算出ませんから、仕方なしに既存のフレームワークを使うわけです。
不平不満が出るところは、我慢していくしかありません。

今ではかなり種類も豊富でバージョンアップもしていってますから、選択肢は多めです。
環境に合ったフレームワークを選べば、大事故になることはないでしょう。

3.フレームワークは自分で積み重ねたソースで作っていく

これはプログラマーにも、コーダーにも言える話です。
とても大事な事ですが、外部のフレームワークのツールに頼るだけではなく
自分自身なりのフレームワークを作っておくことをオススメします。
人によってはテンプレと呼ぶものかもしれません。それでも問題ないです。

これの重要性は前述したように、まずはミスを減らすこと。
動作確認済みのコードであれば、そもそもそこでミスがある事はない。
となればエラーが出たときも探す箇所や手間が省けてとても楽なのです。
そしてミスを減らすことは作業効率の向上に繋がる、というわけです。

定番のコードをEvernoteに保存しているコーダーさんやプログラマーさんもいるようです。
そういった使い方も一種のフレームワークを持っている、と言えるかもしれません。

あまり作業効率がどうたら、とか品質がどうたら、と言いすぎると自由がないように見えます。
ですので、自分なりのフレームワーク、自分が楽しめるコードを保存しておくのです。
苦労して作ったソースなんかは愛着すら沸いてきますよね。
それの集合体だと思ってくれれば。まるで子供のように感じる事でしょう。

慣れてくると、コーディングが一瞬で終わります。
実はコーディングやプログラミングにおいて重要なのは技術力よりも引き出し。
いわゆる経験回数や実施回数、検索回数から生まれる実践的な知識、という事になります。
それを総合して技術力、と言う場合もありますが、知識さえあれば経験がなくても引っ張り出せます。
今の時代、検索すればコードはいくらでも落ちてますからね。有意義に使いましょう。

脱線しますが、私も今、ちょっとした勉強でJavaをやっています。
内容は

「20日までにJavaのAPIの癖を把握する事」

APIの癖というのはループ文で最も早いのは何か。
ある特定の動作を行う際、最も効率的な構文はどれか。
複数ある数値型のうち、小数点を扱うならばどれを使うか。

これは今、私が入ろうとしている現場の水準で問われます。
サーバーのスペックは神様クラスなので、レスポンスがどう、よりもバグが起きない、無理がないソースを求められます。
なので、ある程度答えは明確に決まっているようです。
最も、根本的な事を言えばforやwhile doもそうですが、利用する状況というのが想定されています。
だからこそ同じループ処理でも書き方が違う。while doなんかは厳密にはループ処理ではないですし。
となると、最速のループ文、と問われるとforしか残らなかったりするんですよね。

こういったAPIの癖を把握するのには、どういう意味があるのか。
簡単です。前述した引き出し力をアップさせる為です。
本質、というものを理解していると、想定外のことを問われても検索し、自分にない知識を引っ張り出せます。
これが今の時代では重要なスキルで、自分が持っていないものを瞬時に取り入れる能力というものが求められます。

逆に固定観念を持ってしまうと、forとwhile doの違いすらわからなくなってしまう。
何となく使っている状態になると、そこで思考がストップする。
想定外の事が起きると、テンパってしまうわけですね。これではいけない。

しっかりと本質を理解した上で、コーディング、プログラミングに当たりたいものです。
そうであればフレームワークを作ること、そして利用する事もなんら苦はないはずです。

技術力を高めたいなら、まずは引き出し力を上げましょう。
オチが何か変わっちゃいましたが、たまにはこんなテイストも。