「Unixという考え方」を読んだ際の個人的メモ

この記事について

「Unixという考え方」を読んだ際、個人的に印象に残った考え方を。メモしたものです。

スモール・イズ・ビューティフル

• 忠実に、解決したい問題だけを解決するプログラムを組む。そこに余計なものはいらないという考え方。言い換えれば、一つのプログラムには一つのことをうまくやらせよう。
  例えばファイルをコピーするプログラムを作ろうと考えているなら、ファイルをコピーするロジックだけを提供すれば良い。そこにエラー処理とかをいっぱい載せたくなるのを我慢すること。そうすれば必然的に小さなプログラムとなる。
  　　
• そして小さなプログラム単独で行えることは大したことなくても、「組み合わせる」ことで大きな力を発揮する。
  また、小さなプログラムはわかりやすく、保守しやすく、そしてシステムリソースにも優しい。
  　　
• 巨大で複雑、リッチで強力なプログラムは便利とされているが、「現状のあらゆる不測の事態に対応できるように」作られたものは、果たして将来の技術の進歩と、それに伴うインタフェースの実装作業に耐えられるのだろうか。
  対して、複数の小さなプログラムで構成された一つの仕事をこなすプログラムは、(はじめから)細かなモジュール化がされているため、部品(小さなプログラム)を少し取り替えたり変更するだけで、新しいインタフェースが必要になっても対応可能になる。

効率より移植性

• 効率の良いプログラムを書こうと思うと、ハードウェアの持つ特殊な機能を利用して、そのマシンに最適化された、他のマシンとは互換性の無い方法で実現しようとする。効率の良い書き方は往々にしてこうなりがちだ。
  　　
• しかし、特定のアーキテクチャでしか動作しないソフトウェアはやがて淘汰されてしまう。なぜなら次に登場するハードウェアは今までよりもっと高速だからだ。そして次に登場するハードウェアは更に高速だろう。つまりプログラムの移植が容易であるほど、そのずっと先のマシンでも生き残り続けることができる。反対にマシンに依存したプログラムを書いていると、移植する際に多大な努力を必要としてしまい、そのうち誰もそのプログラムを移植しようだなんて考えなくなる。
  　　
• つまり、プログラムを速くすることには時間をかけないほうが良い。プログラムが低効率でも次の年にはハードウェアの高性能化で気にならなくなるよ。
  それに、できることならシェルスクリプトで書いたほうが移植性は高い。

ソフトウェアの梃子を有効に活用する

• 偉大なプログラマはよいコードを借りてくる。すでに同じ問題を解決する方法が先人によって提供されているなら、それを取り込むべきであり、これはコードを書く時間やアプリケーションへの投資を少なく抑えることができる。大事なのはそのソフトウェアが仕事をこなせるかどうかであり、他人の仕事を借りた結果かどうかではない。
  　　

• ソフトウェアの梃子を効率的に利用する方法の一つは、全てを自動化することであり、自動化できそうなタスクはソフトウェアの梃子を利用して自動化を勧めてしまおう。これは余計な作業時間を減らし、生産性を飛躍的に向上させるだろう。
  　　

• シェルスクリプトにはおそろしいほどの梃子の効果がある。シェルスクリプトは数千、数万行ものC言語のソースコードからコンパイルされており、自分で書いたものではない。それを組み合わせて各コマンドを実行させるだけでも、何百万行以上ものコードの実行結果を自分のものにできる。

• シェルスクリプトはC言語よりも移植性が高いので、シェルスクリプトをC言語で書き直したいという誘惑には負けてはいけない。なぜならC言語のプログラムはヘッダファイルの定義や、マシンアーキテクチャサイズ、その他UNIX実装の持つ移植不能な様々な原因から、その移植性は低いからだ。

個人的な感想

特に「小さなプログラムを組み合わせる」という考え方には感動を覚えました。小さくて一つの仕事をきっちりこなせるプログラムを、一つの構成要素として他のプログラムと組み合わせ、巨大なストラクチャを形作るというのは、様々な面において合理的な考え方だと感じました。