🖨️
コピペがフロントエンドの未来かもしれない — Cohesive Programmingの台頭

2025/03/25に公開
「コードを分離せよ」— これが絶対の教えでした。データ層とビュー層を分け、ロジックとUIを切り離し、スタイルとマークアップは別々に管理する。しかし最近のフロントエンド開発のトレンドを見ていると、まったく逆の方向に進んでいます。

 Cohesive Programming私は2025年3月の今、この新しいトレンドを「Cohesive Programming」と呼んでみることにしました。関連する要素を一箇所に凝縮するスタイル、という意味合いで、従来の「関心の分離」と対比するものです。
データ取得、UI、ロジック、スタイリング — 従来はこれらを別々の層に分けていました。HTML と CSS、MVC、なんでもいいですが、私たち経験のあるエンジニアは誰もが「レイヤー」やその境界面を磨き上げることに熱心でした。
Cohesive Programming では機能的に関連する要素を同じ場所に置きます。そうすると、コンポーネントは外部に頼らず、それだけで完結するようになります。
この考えは少しずつ頭の中で整理されてきました。2014年からウェブとモバイルアプリの開発をしていて、jQuery の全盛期から React への移行で苦労しました。その中で「きれいなコード」と「実際に役立つコード」の間には思った以上の隔たりがあると気づきました。

 「クリーンコード」の限界長い間、私はコードの分離を強く信じていました。クリーンアーキテクチャ、DRY 原則、SOLID に熱中し、MVC、MVVM、FLUX の研究にのめり込みました。若手エンジニアに「ビュー層にデータ取得を入れちゃダメだよ」と教え、きれいに分かれた層の間を矢印でつないだ美しい図を描いていました。
そして、様々な技術レベルのエンジニアが混じった忙しいプロジェクトに入りました。最初は理想のアーキテクチャを作りました。そして...
ほんの数週間で、その美しいアーキテクチャは壊れ始めました。あらゆるブランチというブランチはコンフリクトし、バックエンドの変更でフロントエンドが動かなくなり、みんな誰かの作業が終わるのを待っていました。私が MVC に慣れたエンジニアの Pull-Request に「MVVM なのでこのコードは ViewController ではなく ViewModel に移してください」とレビューを付けて差し戻しました。何度も。もしかすると、開発が進まない原因は開発者のコードではなく、「きれいな」アーキテクチャだったかもしれません。

 Fragment Colocation大きな開発組織では、大勢が同時に作業すると調整自体が大変になります。フロントエンドエンジニアの悩みはバックエンド API です。バックエンドエンジニアが REST API を作るまで待たないといけません。一方、バックエンドエンジニアは UI がどんなデータを必要とするのか分からず、フロントエンドエンジニアの指示を待っています。このコミュニケーションコストがとても高いです。
この問題のヒントの一つが GraphQL です。GraphQL は自己記述的で、フロントエンドエンジニアは必要なデータを取得するクエリを自分で書けます。どのデータが使えるのかが見えるので、バックエンドエンジニアに聞かなくても作業を進められます。
そして「Fragment Colocation」という考え方があります。React コンポーネントとデータ取得層を別々に管理せず、GraphQL の Fragment Colocation はコンポーネントのコード内に直接クエリを書きます。
function UserProfile() {
  const { data } = useQuery(gql`
    query {
      user {
        name
        avatar
        friendCount
      }
    }
  `)

  return <div>{/* ユーザーデータを表示 */}</div>
}
Colocation の基本は、関連する機能を同じ場所（同じファイルやフォルダ）に置くことです。こうすればコンポーネントが必要とする全てが近くにあり、開発者は複数のファイルを行ったり来たりせずに、一箇所でほとんどの作業ができます。
この方法なら、コンポーネントとデータの要件が同じ場所で定義されるので、コンポーネントが独立します。従来の分かれたデータ取得層と比べると、コンポーネント間の依存が少なくなり、複数の開発者が同時に作業しやすくなります。

 Cohesive Programming の広がりこのパターンは色々なところで見かけるようになりました：

 TanStack Query: 効率より開発のしやすさTanStack Query（旧React Query）はビューコンポーネント内に直接API URLを書けます。これは少し前までは避けるべきとされていました。
各コンポーネントが独自にAPIを呼び出し、ライブラリが裏で重複を省きます。開発者に「一見非効率に見えても、実際には最適化されるから気にせず書いていい」という自由を与えています。

 Tailwind CSS: コピペで使えるCSS以前はインラインスタイルを使う開発者は批判されていました。でも Tailwind CSS はその常識を覆しました：
<!-- これを書いたら数年前なら批判されていたでしょう -->
<button
  class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
>
  送信
