ちょいと昔話を
統合環境やGUIといった便利な環境が登場する以前のプログラミングは、とても面倒な作業でした。ハードもOSもユーザーの求めるものも、今とは随分違っていました。
GUIも統合環境もなかった頃
フォームウィンドウにテキストボックスやコマンドボタンを貼り付け、それをダブルクリックしてソースコードを入力――最近のプログラミングは便利になりました。
GUIも統合環境もなかった時代のプログラミングは、キーボードからコツコツとソースコードを打ち込んでいくという、地味な作業の連続でした。開発に必要な部品や道具を自分で作る必要もありました。そもそも、コンポーネントなんていう発想のなかった時代です。自作の部品をどれだけたくさん持っているかが、ベテランの証だったりしたわけです。
OSもアプリケーションも高機能化し、ソフトウェアの開発サイクルも短くなった現在では、少しでも早く質の高い製品を送り出さなければなりません。時代は変わっているのだから、環境も方法も変わって当たり前です。
今や、GUIも統合環境もコンポーネントも当たり前。面倒な作業を減らして手っ取り早く開発することが求められています。
小さなプログラムをコツコツと……
アプリケーションが複雑になった原因の１つに、コンピュータの使い方に対するユーザーの意識が、大きく変わったことが挙げられます。
ハードウェア自体が非力だった昔は、当然プログラムの規模も小さく、単純な仕事をこなすことしかできませんでした。そこでユーザーは、小さなプログラムを組み合わせて望む結果を得ることになります。
例えば、検索プログラムで住所録から目的のデータを取り出し、その結果をテキスト整形プログラムに渡して印刷用に整形し、さらにその結果を印刷プログラムに渡す……といった形です。
業務システムでも、データ入力、当日分の集計、集計結果の印刷――などの小さなプログラムをバッチ処理で連動させるのが一般的でした。
ところが現在では、１つのプログラムで『検索から印刷まで』を処理できます。業務システムでも、１つのアプリケーションの中で一通りの処理が完結するように作られています。
旧来は１つのプログラムだった処理が、大きなプログラムの中にモジュールとして組み込まれるようになったのです。
インスタントカメラのように
これは、写真にたとえれば
カメラを構えてシャッターを切る
→フィルムを取り出す→フィルムを現像する
→引き伸ばしたいコマを選択する
→フィルムを引き伸ばし機にセットする
→印画紙に露光する→印画紙を現像する
と、何段階ものプロセスを経ていた作業が、
カメラを構えてシャッターを切る
→いきなりプリントが出てくる
というスタイルになってしまったような感じです。
だから作る側は、フィルムを現像したり印画紙に焼き付けたりする過程を全部まとめて処理できるシステムを作らなければならなくなります。すると、それらの工程の内部に隠されているちまちまとした共通処理は「部品」としてまとめられ、プログラムはインスタントカメラ（ポラロイドカメラ）のようになってしまうわけです。
少し不便なプログラミングを
このサイトを運営しているグレープシティでも、たくさんのプログラム部品──コンポーネントを販売しています。だから、これからも部品を組み合わせた楽ちんなプログラミングを続けましょう……と書けば、サイト運営側からは喜んでいただけるかもしれませんが、そんな媚びた態度を取る訳にはいかないのです（あ、でも日頃お世話になっているんだから、少しはおべっか使っておこう→ ※1 (^^;)）。
プログラミングの本質を理解し、スキルを向上させようと思うなら、GUIもコンポーネントも使わない面倒な作業を、一度は経験するべきだと思います。とは言っても、実際の現場でそんな悠長なことをやっている暇はありません。スケジュール表を睨みながら納期に追われて残業の連続……。
だからせめてこのコラムで、まぁ少しは息を抜きながら、ちょっと昔の不便なプログラミングを体験してもらえれば、と思う次第です。
日々複雑で大規模な業務アプリケーションを組み上げなければならないプロにとって、安定した部品（コンポーネント）を使うのは今や常識です。かつてはプログラマーが自分で部品を作るのが当たり前でしたが、各種プラットフォーム（OSやデータベースなど）に対して同じ機能で同じ品質の部品を作るのは、現在ではかなり難しい作業になっています。日々仕事に追われる技術者にとって、昔のようにじっくりと部品を作っている時間がなくなってきたのも事実です。その意味で、完成した部品を使うことは開発作業の効率化に役立っています
|
|
|
TOP