【プリンシプルオブプログラミング】UNIX思想

 

目次

はじめに

この記事は「プリンシプルオブプログラミング」を読んで自分なりにまとめた学習メモです。 

思想 〜プログラミングのイデオロギー

UNIX思想

 UNIX思想とは、UNIX文化の中で育まれた、優れたプログラミングを行うための、経験に基づいた実践的な「技」の集合。

 

17個の原則

  • モジュール化の原則
  • 明確性の原則
  • 組み立て部品の原則
  • 分離の原則
  • 単純性の原則
  • 倹約の原則
  • 透明性の原則
  • 安定性の原則
  • 表現性の原則
  • 驚き最小の原則
  • 沈黙の原則
  • 修復の原則
  • 経済性の原則
  • 生成の原則
  • 最適化の原則
  • 多様性の原則
  • 拡張性の原則

 

モジュール化の原則

モジュールは、そのインタフェースを、余分なものはそぎ落とし、極限まで少なくする。

ソフトウェアは、シンプルなモジュールの集合体として構築する。

 

明確性の原則

人にわかりやすい、明確なコードを書くようにする。

 

組み立て部品の原則

テキストストリームを読み書きする、コマンドラインで使用できるソフトウェアを設計する。

 

分離の原則

安定的な部分と不安定な部分を明確に分けて管理する。

  • サービス系アプリケーション
    • 「ポリシー」:クライアントからの要求を受け付けるフロントエンド
    • 「メカニズム」:実際のサービスを行うバックエンド
  • エディタアプリケーション
    • 「ポリシー」:拡張可能なユーザーへのインタフェース
    • 「メカニズム」:エディタのエンジン

 

単純性の原則

もっとも単純で美しい」ことを誉めあう文化を構築する。

  • コードが膨れ上がり複雑化することを、きっぱりと拒否する
  • 逆に、単純な解決方法を互いに高く評価する
  • 大量の機能でソフトウェアを飾り立てることには、反射的に抵抗する
  • 逆に、連動しあう小さな部品に分割する方法を探す

 

倹約の原則

  • 小さなコードを書くようにする
  • 大きなコードは分割する
  • 分割に失敗した時に限り、大きなコードを残すようにする

 

透明性の原則

デバッグのための機能を、設計の最初の段階から組み込む。

 

安定性の原則

コードが「透明」「単純」であることを、常に保つようにする。

 

【行うべきこと】

  • コードレビュー
  • 特異な入力や極端に大きい入力に耐えられるような検証

 

表現性の原則

コード上の避けられない複雑さの部分は、データ側に寄せるようにする。

コードを改善していく時も、コードの複雑さをデータの複雑さに切り替えていくことを検討する。

 

驚き最小の原則

予想通りに動作するようなインタフェースを設計する。

 

【気を付けるべき点】

  • よく似たソフトウェアのインタフェースをモデルにする
  • 想定ユーザーの特徴を考慮する
  • 伝統に注意を払う
  • 「一見似ているが微妙に異なる」ということを避ける

 

沈黙の原則

表示出力を最小限に抑える

重要な情報のみ出力して、内部動作の情報を混在しないようにする。

 

【方針】

  • 本当のエラーだけを標準エラー出力に表示して、その他の要求されていないデータはいっさい出力しないようにする
  • デバッグの目的で、進行状況についてメッセージを表示したい場合は、冗長モードのスイッチを作り、デフォルトではそれを無効にしておく。

 

修復の原則

エラーが発生した場合には、できるだけ早い段階で、けたたましく通知するようにする。

ただし、ユーザーの誤った入力や、ソフトウェア自身の実行エラーは、まずは穏便に処理すべき。

それができない時、ただちに、できる限り簡単に障害を診断できるようなエラーを起こすようにする。

 

経済性の原則

  • 開発環境のためのハードウェアやソフトウェアに投資する。開発効率が上がり、ストレスは下がるので、生産性や品質が格段に向上する
  • ルールや制約は、施行後にバランスを調整する
  • いったん作るルールは叩き台として考え、運用後、プログラマの意見を聞くようにする
  • 開発に支障が出ているのであれば、「これだけは最低限譲れない」というところまで譲歩する

 

生成の原則

コードを生成するコード、つまり、コードジェネレータを適材適所で作成する。

特に、繰り返しが多く、定型的なコードは、コードジェネレータの対象とする。

 

最適化の原則

まず動かし、正しくしてから、速くする。

 

多様性の原則

よりよいやり方を求め続ける。

プログラミングに対して、「唯一の正しい方法がある」という喧伝については、きちんと「不信感」を持って接するようにする。

 

拡張性の原則

プラガブル(接続可能)になるように設計し、それを明示する。

機能を簡単に追加できるようなコードを書く。