『UNIXという考え方』 読書メモ

#概要

• 『UNIXという考え方』の要約というか、読書メモです。
• UNIXの設計思想にフォーカスしているはずが、「処理効率より移植性」「100%ではなく現実的な90%を目指す」「後から変更しやすいプログラムにする」「車輪の再発明はしない」などUNIX以外にも当てはまる汎用的なテーマが多く面白い。

#UNIXの考え方 : 基本的な9つの定理

• [定理1] スモール・イズ・ビューティフル
• [定理2] 1つのプログラムには1つのことをうまくやらせる
• [定理3] できるだけ早く試作する
• [定理4] 効率より移植性を優先する
• [定理5] 数値データはASCIIフラットファイルに保存する
• [定理6] ソフトウェアを梃子(てこ)として使う
• [定理7] シェルスクリプトによって梃子(てこ)の効果と移植性を高める
• [定理8] 過渡の対話的インターフェースを避ける
• [定理9] すべてのプログラムをフィルタとして設計する

#面白かった部分のメモ

小さなプログラムという発想

「なるべく小さな部品に分けよう」という主張や、「小さいほうが保守もテストも楽だ」というメリットはよく聞くが、「みんなそう思ってるのになぜプログラムは肥大化するの?」という点に言及しているのが面白かった。

• 一般にソフトウェアの開発者は、巨大なプログラムを書いてしまう。これは「あらゆる不測の事態に対応できるように」という誤った考えに基づくものだ

• 一方、小さなプログラムの開発者は、未来の予測など最初からあきらめている。彼らの予測することは、明日作られるものは今日作っているものとは違うということでしかない。
• 作った時には予測できなかったことに対しても、小さなプログラムなら直ちにそれに対処できる。
• 現実には、その場かぎりの小さな解決策でも解決できない問題はそれほど多くはない。
• creeping featurism(しのびよる多機能主義)

なぜソフトウェアは「ソフト」ウェアなのか

未来の予測はむずかしいし、たいてい予測どおりにはいかない。

• ソフトウェア開発に終わりはない。あるのはリリースだけだ。

• ソフトウェア技術者たちが、ユーザーが現在必要としている機能と将来必要になるであろう機能とをすべて把握していたとすれば、ソフトウェアはいらないだろう。すべてのプログラムは、最初からROMに書かれていればいい。
• ソフトウェアのエンジニアという職業には、継続的な改訂作業がつきものだ。

プログラムを速くすることに時間をかけない

• 多くのUNIXプログラマが犯す間違いの一つに、わずかな速度を求めてシェルスクリプトをC言語で書き直すというものがある。

• 将来のハードウェアでの性能向上を常に視野に入れて置かなければならない。
• そのプログラム自身のためだけに、速くしようとする誘惑に抵抗することだ。来年の新マシンはすぐそこまで来ている。
• プログラムの速度に多少の不満があっても、現在のニーズが満たされていればそれでよしとする。

シェルスクリプトをC言語で書き直すという誘惑に負けない

• UNIX環境においてのC言語には、シェルスクリプトのような移植性はない

• シェルスクリプトの持つ思わぬ利点は、C言語で書いたプログラムよりずっと移植性が高いことだ。
• 変わった意見に聞こえるかもしれないが、C言語でプログラムを書くのは、絶対に必要な場合以外はなるべく避けるべきだ。

##効率より移植性

• C言語よりシェルスクリプトの方が移植性が高いとありますが、今ならGo言語がいいかも、という意見を見つけました。

移植性の話でシェルスクリプトが礼賛されてるけど
今だとクロスコンパイルの効くgolangが良いと思う。
UNIXという考え方読んだ - はこべブログ

最も効率のよい方法は、ほとんどの場合移植性に欠ける

• ハードウェアと切り離すことができないソフトウェアは、そのハードウェアが競争力を持ち続ける間しか価値を維持できない

• より高速なハードウェアによって既存のハードウェアが置き換えられる度に書き直さなければならない。

プログラムはデータを作らない。人間がつくる

• ソフトウェアの本質は、データを処理することで、生成することではない。

理想を追いかけるより現実的な小さな解決

• さまざまな批判を浴びせかけられるだろう。しかし、当の本人は「ああ、そりゃちょっと汚いのは分かってる。でもちゃんと役に立ってるだろ!」と、こういうだろう。

• 「正しく」やる時間がない人間は、重要な箇所だけに集中して枝葉を無視する。その結果、いくつかの細かい点は次のバージョンに回そうと計画する