一階層上を意識する
コンピュータの世界は、問題を簡単にするための仕組みが積み重なって層を成しているように見える。ある「層」は、下の層にある複雑な問題を隠蔽する（プログラマ流に言えば「ラップ（Wrap）」する）ことで、機能を簡単に利用できるようにしている。業務ロジックだけを書く人が、フレームワークの中身を知る必要がないのと同じように、フレームワークを書く人も、言語の処理系（コンパイラやインタプリタ、VM など）の実装内容まで知る必要はない。こうした階層構造は、アプリケーションから OS、ハードウェアの領域に至るまで、幾重にも積み重なっている。技術者が効率的に分業できる仕組みになっているというわけである。
複雑化した現在のコンピュータについて、一人の人間が全ての階層について理解するのは難しい。しかし、自分のスキルを今以上に伸ばそうと思うなら、自分が今立っている「層」のひとつ下ぐらいは覗いてみることも必要だろう。端的に言えば、自分がいつも呼び出している「共通関数」のソースコードを読んでみることである。
スキルアップのためにラップを剥がしてみる
プログラムの技術を磨くためには、もちろん上記は必須。
自分の書いているプログラムが何に依存しているのかを把握しておかないと、不慮の事態に対処できなくなる。
システム開発というのは、実装している期間よりも保守している期間の方がはるかに長い。
それはつまり、プログラムを組んでいる時間よりも、不具合の解析をしている時間の方が長いということだ。
そして運用開始後の不具合は、たいてい自分の書いたプログラムとフレームワークの境界で発生する。
結局、システム開発をやっていれば、嫌でもフレームワークを覗き込まないとならなくなる。
普段からフレームワークを覗き込んでいなければ、運用後の不具合解析のためのスキルが見につかないのだ。
スキルアップのために、自分のプログラムの一階層下を知ろう、というのが元記事の趣旨。
で、僕は、自分のプログラムの一階層上を知ろう、と言いたい。
プログラムなんてものは、結局何かをするための道具に過ぎない。
自分が作っているプログラムが何のための道具なのかを知ることも重要だと思う。
これは、システムを設計する人だけがわかっていればいいのではなくて、現場のプログラマ全員が把握しているべきだ。
例えば、元記事のフレームワークというのは、結局業務ロジックを書くための道具だ。
だから、業務ロジックが満たすべき要件はすべて満たしていなければならない。
そのためには、「業務ロジックが満たすべき条件」、業務ロジックの「一階層上」について知っていなければならないと思う。
同じ包丁だとしても、パンを切るのか、魚をさばくのか、果物の皮を剥くのかによって、最終的にできあがるものは異なる。
最終形をイメージしてプログラムを組んでいるかどうかで、できあがるプログラムの質はかなり変わる。
だから、システム開発をする際には、一階層下を覗き込むと同時に、一階層上を意識しなければならないと思う。
なんだかぐだぐだな文章だなぁ。
どうも書くのって苦手だ・・・。
