ソフトウェアの作り方。1970年代からある答え。

私は現在メーカー系のSIerで働いている。最近ではCOBOLをJavaにする案件が増えている。そんな中、歳の頃なら50歳前後といった男性エンジニアが言った。「なぜ(既存のCOBOL製プログラムを)小さく分けなければならないの?」

その質問は純粋に「分からない」から聞いているようであった。明確には私も分からないが、「昔からそういうことになっているよなぁ」と心の中で思った。最近ではマイクロサービスアーキテクチャなるものが台頭してきたので、これを調べて勉強しようと思っていた。きっと関係があるので先にその「昔から」が何なのかを探すことにした。

目次

目次:

発見。UNIXという考え方:その設計思想と哲学(邦題)

掲題の書籍が見つかった。原題は「The UNIX Philosophy」Mike Gancarz著。

すでに24刷発行で1994年が初版のようだ。UNIX自体は1969年に誕生したようなので1970年代には既にこの「考え方」はUNIX界隈のソフトウェア開発の先駆者達の間では共通の考え方だったようである。

この書籍を勉強がてらまとめてみたいと思う。50歳になってから「なぜプログラムは小さく無いといけないの?」などと言わないためにも。

ソフトウェアはこう作る。

ありがたいことに9個の定理と10個の小定理に分類されている。読みやすい。

UNIXの考え方の定理:

  1. スモール・イズ・ ビューティフル
  2. 一つのプログラムには一つのことをうまくやらせる
  3. できるだけ早く試作する
  4. 効率より移植性を優先する
  5. 数値データはASCIIフラットファイルに保存する
  6. ソフトウェアを梃子として使う
  7. シェルスクリプトによって梃子の効果と移植性を高める
  8. 過度の対話的インターフェースを避ける
  9. 全てのプログラムをフィルタとして設計する

UNIX文化の小定理:

  1. このみに応じて自分で環境を調整できるようにする
  2. オペレーティングシステムのカーネルを小さく軽くする
  3. 小文字を使い、短く
  4. 森林を守る
  5. 沈黙は金
  6. 同時に考える
  7. 部分の総和は全体よりも大きい
  8. 90%の解を目指す
  9. 劣る方が優れている
  10. 階層的に考える

これだけある中で私に気づきを与えてくれたのはこれである。

定理9:全てのプログラムをフィルタとして設計する

「そういえばそうだよな。」それが感想。言われてみればその通り。プログラムはデータを入力として受け入れ、なんらかの形式のデータとして出力する。

GUIの具体例がわかりやすかった。マウスボタンのアクションやキーボードのストロークをイベントとして処理し、このイベントがデータストリーム形成しウィンドウシステムの管理下にあるアプリケーションへ入力として送られる。アプリケーションもフィルタとしてこのイベントに反応し、ディスプレイの表示を更新する。

プログラムはフィルタであるという考えで設計すると何かと良きソフトウェアが作れそうだ。それに新しい、初めて触る技術の理解がしやすいだろう。

他の定理も含めて俯瞰してみてみると、作り方には違いないが、より長いスパンでソフトウェア開発を捉えているようである。後からくる改修や移植、次の新しいソフトウェアでも使える資産とするため、もっといえばビジネスとして成り立たせるためにUNIXという考え方は、ソフトウェア開発において1つの答えのようである。

なぜ50代エンジニアには理解できなかったのか?

恐らく、70年代からこういった思想や方法論があったのにも関わらず、巨大な一塊のソフトウェア、システムが作られ続けたのは所謂、「コンウェイの法則」なのかもしれない。

彼らの組織であるメーカーが一塊の大きな構造体だ。この組織の欠陥がそのまま実装され続けたわけだ。彼もこういった組織の中でこれを疑わず、いつの間にか「当たり前」になっていったのかもしれない。

そもそも大きいということは構造体にとっての脆弱性なのではないか?

旧来のソフトウェア開発と今日の大企業の有り様から考えるに、どうも大きいこと自体が脆弱性なのでは無いかと思う。何しろ大きいものから先に破綻するように宇宙はできているらしい。先に完成した地球よりも後から完成した太陽の方が先にその寿命を終えるようである。

大きいものの弱点を考えてみると:

  1. エネルギー効率が悪い。
  2. 柔軟性がないので拡張に弱い。
  3. 柔軟性がないので修正に弱い。
  4. 一塊なので影響範囲が広く決定に時間的、経済的コストがかかる。
  5. 時間がかかるので適切な機会を失いやすい。
  6. 長続きしない。
  7. なんとかしようとするとゾンビのようなおかしな存在になる。
  8. なんとかしようとすると構成している1単位がグシャっとする。
  9. 後世にとっての負の遺産となる。
  10. カッコ悪い。

大きいものの良い点を考えてみると:

  1. 軌道に乗ると加速しやすい。

ただし、すでに7.8.の状態であればこの良い点も打ち消される。

よって大きい上に、古いものはその寿命を終えるのが「自然の摂理」なのである。

というわけで小さいことはいいことしかない。

小さい方良い理由の詳細は書籍に譲るとして、大きいことの弱さを考えてみた。自分の考え方や身の回りの物、生活習慣に至るまで「もっと小さくできないか?」みなおしたい。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次