</button>
この良さは、プロジェクト間でコンポーネントをコピペするだけで、そのまま動くこと。個別の CSS の仕組みを理解する必要がありません。

 shadcn/ui: 「ライブラリじゃない」発想shadcn/ui はさらに進んでいます。はっきりと「これはライブラリじゃない」と言い、コンポーネントのコードをそのままプロジェクトにコピーする方法を提案します。なぜか？どんなプロジェクトでも、結局はコンポーネントを自分好みにカスタマイズしたくなるからです。あなたのプロジェクトに必要な一つの prop を追加した Pull-Request がマージされるのを待つより、コードをコピーして自分で変えた方が早いです。

 分散開発の必然性この流れはどこから来ているのでしょうか。おそらく、アプリの規模拡大や、リモートワークの潮流があると見ています。アプリは今までになく大きくなっています。開発体制をスケールするためのリモートワークと世界中に散らばる開発チームの増加が、分散開発のニーズを生み出しています。
例えば、私が日本にいて、バックエンド開発者がサンフランシスコにいるとします。新しいAPIが必要になりました。理想的には、しっかり話し合って完璧なインターフェースを一緒に設計し実装します。
しかし12時間の時差があります。質問すれば丸一日遅れます。強烈なボトルネックです。

 Fat ViewController の再来か「Fat ViewController」がダメなパターンとされていたことを覚えています。今、それが形を変えて戻ってきています。
昔の「Fat ViewController」は読みにくい複雑なコードでした。手続き型スタイルのコードを理解するには、ある変数が別の場所でどう扱われているかなどを一つ一つ読み解く必要があるからです。今の凝集コンポーネントは宣言的で関数型です。React コンポーネントにはデータ取得、スタイリング、ビジネスロジックが含まれていますが、昔のような悪夢にはなりません。

 美しいコードから役立つコードへこれらのトレンドで私の考えは変わりました。昔はコードの美しさで評価していましたが、今は「大勢が同時に作業しても混乱しないか」で判断します。文脈非依存のコード、つまりコピペ耐性の高いコードが良いのです。
どんなに美しい抽象化層でも、それが開発の障害になるなら意味がありません。少し重複があっても使いやすく、チームが独立して作業できるコードの方が、実際のプロジェクトでは役立ちます。
"duplication is far cheaper than the wrong abstraction"
似たような話は、こちらの記事もどうぞ："合流・分岐パターンをやめよう"

 AIによる加速面白いのは、これらのトレンドがAIコードアシスタントの得意分野と一致していることです。GitHub Copilotのようなツールは、Tailwind CSSのクラスのようなコピペしやすいコードを生成するのが得意です。複雑なプロジェクト構造より、単体で動くコンポーネントを書く方が上手です。
人間のチームをスケールさせた技術は、エンジニアを標準化しました。そしてそっくりそのまま、AIに適用されます。

 モバイル開発ではどうかモバイル開発も同じ道を進むでしょうか？すぐには難しそうです。iOS と Android 開発は、まだ独自の垣根に守られています。
しかし SwiftUI と Jetpack Compose が宣言的 UI をモバイルに持ち込み、準備が整いつつあります。React Native はすでに LLM の得意領域です。ネイティブモバイル開発も2〜3年以内にこの流れに乗ると思います。
課題としては、TanStack Query に相当するデータフェッチのデファクトが存在しないことや、宣言的 UI の API が React ほどは安定していないこと、そのためコピペ耐性の高いコンポーネントが豊富でないことなどが挙げられます。

 これは望んだ未来かデザインパターンを学び、アプリケーションアーキテクチャを追求してきた私にとって、このトレンドには非常に抵抗感がありました。しかし、リードエンジニアがチームのボトルネックになる現象は、現実そのものです。
コピペコードが未来か？おそらくそうです。誰もが Tailwind CSS で作られた美しいダッシュボードをコピペしたいです。Claude が吐き出したコードを貼り付けて仕事を終わらせたいです。LLM のコンテキストウィンドウの問題はすぐには解決されそうにありませんが、コード生成の性能は上がり続けています。

 単なるコピペとの違いしかし見落としてはいけないのは、単なる従来のコピペコードではないということです。「コピペ耐性の高いフレームワーク」 + 「コンポーネントを跨いだパフォーマンス最適化の仕組み」があって成り立っています。つまり、各個人の開発体験はデファクトスタンダードに従いつつも、アプリとしては一貫性のある、パフォーマンスの高いものになるということです。(TanStack Query の Request Deduplication や shadcn/ui のテーマの仕組みを参照して下さい)

 Cohesive Programming の考察従来のレイヤリングの概念を破り、関連するコードを近づけるパターンがチームの効率を上げることを見てきました。時には、コピペで済む開発パターンが最も現実的な解決策になります。理論的に完璧な設計より、狭いコンテキスト・少ないコミュニケーションで仕事が完了し、実際に動いて結果を出すコードを重視する。
フロントエンドの未来は完璧な分離ではなく、実際のチームが実際の製品を効率よく作れる現実的な設計にあるのではないでしょうか。
同じプログラミングパターンを見つけた方はぜひコメントで教えて下さい。
Discussion

ログインするとコメントできます