TL;DR
- コードの重複と柔軟性は、言うほど対立しない。どちらもシンプルに保つことが根本にある。
- 最初から重複を排除しようとするとかえって複雑になる。レイヤの責務を決めて守れば、重複に気づきやすくなる。
内容
プログラミングにおけるより良い選択とは の 1 つ目のテーマ。
コードの重複（渋川さん）
最初から重複を排除しようとすると、かえって複雑になる。3 回までは繰り返してよい（DRY）。テストのときに接続先をオンメモリのミドルウェアに切り替えるなど、柔軟性は確保したい。ただし、抽象化のレイヤでアプリケーションを作り込まない。
非プログラマの企画担当や現場のユーザが、開発者を介さずに動きを変えたいという需要があるなら、データ駆動にする。ゲーム開発ではこの形が多い。
共通化したものは、先手を打って他のメンバにコミットしていく。共通化はなるべく早く行い、共通化やレイヤを取りまとめる責任者がいるとよい。
コードの柔軟性（松岡さん）
レイヤの責務を決めて、それに従う。渋川さんは、責務はフレームワークに任せるという立場で、大規模なシステムではデータベース（SQL）に処理を寄せることもある。システムの規模によって責務は変わり、松岡さんによると言語やフレームワークによっても変わる。
レイヤの責務を守れると、自然に高凝集・低結合になりやすく、保守性が高まりやすい。記述の重複はよいこともあるが、同じ責務のコードが重複するのはよくない。クリーンアーキテクチャは複雑なので、松岡さんはオニオンアーキテクチャくらい軽いほうが好きだという。
意図しない重複の検知
松岡さんのチームでは、自動検知はあまりしていない。レイヤを分割して重複に気づきやすくし、リファクタリングでなくしていく。
渋川さんは、意図しない重複を必ず潰す必要があるのかと問う。意図しない重複は複雑なので、テストのためにまとめる動機があるならよい。ただ、重要ではないコードはそのままでもよいのではないか。重複をなくすこともトレードオフである。