あなたは、アーキテクトとして全体の基調を設定します。あなたはシステム全体を把握したはずですし、それに基づいてシステムを端から端まで縦にスライスしたような形で、チームが参考にすべきサンプルを書いているはずです。今まで何度もコピーされているサンプルのことです。数行のコードであれ、XMLファイルであれ、クラスであれ、デベロッパーが何かをコピーするたびに、それはもっと単純化できるか抽象化できる何かが残っているということを示しています。多くの場合、コピーされているのは、ドメインロジックではありません。システムを動かすためにそこになくてはならないインフラコードです。このような理由から、あなたが自分のサンプルの効果を頭に思い描けているかどうかがとても重要な意味を持ちます。あなたのサンプルに含まれているコードやコンフィギュレーションは、その10倍、100倍、1000倍のスライスの基礎となりますから、あなたのコードはクリーンで、意図がはっきりとわかって、抽象化できないもの以外含まれていないようなものでなければなりません。ドメインの問題に対応するコードだけということです。あなたがアーキテクトとして書くコードは、(皮肉にも)繰り返し使われますので、反復的なパターンには特に注意しなければならないのです。あなたのシステムでは反復的なパターンが現れているのではないでしょうか。コンフィギュレーションファイルを見てみましょう。システムの他の部分に適用したときに異なっていなければならないところはどこで、同じままになるのはどこでしょうか。典型的なビジネスレイヤーメソッドを見てみましょう。他のメソッドにも出てきそうなパターン、つまり、トランザクション処理やログ、認証、監査のためのコードが含まれていませんか。データアクセスレイヤーはどうでしょうか。エンティティやフィールドの名前以外同じになるようなコードはありませんか。広い視野から見てみましょう。いっしょに固まっている2、3行のコードがあって、他のオブジェクトを操作しているのに、同じことをしているような感じがすることはありませんか。それはすべて反復の例です。コードの重複とは、デベロッパーたちが違いのある大切な部分を見分ける方法を覚えたら、頭の中でフィルタリングして無視できるようになる部分ですが、デベロッパーたちがそれに慣れたとしても、作業を遅らせることに変わりはありません。そのようなコードは、コンピューターが実行しやすいように書かれているのであって、デベロッパーにとって読みやすいようには書かれていません。そのような部分を取り除くのは、あなたの仕事です。そのためには、フレームワークを活用したり、より良い抽象を作ったり、ツール担当に頼んでアスペクト・フレームワークをセットアップしたり、小さなコードジェネレーターを書いたりしなければならなくなるかもしれません。誰かが何かをしなければ、重複は消えません。その誰かとはあなたなのです。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。