また雑に考えてしまった。最近はこういった事に意識を持っていかれる事が多くて少し困る。せっかくなので文章にしておく。ただし、まとまってはいない。
ドメインに入り込むような内容の事について、きちんと考える事できなくなってきた。以前はそうでもなかったのか、意識した事はなかったけれど。業務上の何かを表わす独自のオブジェクトを定義して、固有のメソッドを定義するという事を以前は良くやっていたと思う。業務上にそういう概念があるのだから、そのものを表わすオブジェクトがあるはずだと思っていた。
でも最近はそういうものを、できるだけ排除しようとしている気がする。抽象化を極力せず、共通化を極力せず、分岐をプログラミングテクニックのような方法で減らさない。そういう場合は愚直に分岐する。なんだかあまり "優秀" な人がやるような方法ではないけれど、不確定な要素が減るという意味では初見でのソフトウェアでの理解度は向上する。あとそうした実装は、抽象化への余力をソフトウェアが成長した後に押し付ける事ができる。これは結構大事だと思っている。そもそも的を射た抽象化はとても難しい。ある瞬間に的を射た抽象化だったとしても、ソフトウェアが成長すると的を外してしまうという事はよくある。また的を射た抽象化は常に品質向上や開発速度向上には繋がらない。むしろ、デバッグのしにくさや、テストのしにくさで足を引っぱる事もある。
テストについてはユニットテスト(単体テスト)が全てのように論じられる事があるように思う。ただテストはユニットテストだけじゃない。私はPythonをよく書くけれど、unittestよりもdoctestの方が優れている所もあるし、doctestよりもドキュメントをちゃんと書く方が意味がある事もある。それはテストじゃないだろうと思うかもしれないけれど、その文書を読んで、動作をちょっと触ってみるといった何気ない行為はテストだと思う。そういった人間らしい当たり前の行為を無視して既存の仕組みを強制する所について良いとは思わない。
そこにあるdoctestを、闇雲にunittestのスタイルに書き直してないか、目の前にあるコードを実行する時、そのコードをコピー&ペーストして素のインタプリタに読み込ませ実行できるか、自動テストを強制するあまり開発速度を低下させていないか、テストを実装し動作確認し最後にコードレビューをするような愚策を実施していないか、本番環境やステージング環境と人(開発や営業やCSの担当者)の距離が遠くなっていないか、デプロイに3分以上かかるような事になっていないか、本当によく考えたい。人をモノのように扱っていないか、ちゃんと話をしているか、一方的な情報伝達になっていないか、自己満足になっていないか、本当によく考えたい。