<< 前 ホーム 次 >>

bakaid: 20051108

やべー。いつのまにかフランスで暴動とか起きてるし。断食しすぎ。東スポだ
けじゃ本田ミナコがお亡くなりになったとか、そういったことしか分からない
もんな。デイリーも読んでるんだけど。『甲子園リニューアル計画!』とか、
『来年こそは日本一で晴れてパレードを!』とかばっかだし。

--

ちょっと気が狂って、``Software Tools in Pascal'' (STiP) 読んでるんです
けどね。

これ、日本語訳出てないんですけど。出てるのは``Software Tools'' (邦題
『ソフトウェア作法』) のほうで。

『ソフトウェア作法』って共立でしたっけ? 今でもそれは書店に並んでて、
かなりロングセラーなわけですけど。でも、そっちよりSTiP出すべきでしたね。
STiPが日本で広く読まれてないのはかなりの損失ですよ。さすがにRatforじゃ
ツラすぎますもん。

これ読んで、紛れもなく自分はKernighan's Childだってことを再認識したわ
けですが。まぁ、でも、自分らより上の世代でC/UNIXやってた人なら大抵そう
なんでしょうけど。

ところで、前から『プログラミングの基礎ってナニ?』って悩んでたんですよ
ね。いわゆる逐次実行、分岐、繰り返しといったものや、変数、配列、関数と
いったものが基礎といわれてると思うんですけど。まぁ、それはそれで間違い
ではないんですけど、『ちょっと足りねーんじゃねーの?』って思ってたんで
すね。

で、STiPにその悩みを解決するヒントがあると感じたんです。結局、分岐とか
変数とかは、基礎は基礎なんですけど、基礎というよか初歩なんですね。それ
がなきゃ始まらないけど、それだけじゃどうにもなんないっていうか。

で、その足りないものっていうのは設計の知識なんですね。設計とはどういっ
たことをやることなのかとか、どういう設計がいい設計なのかとか。

こういったことっていうのは、実はまとめて語られることがあんまりないんで
すね。少なくともナントカ入門とかいう本じゃ語られない。語られることがあっ
たとしても、主題じゃなくって文脈の中に埋もれてしまってたりする。で、ナ
ントカ設計入門みたいになると、今度は全然コードが出てこなったりする。そ
れじゃダメなわけで。

設計に関してそれなりにまとめられていて、なおかつ具体的な話もしてる本と
なると、真っ先にあげられるのが``Smalltalk Best Practice Patterns''。やっ
ぱりこれは必読ということになりますね。あと、``Test-Driven
Development''もそれっぽい。まだ読み終えてないんですけど。(『STiPよりそっ
ち先に読め』ってのはナシ (笑))

でも、古典ということであれば、やっぱり``Software Tools in Pascal''とい
うことになるんですよね。

  Yet it is a fundamental principle of testing that you must know in advance what
  answer each test case is supposed to produce. If you don't, you're not testing;
  you're experimenting. So part of the responsibility of writing a program is to
  prepare a comprehensive set of test inputs, and outputs against which to com-
  pare the results of test runs.

これなんか、TDDほどじゃないですけど、『プログラムを書くという中には、
テストのためのデータを用意することも含まれる』っていってるわけで。自分
は『ソフトウェア作法』読んだはずなんですけど、『こんなこと書かれてたの
か』とちょっとビックリしました。

マニュアル・ファーストっていう実践も紹介されています:

  This time we present the manual page before the program, a useful way to
  begin any project -- it encourages us to focus from the start on how the final
  product is going to look to the user. 
  (中略)
  Another advantage of writing the manual page first is that it gives us a pre-
  cise specification of the job to be done.
  (中略)
  Of all the factors (other
  than native ability) known to influence programmer productivity, the single
  most important one is the quality of specification given at the outset -- the
  more precise and unambiguous the better.

あんまり派手に引用できないんで中略だらけになってますけど。これなんかも
マニュアルをユニット・テストに読み換えれば今でも納得できる話ですよね。
もちろん、今でもマニュアル・ファースト自体も有効なんでしょうけど。

ちょっと今、『ソフトウェア作法』引っぱり出してきたんですけど。1991年の
初版31刷です。これは引っ越すときに捨てられなかった一冊です。で、見比べ
ると、結構章立てとかも変わってます。こっちにはマニュアル・ファーストは
紹介されてないみたいですね。

そうそう、『ソフトウェア作法』には『電話テスト』っていう有名な話があり
ますね:

  一般に、(論理式で)怪しいと思ったときは「電話テスト」というのをやって
  みるとよい。論理式を声を出して読みあげたのを耳で聞いて理解できたら、
  その論理式はまずはわかりやすいといってよい。そうでなかったら書き換え
  をすべきだ。

っていう。これはんかも感覚に訴えるプログラミングなわけですよね。これは
STiPでも紹介されてる話です。

まぁ、長々と書いてますけど、でも今さらSTiPを読めとか、日本語訳を出せと
かいうのもアレなわけで。いや、出したほうがいいと確信してますけど。でも、
それよりももっとモダンな本があればいいわけで。なんてったって20年以上前
の本ですからね。かといってSBPPじゃキツい人も多かろうと思うんですよね。
誰か書いてください。いや、自分が知らないだけかもしれませんけど。

--

プログラミングの基礎の話の続きなんですけど、設計に関する話っていうのは、
大まかにいって、原則と姿勢に分けられると思うんですよ。

原則っていうのはonce and only onceだとかlots of little piecesだとか
intention revealing だとか。あと自分で思いつくのはhigh cohesion, loose
couplingとか?

姿勢っていうのは作業方針とか心がけとかですね。test firstとかDRYとか。
擬似コードとかspikeなんかも入れちゃいましょう。

こういう原則と姿勢っていうのがプログラミングの基礎に含まれるんだと。

たとえばの話、こうした原則や姿勢を知らないでコードを書くこともできるわ
けです。でも、それでもって『あいつは基礎ができてる』とはいわれないで
しょ? 

あと、世間では基礎と見なされてるものでも、自分から見れば間違ってるのも
ありますよね。トップダウンとかボトムアップとか、そんなにプログラミング
は単純じゃないですし。ラピッド・プロトタイピングとかも今じゃ捨テ。もち
ろん、フローチャートとかUMLなんかは基礎でも応用でもない。

で、こうした基礎があって、それぞれの分野に関する知識を上乗せしてくもん
でしょう。言語の詳細だとかOSとかフレームワークとか。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails