バグ論 - TrickDiary

細かい論説すっとばしてますが、いつまでもネタを寝かしたままにしておくのもよくないので、以下、要点だけでも・・・

数学的視点による見解
- 複雑な方程式はいとも簡単に解のない式となる。
  - 仕様のレベルで、複雑な要求に対しバグがない仕様は論理的に存在できなくなる。
  - プログラムも同様に、複雑な仕様に対しバグがないプログラムは論理的に存在できなくなる。
生物学的視点による見解
- 生物(生体)は複雑さに対して「大小様々な問題があろうが致命的な問題がないように」というアプローチでこの問題を克服している。
- これらを踏まえたバグとのつきあい方
  - どんなに科学が進歩しようが「絶対に間違った判断をしないAI」などというものは論理的に無理。
  - 可能な限り簡略化を試みる。
  - 生物(生体)と同じアプローチを採用する。
    - バグがあってもそれを隠蔽する方向で実装する。
      - デバッグ版では逆に assert() などで可能な限りバグを検出する。
    - 開発全体においてテストに注力する。
      - 仕様や工程などに対するテスト(リビュー等)も。
      - 直さなくていいからとにかくバグをより多く検出し記録する。
        
        致命的なバグがあって且つそれを直さないままでも、バグがあると分かっていればまだ対処のしようもある。

次の順番で注力することで、開発効率の最大化が可能になると思われる。( バグにフォーカスした視点においての話 )
- [最優先]簡略化>>>バグを作らないインプリメンテーション>>>テスト(特に自動テストによるバグの早期発見)>>デバッグ[優先度低]
効率の最大化という観点から考えるとバグがひとつもあってもはならないとするのはナンセンス。

以上は中規模以上のプログラムを前提の話とした話であって、小規模なプログラムあるいは小さなモジュール単位であればエントロピーに勝てないなんてことはないし、バグがひとつもあってもはならないとすることが効率の最大化にもなり得ます。