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

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

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

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

UNIXという考え方 The UNIX philosophy

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

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

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