読書要点「プリンシプルオブプログラミング」第3章 UNIX思想

UNIX思想

UNIXを扱う文化の中で育まれた、経験的で実践的な技の集合。
公式の方法論ではないが、暗黙の知識として伝承されてきたものを明文化したものである。

末永くユーザーに利用され続けてきたUNIXは、ソフトウェアとしては段違いの生命力がある。
ソフトウェア開発において、プロダクトの寿命が長く使われ続けることは重要な要素であり、UNIXの積み上げてきた歴史から学べることは多い。
UNIXの設計のエッセンスを日頃のソフトウェア開発に活かしていきたい。

モジュール化の原則

シンプルなインターフェースで結びつけたモジュールを作成するのが良い。
ソフトウェアの複雑度をモジュールによって分解していく。
このとき、モジュールの入り口を狭くしておくことで、シンプルで閉じたモジュールにしやすい。

明確性の原則

コードは明確に書くようにする。
コードはコンピュータを相手にするのではなく、保守をするプログラマを相手にすべきである。
そのためにも意図がはっきりと伝わる明確なコードを書くのが良い。

組み立て部品の原則

ソフトウェアは、受け付けたデータを整形して別のデータとして出力するフィルターとしてつくるのが良い。
データの流れがシンプルだと、他のアプリケーションとの相互接続が簡単なうえ、無駄な表現が混じらないため情報隠蔽にもつながる。
シンプルなインターフェースで実装すれば複数のソフトウェアでの相互接続も実現しやすい。

分離の原則

ソフトウェアの前提に依存している部分がポリシー、依存していない部分がメカニズムだが、これらを切り分けて管理するのが良い。
メカニズムはできるだけ手を付けないことが望ましく、ポリシーは柔軟に変更できたほうが良い。
分離を行うことで、メカニズム部分のテスト容易性や再利用性があがったり、メカニズムと独立して新しいポリシーを試すことができるようになる。

単純性の原則

設計の段階からコードが単純になるように務める必要がある。
コードは意識せずに書いていくと自然と複雑になってしまう。
シンプルを是としたコーディングを心がけたい。
複雑なコードを書きたくなる気持ちや大量の機能追加に抵抗していく必要がある。

倹約の原則

大きなコードは書かないほうが良い。
大きなコードとは、コードの記述の量が大きい、または複雑度が大きいコードである。
大きなコードは制御が困難である。
小さなコードを書くように心がけるのはもちろん、制御できる大きさのうちに分割していくことで未然にコードが破綻することを防げる。

透明性の原則

ソフトウェアの動作を、外からわかりやすく見えるように設計するのがよい。
そのために、透明性と開示性から設計を考慮する。
透明性は、ソフトウェアの動作を見ることで何がどうなっているのかがわかりやすいかということである。
開示性は、ソフトウェアの内部がどうなっているか、確認、表示できるかということである。

透明性が良いソフトウェアはデバッグにかかるコストを抑えられる。
デバッグはコストのかかる工程であり、デバッグのための機能を盛り込んでおくことは十分リターンのある投資だと言える。

安定性の原則

ソフトウェアは安定であったほうが良い。
予想外の条件でも適切に動作するものを作る必要があるが、このためには分岐などコードの複雑度をあげる作業が必要になる。
あまりに複雑度があがると一の手に負えなくなるため、内部構造を簡潔に説明できるコードを書く必要がある。
コードから何をしているか読み取れるかという透明性、コードが複雑ではなく説明が容易かという単純性を満たすコードを書きたい。

コードレビューや負荷テストを行い、ソフトウェアの透明性や単純性、堅牢性を確認するのが良い。

表現性の原則

コードにおける情報表現はデータとロジックがあるが、基本的にデータに寄せて書くようにしたい。
データのほうが理解しやすいため、複雑なものを作るときはまずデータの表現を基準に考えるのが良い。
避けられない複雑さはできるだけデータ構造側に押し付けたほうがわかりやすくなる。

驚き最小の原則

インターフェースは機能に対して過不足のないものを提供する。
奇抜なUIは学習コストが高く、ユーザーに対して使用上のハードルを上げてしまう。

既知のUIや伝統を意識しつつ、過不足のないユーザー目線のUIを目指したい。

沈黙の原則

ソフトウェアの表示は最小限に抑えるのが良い。
必要がなければ情報を表示する必要はないし、必要なものは最低限の表示で抑える。
透明性の原則に基づきメッセージの表示を行いたいときは、スイッチを作り表示するかどうかを選択させると良い。

修復の原則

エラーの回復に失敗した時は処理は中断するのが良い。
回復できた場合はそのまま処理を継続すればよいが、そうでない場合は取り返しのつかないことになる前に処理を中断する。

経済性の原則

プログラマの時間を節約するための整備を行いたい。
ハードウェア、ソフトウェア面での制約、環境やルールの制約はプログラマの時間を浪費することにつながる。
貴重で高価なリソースであるプログラマに投資することで、プログラマの開発効率やモチベーションの向上につながり、生産性や品質がよくなる。

生成の原則

コードを生成するためのコードを書くのが良い。
コンパイラ技術に代表されるように、コンピュータが生み出すコードは人の手で書かれたものよりも素早く、品質が良い。
コードを書く上でも、コンピュータに任せられるところを増やすことで作業の効率化、品質の向上につながる。

最適化の原則

最適化を行う際は、まず確実に動作する正しいコードを作った上でパフォーマンスの最適化に務めるべきである。
動作保証されていないコードに対する最適化は複雑性を増すだけでなく大きなリターンも得られにくい。
遅くても、シンプルで確実に動作するコードに最適化を行いたい。

多様性の原則

プログラミングにおいては唯一の正しい方法がなく、多様性があることを認識する。
この認識の上でより良い選択肢を模索し続ける姿勢が肝要である

拡張性の原則

開発の上で唯一の正しい方法がないソフトウェアに対して、拡張できる設計にしておくことが望ましい。
多様性の原則に基づけば、ソフトウェアの保守や改善の作業は必須で、その際にソフトウェアの拡張性は役立つ。
外部との接続性が良いソフトウェアを設計するべきだが、余分な機能を追加するための免罪符ではないことを注意したい。