Read the book "The UNIX Philosophy" | stefafafan's tech blog
あけましておめでとうございます。『UNIXという考え方―その設計思想と哲学』という本を読んでいたら年越していました。
この記事は はてなエンジニア Advent Calendar 2022 の 1月1日の記事です。*1
昨日は 
id:tkzwtks による コーポレートサイトドメイン引越しの裏側 - Hatena Developer Blog でした。
今回は表題の本を今更ながら読みましたので、感想を軽く書きます。
この本で紹介されている9つの定理
この本では以下の9つの定理が紹介されていました。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作を作成する
- 効率より移植性
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアの梃子を有効に活用する
- シェルスクリプトを使うことで梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタにする
わりと色んな粒度の話題が混ざっている気がするので、個人的に以下の3つの分類で整理してみました。
- 設計思想
- 開発プロセス
- 細かい手法
設計思想に関する定理
まずは設計っぽい話題から。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- 効率より移植性
- ソフトウェアの梃子を有効に活用する
このあたりがUNIXなツールを実装する際の設計思想という雰囲気でした。めちゃくちゃざっくりまとめてしまうと「小さくてポータブルなプログラムを書け」「一から全て書くのではなく時には他人のコードを拝借しよう！」みたいな感じですね。
ベンダーロックインを避けてどこでも動くような実装にする、みたいな最近の流行りともフィットしている気がするし、既にライブラリなどが存在しているものがあれば乗っかって本質的な問題に時間をかけたほうが良いというのも納得感がある。小さい単位のものを作って連携し合うようにするのもそれぞれの部品はテストしやすくなるし良いですね。
そういう意味ではたまたま最近作っていたGitHub ActionsもUNIX思想に近い設計になっていました。
この時思ったのは、「1つのActionの責務は1つに抑えると使いやすそう」ということです
PageSpeed Insightsの値を返すだけのGitHub Actionsを作った / Mackerel にも簡単に投稿できる - stefafafan の fa は3つです
また、先日書いた記事にも新しいことを1から考えない的なことをそういえば書いていました。
新しい概念を発明するのではなく社内外にあるものをもとに検討する
はてなのエンジニアとして日々意識しながらやっていることを紹介します - stefafafan の fa は3つです
実は自然と似た思想で日々暮らしていることがわかってよかったですね。
とはいえ気になるのは、実際業務で書いているWebアプリケーションにこの「スモール・イズ・ビューティフル」や「一つのプログラムには一つのことをうまくやらせる」をどう適用するのかという点です。アプリケーション全体というよりはモジュールや関数単位でリファクタリングする際には参考になりそうだし、モノリシックなリポジトリになっているなら分割するなどそういう面でも適用できそうかなと個人的には思いました。
「大きな問題を小さな問題の集合として分割する」という考え方は普遍的に活用できそうです。
開発プロセスの話
- できるだけ早く試作を作成する
この章は読んでいて個人的に アジャイルソフトウェア開発宣言 を連想しました。何かしら大きなものを作るとき、重厚なドキュメントを書ききってから開発するのではなく、最初の設計は軽めに抑えた上でプロトタイプをがんがん作り早い段階でユーザからフィードバックをもらうのが良いという話。完全にアジャイルですね。
この時代のソフトウェアエンジニアはみんなこういう経験をもとに色々と考えた結果、アジャイルソフトウェア開発宣言という成果物をまとめることができたと思うといい話だなという気持ちになりました。また、改めてアジャイルとソフトウェア開発は切っても切れない関係（DevOpsとかも）だなというのを思いました。効率的にソフトウェアの開発を進めたかったら設計やコードを早く書く力を闇雲にあげるのではなく、ボトルネックをはやめに潰せるような進め方をとることが大事ですね。(そしてまた私の以下の記事に繋がる)。
全体的な感想
2023年になって1990年代の本を読んだ状態ですが、完全に現代でも通用する話でサクッと読めて最高でした。読んだ後に「あれ、gitとかmkrのようなツールはサブコマンドが大量にあるけどこれは本当に小さくてシンプルなんだろうか？」という風なことを思ったりしていて、今後しばらくはCLIツールを見るたびにこういうことを考えることになりそうです。
大事なのはどこからが小さいかどうかの線引きではなく、最初から全てを網羅した超巨大なツールを作らないという意識なのかなと思いました。アジャイルな開発をするときも「計画に従うことよりも変化への対応を」求められるので小さく作るのはいずれにしろ大事ですね。
