始めに
本記事では、UNIX思想について記載する。
尚、解説時には、以下の3つの形式に分けて解説する。
- what??
- why??
- how??
UNIX思想とは？？
what??
優れたプログラミングを行うための、経験に基づいた実践的な「技」の集合
以下17個の原則がある。
①モジュール化の原則
②明確性の減速
③組み立て部品の減速
④分離の原則
⑤単純石の原則
⑥倹約の法則
⑦安定性の原則
⑧表現性の原則
⑨驚き最小の原則
⑩沈黙の原則
⑪修復の原則
⑫経済性の原則
⑬生成の原則
⑮最適化の原則
⑯多様性の原則
⑰拡張性の原則
why??
UNIXの設計診断が正しいため。
how??
UNIX思想の各原則を、設計の指針とする。
①モジュールの原則
what??
コードの中で関係性の高い要素を集めて、モジュールを作成する原則のこと。
why??
問題を局所化し、全体を壊さずに、対象のモジュールだけを改良するため。
how??
モジュールの構成要素を、関係性の高いもののみを集めるようにする。
②明確性の原則
what??
コードは明確に書くようにするという原則。
why??
保守を行う人の可読性を上げるため。
how??
- 2度同じコードの解読が続いた場合は、対策を打つ。
- 明確でなければ改善する。
③組み立て部品の原則
what??
ソフトウェアは、できる限りシンプルなフィルタとして作る。
この際、データストリームの形式は、テキスト形式にするのが良い設計である。
フィルタ
フィルタとは、入力としてデータストリームを受付、加工し、別のデータストリームとして出力するソフトウェアのこと。
why??
他のソフトウェアと連携できないソフトウェアは価値がないため。
how??
複雑な形式はさけ、単純なテキストストリームのようなインターフェースを選択する。
④分離の原則
what??
メカニズムをポリシーから引き離すという原則。
メカニズム
- ソフトウェアの前提に依存しない独立した部分。
- コードの中では比較的安定。
ポリシー
- ソフトウェアの前提に依存する部分。
- コードの中では比較的不安定。
why??
繋ぐことで発生する2つの欠点を避けるため。
- ポリシーが硬直して、ユーザーの欲求に合わせたポリシーの変更がやりにくくなる。
- ポリシーを変更すると、メカニズムまで変更しなければならない。
引き離すと以下の3つのメリットが得られる。
- メカニズムを壊さずに、新しいポリシーを試すことができるようになる。
- メカニズムの有効なテストを書きやすくなる。
- 他のソフトウェアで再利用が可能になる。
how??
ソフトウェアの中で、安定的な部分と不安定な部分を明確に分けて管理する。
⑤単純性の原則
what??
コードをシンプルに設計するという原則。
複雑なコードの追加は必要最小限で行う。
why??
コードは自然状態で複雑になるため、意識的に単純化する必要がある。
how??
プログラマが、互いに「最も単純で美しい」ことを褒め合う文化を構築する。
⑥倹約の原則
what??
コード内部において複雑度が大きいコードを書かないという原則。
why??
保守時における可読性の向上のため。
how??
小さなコードを書き、大きくなった場合は、分割する。
⑦透明性の原則
what??
ソフトウェアの動作を、外からわかりやすく見えるように設計するという原則。
以下の2点を意識して設計を行う。
- 透明性
- 開示性
透明性
ソフトウェアの動作について、一眼見てすぐに「何をどうしているのか」が理解できること。
開示性
ソフトウェアの内部状態について、監視ないし表示できること。
why??
- デバッグや障害調査を簡単にするため。
- 連携のための単純なインターフェースを得やすくするため。
how??
デバッグのための機能を、設計の最初の段階から組み込む。
⑧安定性の原則
what??
「透明性」と「単純性」を活かすコードを書くことで、ソフトウェアを安定させるという原則
透明性
単純性
透明性
コードを見通すことができて、何が起きているのかすぐわかること。
単純性
コードで行われていることが複雑でなく、全ての分岐条件を難なく説明できること。
why??
* ソフトウェアのダウン・フリーズを防ぐ
* 安定性の保証・保持のため。
how??
コードが「透明化」・「単純化」であることを常に意識する。
そのために以下を行う。
- コードレビュー：コードを書いたプログラマが、コードの内部構造について正しく説明できるようにする。
- 得意な入力や極端に大きい入力に耐えられるような検証
コードレビュー
コードを書いたプログラマが、コードの内部構造について正しく説明できるようにする。
得意な入力や極端に大きい入力に耐えられるような検証
他のソフトウェアから与えら得られる入力を使用すると効果的にテストできる。
⑨表現性の原則
what??
情報はデータ側に固めるという原則。
why??
データ構造は複雑なものでも比較的簡単に理解できるが、ロジックはそうではないため。
how??
コードの避けられない複雑さの部分は、データ側に寄せるようにする。
⑩驚きの最小の原則
what??
インタフェースの設計は、使う人の意外に思う気持ちが最初になるように行うという原則。
why??
使い手の学習コストを低くするため。
how??
予想通りに動作するようなインタフェースを設計する。
そのために以下の点に気をつける。
* よく似たソフトウェアのインタフェースをモデルにする。
* 想定ユーザーの特徴を考慮する。
* 伝統に注意を払う。
* 「一見似ているが微妙に異なる」ということを避ける。
よく似たソフトウェアのインタフェースをモデルにする。
ユーザーがよく使っていて、機能がよく似たインタフェースを踏襲する。
想定ユーザーの特徴を考慮する。
エンドユーザーなのか、他のプログラマなのか、システム管理者なのか、ユーザーのタイプによって、驚きが小さいインタフェースは異なるため、想定ユーザーを考慮して設計する。
伝統に注意を払う
UNIXの世界には、「お馴染み」の習慣がある。
これらの習慣を学び、仕様の策定に活かす。
「一見似ているが微妙に異なる」ということを避ける
馴染みのあるものは既知のものにしておく。
⑪沈黙の原則
what??
ソフトウェアは、どうしても言わなければならない想定外のことがないのなら、「何も言わない」という原則。
why??
ユーザーが使用する注意力や集中力を、本当に必要な時のみにするため。
how??
表示出力を最小限に抑える。
方針として以下の2点を心がける。
- 本当のエラーだけを標準エラー出力に表示する
- デバッグの目的で、進行状況についてメッセージを表示したい場合は、冗長モードのスイッチを作り、デフォルトでは、それを無効にしておく。
⑫修復の原則
what??
修復失敗時は、処理を停止するようにする原則。
why??
エラー時に、修復が成功していないにも関わらず処理を継続してしまうと、被害が拡大してしまうため。
how??
エラー通知をけたたましく通知させる。
⑬経済性の原則
what??
プログラマの時間を大切にするための原則。
以下の問題がプログラマの時間を浪費する。
- ハードウェアが貧弱。
- 使用するソフトに対する制限。
- 環境に関するルールや制限。
ハードウェアが貧弱
- 記録ディスクが不足すると、圧縮や別メディアへの移動など、やりくりに多くの時間を取られる。
- CPUの性能が不足すると、コンパイルや実行に時間がかかり、待ち時間が多くなる。
- メモリが不足すると、同時に実行できるソフトウェアが少なくなり、開発効率が下がる。
- モニタが小さいと、いちいちウインドウの切り替えが発生し、作業がとても非効率になる。
使用するソフトに対する制限
必要なソフトウェアが購入できないと、工夫をして同じことをする必要があり、時間を浪費してしまう。
環境に関するルールや制限
インターネットにおいて開発に必要なサイトなのにアクセスできないといった場合、必要なものを利用できず、時間を浪費してしまう。
why??
プログラマの時間は貴重であり、設備に投資することで、仕事が効率的にできるようになれば、ペイできるため。
how??
プログラマの効率的な仕事のために、開発環境のためのハードウェアやソフトウェアに投資をする。
⑭生成の原則
what??
コードを生成するためのコードを書くという原則。
why??
プログラマが手で書いたコードよりも、生成されたコードの方が、常に「安上がり」で「高品質」であるため。
how??
コードを生成するコードを適材適所で作る。
⑮最適化の原則
what??
コードを最適化する前に、正しく動作するコードを書くという原則
why??
正しく動作する前に最適化に走ることは、以下の問題を発生させる。
- 透明性や単純性が犠牲になる。
- 部分に対する半端な最適化が、全体の最適化の妨げになる。
how??
まず動かし、正しくしてから、早くする。
⑯多様性の原則
what??
ソフトウェアにおける選択の多様性を受容するという原則。
why??
人の想像力には限りがあり、唯一の正しい方法は提示できないため。
how??
より良いやり方を模索し続ける。
⑰拡張性の原則
what??
ソフトウェアにおいて、唯一正しい方法はあり得ないため、コードには成長の余地を残しておくべきとする原則。
why??
ソフトウェアが役に立ち続けるため。
あらかじめ拡張性を考慮していないと、ソフトウェアが成長していくことができない。
how??
ソフトウェアが持続可能(プラガブル)になるように設計し、それを明示する。
ただし、必要としていない機能を追加するための免罪符にしないよう注意。