フレームワークを理解しないでプログラミングしてるエンジニアっているんだね

@nabeemichi です。

アプリケーションをつくるときにフレームワークを必ずといっていいほど利用する。 最近のエンジニアにとっては、フレームワークをうまく利用して効率的に開発することが重要になってくる。

フリーランスエンジニアとして働いていると、いろいろな経歴のエンジニアと働くのだが、 フレームワークを理解しないでプログラミングしているエンジニアが一定数いることに気づいた。

フレームワークを理解するとは

フレームワークや技術を理解するということは、理論と動作の2つを確認して初めて理解したということになる。

理論はフレームワークのドキュメントから論理てきに頭で理解する。 オープンソースのフレームワークでソースコードが公開されている場合は、ソースコードを読んで論理的に動作を頭の中でイメージできる状態にしてもいい。 とにかく、文字列を読んで頭で動きを予想できる状態になることが理論的にわかっている！という状態なのだ。

しかし、これだけではフレームワークを理解している状態だということができない。 文字列を読んでイメージできても、所詮は人間である。勘違いしてる場合だってあるのだ。 そこで重要なのは、実際に動かして目で見て確かめることだ。 頭でイメージした状態が、目の前で動いてイメージと一致する状態を確認しなければ、理解しているとは言えないのだ。

理解してないで使ってるとは

上記で述べたことの一方しか確認してない状態で作っている。 特に、動きだけ見て作っている。 動きの確認は、ドキュメントみてサンプルを見て、コピペして自分のやりたい動作になるように改造している。

たしかにこれでもアプリケーションは作れるし、つくる速度もは一旦は早い。 ここでの問題は、理解しないで作ってるから、つじつま合わせの実装が増えて、何をしたいのか理解できないソースコードが出来上がることだ。 そう！実現したいことに対して最短のアプローチを取れていない状態を作り上げている。 こうなってくると、フレームワークを利用して効率的に開発を行いたいのに、非効率を作り出している。

さらにつじつま合わせの実装を行うということは、不具合や問題が起こったときに何をしていいのかわからない状態になっているのだ。 不具合に蓋をするためにさらにつじつま合わせのの実装で回避する。 こうなったら、もう何も問題が発生しないでくれ！と念じるしかない。 （いや、問題起きても時間かければ一つづつ紐解いていけばいいのですがね。泣きたくなります）

プログラミングのソースコードってね、書けば書くほど不具合の発生確立も高くなるし、負債にもなるんですよね。 書かなくていいものは書かないで、違うとこにパワー使おうよ。 そのためには、理解して使ったほうが、なにかと早いと思うけどね。