プログラミングはそもそも日常的じゃない
最近のQiitaのMVCの糞記事をみかけて、しかもそれにたくさんの「いいね」がついてて、いろいろ意見があるが、内容もクソなんだが、そもそも日常的なものにたとえて説明すること自体が間違えるもとだと思うので書いておく
さて、元の記事は、なにか日常的なもの、(レストラン)に例えて説明している。元の記事では日常的なものにたとえ、いかにも見栄えが良く、やさしそうに書かれている。しかしながら、それが根本的の間違える元なのだ。プログラミングの設計は、日常的でない。まずこれを意識するべきだ。
もちろん、日常的なものに例えて考えやすくする手もわるくないが、ソフトウェアではそれが往々にして失敗しやすいものだ。
ときどき、日常的なものにマッチすることもあるが、それはそもそも、日常的なものから着想を得ている場合が多いと思う。つまり、日常的な例えがしやすいのは、そもそもが日常的なものをモデリングしたからであって、抽象化されてしまったものを、日常的なものにたとえるのは非常に困難である。
日常的なものにたとえるのが難しいが、でも強引にたとえることによって、逆に理解できなくなることも多いだろう。例えば、変数を箱モデルとして考えることによって、ポインタの理解がむずかしいなんてこともありえる。
どのように理解していくべきか?
ではどのように理解していけばいいのだろう? 日常的でないものにする理解するにはどうすればいいだろうか? 僕なりの答えは、慣れることである。日常的でないものがどうして理解できないかといえば慣れてないからにあると思う。
具体的に言えば、まずはコードを書くべきだと思うのである。最初からすべてを理解しようとするから間違えであって、まずは分かるところから、コードを書いて理解する。これが必要なのではないだろうか。
次に、そもそも、MVCなどのソフトウェアアーキテクチャの理解は、問題があって、解決策としてのものであって、その問題がなにかを適切に提示できてないとダメだし、(そもそも元記事は、MVCの解決しようとする課題を適切に説明できていない)、 それがあってはじめて理解できるものである。
つまり、課題に衝突してなかったら、MVCをやっても無意味だ。それをやるのであれば、GUIをつくるのであれば、それ利用するフレームワークやプラットフォームへの理解をするのが先決だと思う。
つまり、ひたすらコードを書き、問題に衝突し、設計をしていく。そういった熟練が結局は必要になるのである。MVCは数時間あればできるものでもないし、ネットに上っている記事を雑によむだけでは理解できないものだ。
この記事が気に入ったらサポートをしてみませんか?