読書メモ：Software Tools
"Software Tools"（邦題：ソフトウェア作法）はやはり素晴らしくて、以前に記事で書いたが、英語の原書を改めて読むと、もっとぜんぜんメモっておかねばと思う。
Kernighan先生とPlaugerさんの本書はUNIXについて語った本ではないが、UNIX精神が宿った名著である。（とはいえ、まだ序盤しか読んでませんが）
以下、ふたたび私拙訳とメモ。
Far too many programmers are red pencilers. Some are literal red pencilers who do things by hand that should be done by machine. Others are figurative red pencilers whose use of the machines is so clumsy and awkward that it might as well be manual.(p1)
あまりに多くのプログラマが赤ペン使いである。ある者は文字通りの赤ペンを使って機械でやるべき仕事を手でやる。他の者は比喩的な赤ペン使いで、機械の使い方が下手で不器用なため、ほとんど手作業でやってるに等しい。
これだけだと何のことを言っているのか分からないが、本の冒頭も冒頭に書かれていることで、例えばプログラムの移植を行う際にシステムに依存した関数をソースからどう探すか？ という課題に対して、当時はテレタイプが当たり前の時代、つまりソースを紙に印刷して該当関数を見つけて赤ペンをつける！というスタイルをとるプログラマを「赤ペン使い」と言っている。
これに対して本書のテーマは、ツール（プログラム）を書いて解決しましょう。小さく汎用的なツールを書いて、連携させて活用しましょう。ということを推奨している。
しかし、なんとも思い当たる節がありすぎて、、、もちろん赤ペンは使ってないが、例えばテストとかビルドとか手作業で繰り返しやってた自分がなんとも痛々しい。
Whatever your application, your most important tool is a good programming language. Without this, programs are just too hard to write and understand; you spend more time fighting your language than being productive.(p3)
あなたの作るアプリケーションが何であれ、一番重要なツールは良いプログラミング言語である。これなくして、プログラムは書くのも読むのも辛い。あなたは生産することよりも言語と格闘することに時間をとられることになる。
いやまあその通り。今の時代は適材適所に言語もよりどりみどり。 それぞれの分野で、それぞれの強みを持った言語を使いたい。
...it is vital to break larger programs into small pieces that communicate only through well-defined interfaces. The less one part of a program knows about how another part oprates, the more easily each may be changed.(p21)
より大きなプログラムを小さなピースに分割して、よく設計されたインタフェースのみを通してやりとりさせることは極めて重要である。プログラムのある箇所が別の箇所の処理を知らなければ知らないほど、それぞれを変更することが容易になる。
The best programs are designed in terms of loosely coupled functions that each does a simple task.(p21)
一番良いプログラムは、シンプルな処理を行う関数らが緩くつながったように設計されたプログラムである。
前にも書いたが本質的にOOPの原点ですな。
We invest extra effort in the design and coding process (which is fun) to minimize the much costlier testing and debugging phase (which is not). We put strong emphasis on clean, comprehensible code, saving efficiency considerations for the end. We check and test code as we write it, rather than relying on a final debugging binge to fix everything. (p27)
我々は（楽しい）設計とコーディングのプロセスに余分に汗をかくことで、よりコストのかかる（楽しくない）テストとデバッグのフェーズを最小限にする。我々は簡潔で理解しやすいコードに強く重点をおき、効率の追求は最後に考える。我々はコードを書きながらチェックとテストを行い、最後のデバッグですべてを修正するようなことはしない。
テストドリブンの原点ですな。
In our experience, readability is the single best criterion of program quality; if a program is easy to read, it is probably a good program; if it is hard to read, it probably is'nt good.(p28)
我々の経験では、読みやすさこそがプログラムの品質を判断する一番良い基準である。もしプログラムが読みやすければ、それはおそらく良いプログラムで、もし読みにくいのなら、それは多分悪いプログラムだろう。
「リーダブルコード」という本を思い出す。
It is often better to get on with something that does most of the job well enough, then improve and add things as they prove to be worthwhile.(p40)
たいていの場合、まず仕事の大半が必要十分にこなせるものを作ってから、価値があると判断した改善や機能追加をした方がよい。
UNIXの精神そのものだ。 Ken ThompsonさんがPDP-7にまずFilesystemのアイディアを実装してみた、というのがUNIXの始まりですしね。
以上。
