「TDDは設計の方法論ではない」という投稿を見て作成した文章です。

TDDをしたことはないが、１年間、熱心に単体テストを追加し、レガシーコードをテスト可能にリファクタリングする中で感じた点と似ている。

まとめてみると

  1. テスト可能なコードは密結合を回避し、依存性逆転の原則は守るようにしてくれる。
  2. 単一責任の原則とインターフェース分離の原則は、個別に確認する必要がある。

昨年はコードをテスト可能にする作業から始めた。RIBsは、基本構造があまりにも細かく分離されており、各要素が単一責任原則を守っているので、それに合わせてコードを作成するだけで重要ロジックのテストはある程度可能である。MVCを除くほとんどのアーキテクチャは似ている。そのため、モバイル開発環境では、アーキテクチャの影響がないその他15-20％程度のコードに限って、開発者の設計能力が重要だと思う。

ところが、その15-20％のコードが非常に重要だ。アプリのデザインや機能と同様に、コードもテンプレート化され、簡単にコピーされ広がります。ある程度コードベースが積み重ねば、まったく新しい設計をすることはほとんどなく、既存にある同様の機能をするコードを探して使うことになる。そして、ほとんどの人は既存のコードを簡単にコピペして持っていく。

誤って設計された共通モジュールがそれに依存している数十個のモジュールと数十人の開発者に悪い影響を与えるのを見たこともあり、誰かが取り込んだ設計ミスの構造が徐々に広がっていくことを目撃したこともある。不要な依存性が付いてきたせいでインターフェース分離の原則も守らなくなり、ビルド時間も増えてしまう。また、誰かが作ったテスト不可能な構造が、他の開発者が特に考えずにそのまま使ったせいで、増殖することもある。コードが悪くなるだけでなく、意味のないコードレビュー作業が強制され、レビューを受けたい人、レビューすべき人の時間を無駄にした。

そのため、共通モジュールを作成したり、新しい構造を導入する時は、今後このコードが長く残って影響を与えることを考慮して、特に責任を持って設計しなければならない。Googleはコードレビューの大原則でこのように述べている。「開発者は引き受けたことを果たしながらもコード品質を改善しなければならない。着実に改善しなければ、品質は絶対に良くならない。