こんにちは。
都内でバックエンドエンジニアをしている増田です。
今まで見逃してきてしまったのですが、今回はUNIX哲学について扱った名著「UNIXという考え方」について扱っていきます。
現在幅広く使用されているlinuxやmacOSの元ともなっている、世界最古のOSであるUNIXの根底にある設計思想や哲学を学ぶことで、サーバーに関する理解が深まるのではないかと思い、本書を読んでみることに。
今回は特に刺さった箇所を取り上げて感想を書いていきます。
定理1、定理2
定理1：スモール・イズ・ビューティフル（小さいものは美しい）
定理2：一つのプログラムには一つのことをうまくやらせる
「しのびよる多機能主義」の話で、X（旧Twitter）やInstagramなどのSNSで、アップデートされた時に無駄に凝ったデザインや新しい機能を追加してしまって、「改悪した」とユーザーから叩かれている場面が頭に浮かびました。
本書は90年代に書かれたものですが、エンジニアの「クリエイティヴさが新機能や新しいオプションを付けてしまう」という性質は昔から変わらないみたいです。自分にも新しく覚えたこの機能を試してみたい！ や、凄い機能を追加したい！ という欲望があるので、エンジニアの一人としてつくづく実感する話でした。
ですが、これは自社開発の話であって、小さなプログラムやシンプルなプログラムが良いということを理解しつつも、エンドユーザーが存在する受託開発をする場合、相手の要望を応えることが第一となるので、どうしても難しい部分があるな……と思いました。
実際、様々なSIerの関わっている官公庁のシステムを見てみると、よくわからない機能が付いていたり、ユーザーファーストではないUI/UXになっていたりするので、たくさんの人が関われば関わるほど、理想とは遠くなっていく気がします。
そうなると、自分が関わっている範囲だけでも、できるだけシンプルなコードを書くことを意識しながら開発をしていくしかなさそうです。
定理3
定理3：できるだけ早く試作を作成する
できるだけ早く試作を作成してユーザーに触ってもらうために、ソフトウェア開発を従来の設計方法（恐らくウォーターフォール開発のことだろう）ではなく、UNIX的に短い機能仕様書を書く→開発→テストを繰り返して、その後に必要があれば詳細なドキュメントを必要であれば書くのがいいというもの。
流石に本書で示されているUNIX的な開発手法では、例えばサイクルを繰り返した後に詳細ドキュメントを追加しようとなっても混乱が起きそうだなと思ってしまうのですが、現在ではアジャイル開発やスクラム開発といった、短期間の開発サイクルを繰り返して行う開発手法も現場で広まってきているので、「できるだけ早く試作を作成する」という思想が根付いてきているような気がします。
定理6,7
定理6：ソフトウェアの梃子を有効に活用する
定理7：シェルスクリプトを使うことで梃子の効果と移植性を高める
ソフトウェアの梃子（個人の力を増幅させること）を有効に活用するため、シェルスクリプトを使うのがいいというもの。
サーバー側を触る際、必ずシェルスクリプトを作成することになり、複数のコマンドを一つにまとめて実行するものであることは把握していたが、なぜこれを使用しているのだろうと疑問に思っていたので、長年何となく疑問に感じていたことが晴れていく感じがありました。
例えばある開発環境を立ち上げるとなった時に、一つ一つコマンドを打つとなると非常に面倒くさいことになります。この際に使用するコマンドを一つのシェルスクリプトを作成してまとめることで、この複雑な作業が解決することを考えると、シェルスクリプトの登場は非常に革命的なことだなと思いました。
最後に
サーバーについての理解を深めるつもりで読んでいたのですが、UNIXやサーバーへの理解という部分を越えて、エンジニアとしてどのようにシステムや開発と向き合うべきかということまで改めて考え直す良いきっかけになりました。
情報が古くなっている部分は多々あるのですが、エンジニアとして一度は触れるべき本かなと思います。