TPOP - UNIX思想 3.37〜 (WIP)

UNIX思想

UNIX設計思想の正しさ

  • UNIXは1969年に生まれて現在まで使われている。設計思想の正しさは長い実績が保証している。

モジュール化の原則

モジュールは自己完結させる

  • 理由
    • 問題の発生箇所がモジュール内に局所化できる。
  • 方法
    • 関連性の高いもののみを集める。
    • 極限までシンプルなインターフェースにする。

明確性の原則

人間にとって明確なコードはめったに壊れない

  • 複雑なコードは障害の発生箇所となる。

コードはマシンのためではなく、保守する人のために書く。

  • 保守作業は新規開発より高いコストがかかる。

- コードを解読する作業が高々1度で済むように留める。

  • 2度目の解読が発生した場合、3度目の解読を引き起こさないように改善をする。

組立部品の原則

ソフトウェアをテキスト形式のデータストリームのフィルタリングとして捉える

  • 入力と出力を意識し、ソフトウェアはどんな加工を行うか。
  • テキストストリームは、ソフトウェアを強制的に情報隠蔽する
  • 凝ったプロセス間通信は、互いに内部構造を曝け出してしまう。

入出力をテキストストリーム

  • コマンドラインから使用できる
  • 複数のソフトウェアを組み合わせて使用できる

分離の原則

メカニズムからポリシーを離す

  • ポリシーはソフトウェアの提供する機能に依存する部分。メカニズムは完結するような実装。メカニズムの例として、名前の付いたアルゴリズムの実装やエンジンなどがあたる。
  • ポリシーはソフトウェアの要件が変わることで、変更が必要になる。ポリシーとメカニズムの区別がついていないと、メカニズムに変更の必要が生じてしまうので、分離が必要。
  • ポリシーはフロントエンドやインターフェースがあたる。

単純性の原則

コードはシンプルにする

  • 技術誇示が複雑度をあげる。
  • 機能が外部から要求されることで、ソフトウェアが満たすべき本質的な要件が認められなくなる。
  • 図やドキュメントで、猿でもわかる設計思想と哲学を記述することが必要。

倹約の原則

大きなコードは書かない

  • はじめに小さなコードを書く。
  • コードを継ぎ足して大きくなったら分割する。判断基準は？１つのファイルにたくさんのコードが書いてあれば、それがそのまま悪というわけではない。SRPにもとづいて2つ以上の変更があるかどうかを基準にしてコードを分割したほうが良い。同じドメインでも、異なる2つ以上のコンポーネントが含まれていれば、分割を考えてもよい。

透明性の原則

透明性

  • ソフトウェアが外から見て何をどうするかが一瞬にして理解できるものである

開示性

  • 内部状態の監視が可能
  • 設計の初期から機能として組み込む
    • ログをやたらめったら表示するのは、コードが汚くなる
    • 変数の状態をString化するメソッドを作る

安定性の原則

コードレビュー

  • コードを書いたプログラマが内部構造を正しく説明できるようにする

特異な入力や極端に大きい入力に耐える

表現性の原則

情報はデータに寄せる

  • データ構造とロジックのどちらがか複雑になるのであれば、データ構造を複雑にする

驚き最小の原則

  • 想定通りのインターフェースにする
  • 一見似ているが微妙に異なる物を作らない
    • すでにある機能と似た名前で役割が微妙に異なるなら、命名を変える。