これは個人的なTIPSとして、プログラムを書くときに、詳細設計がきちんとできていて、将来に渡ってメンテナンスしやすいかどうかの判断基準として、気を付けていることのメモ。
二つあって、どちらも同じような目的のために確認している。
１つ目は、後からテストコードを書く場合は、テストコードがどのように実行できるかを想像しながら実装する。すると、テストしたい部分を自然に切り離しながら実装したくなる。自動的にテストしにくい部分がどんどん一か所にまとめられていって、結果として後からいろいろ変更したり、機能追加がしやすくなる。
２つ目は、今追加しようとしている機能をOFFにしようとしたとき、どれくらいの場所を修正しなくてはいけないかを考える。１行コメントアウトするだけでそれができるのがベスト。できなくても、１ファイルの１ブロック（画面内で確認できる範囲）を修正すれば機能をOFFにできればまあ、問題ないレベル。
１ファイルの複数個所、という場合には、まず設計を見直す。OSの仕組みなどにより、どうしてもそうせざる負えない場合には、よくコメントを書いておくなりドキュメントしておくなりしないといけない。
複数ファイルを直さなきゃいけない場合は、１度よく設計を考え直した方がいいかもしれない。もうそれしか方法がないときだけ、コメントを付けて、どことどこに対応関係があるかを書いておく。
複数ファイルの複数個所を直さないと機能をOFFにできないとか、こういう状況になったら、そもそも何かがおかしいと思った方がいい。だいたい１つのファイルに複数の機能が同時に実装されていたり、２つのファイル（モジュール）が互いに依存しあっていたり、機能の定義があいまいだったりするのが原因で、その後その上にいろいろ機能を追加していけばしていくほど、バグは多くなる。
