複雑さと前提条件が増えすぎるとメンテナンス不能になる。

　関数の引数が増えていったり、その関数の前提条件が増えすぎると、メンテナンスが不能になる。
　複雑になりすぎてしまった関数を移植すると期待した動作をしなくなってしまう。だから、機能を詰め込みすぎないことです。不幸にして既に複雑になりすぎた関数を引継いだときには、その複雑さを減らしていきましょう。
　期待する動作をしなくなってしまったときには、成功するはずのデータを用意し、どの段階で期待した結果と乖離するのかを確かめていくことです。関数の引数が多ければ多いほど、関数を正常に動作させるのが難しくなります。引数が増えていけばいくほど、引数の組み合わせで矛盾を生じやすくなります。

　そのあたりの事情は、Unixでシェルスクリプトを書く際にも出てくるようです。シンプルだったUnixは他国語対応によって環境変数によって動作が変わってしまった。lsやdateコマンドの出力がロケールによって変わってしまったので、以前だったらそのまま動いたスクリプトでももはや動かなくなってしまう。複雑さが自分の手に負える範囲から逸脱してしまうとメンテナンス不能になってしまうのです。（１０数年前まではシェルスクリプトを書いていたが、もうずいぶん書いていない。）

どの環境でも使えるシェルスクリプトを書くためのメモ ver3.91

[UNIXという考え方 The UNIX philosophy]
(https://gist.github.com/koudaiii/82e4f8869705e5be065f)

　あると便利かもしれない機能を１つ余分に加えたとたんに、単純さをぶち壊し、移植性を悪くして、メンテナンスを不能に陥れることが可能だ。

cksumの互換性のない"改良版"が作られたことによる問題は、cksumの利用を不可能にする状況を引き起こした。カーニハンの著書にそのことが書いてあった。

複雑さと前提条件が増えすぎると、その機能をテストするためのデータの入手からして厄介な状況になってしまうのです。テストが実行できない環境ではなかなかコードの改変の勇気がもてなくなります。できるだけ、それぞれのライブラリに余分な機能を追加しないようにして、単体テストが出来る条件を取り戻していきましょう。単体テストが可能なインタフェースを取り出していくことで、品質の確保ができる状況に移行していきましょう。

追記(2023.08)：100倍複雑なシステムを僕たちは扱いきれない。

• 複雑さが増大したものを今までと同じやり方で処理しきれる人はいない。

• ファイル単位のバージョン管理システムであるRCS(ci, co コマンド)を今の状況で使いたい人はいますか？

• RCSでは、テキストファイルをファイル単位で履歴を管理するバージョン管理システムである。

• RCSの時代からgitの時代への変化

  • ファイル単位ではなく、リポジトリ単位の管理
  • テキストファイルだけではなく、バイナリファイルも管理できる。
  • ファイル名の変更への対応
  • スタンドアローンの利用からサーバーのあるネットワークへの対応
  • branchの管理とPR(Pull Request)の仕組み
  • Git LFS, DVC(Data Version Control) の利用

• こういった拡張が利用できることで、日々の生産性が向上している。

• つまり、RCSしか使えないままだったら、今の生産性は確保できない。

複雑性の高いシステムは、システム開発に問題を生じやすい

• 過去に問題が指摘されたシステム
• 例: ガラケーのソフトウェア開発
• 例: 某銀行のシステム（合併前の銀行のシステムのしがらみのために、複数のシステム業者が関わっているシステム）

プロジェクト・マネジャーが知るべき97のこと 複雑よりもシンプルな方がいい