前言

介绍了 “内聚编程”（Cohesive Programming）的概念，并探讨了这种新兴趋势如何可能成为前端开发的未来，即使它可能与传统的 “关注分离”（Separation of Concerns）原则相冲突。今日文章由 @ryoheyc 分享，前端早读课@飘飘翻译。

“代码分离”—— 多年来，这一直是开发的基本原则。将数据层与视图层分离。将逻辑与用户界面分离。将样式与结构分离。然而，观察最近的前端开发趋势，我们却朝着完全相反的方向发展。这是怎么回事？

什么是内聚编程？

我把这种新趋势称为 “内聚编程”（Cohesive Programming）。与传统的 “关注点分离”（Separation of Concerns） 相反，这种方法强调通过将相关元素集中在一起，提高代码的内聚性。

过去，我们习惯于将数据获取、UI、逻辑和样式分层管理，而 凝聚式编程从物理上将功能相关的元素更紧密地结合在一起。因此，组件变得自给自足，对外部依赖更少。

这个想法并不是一蹴而就的，而是我在多年开发经验中逐渐形成的。我从 2014 年 开始从事 Web 和移动应用开发，亲历了从 jQuery 黄金时代 过渡到 React 时代 的痛苦历程。在此过程中，我意识到 “简洁设计” 与 “实用设计” 之间往往存在着巨大的差距。

“整洁代码” 的局限性

多年来，我一直坚定地支持 关注点分离，推崇 Clean Architecture（清晰架构）、DRY（不要重复自己） 原则以及 SOLID（面向对象设计原则）。我曾经不厌其烦地向初级工程师强调：“你不应该在视图层里写数据请求代码！” 我还会画出整齐划一的架构图，展示不同层次间如何优雅地交互。

然而，后来我参与了一个高压项目，团队成员技术水平参差不齐。我 先是 设计了一个完美的架构，结果……

几周后，我精心设计的架构就崩溃了。

开发人员相互掣肘，后端的变更导致前端代码频频出错，每个人都在等待别人完成某些工作。问题并不在于代码写得 “糟糕”，而在于 “干净” 的架构需要过多的协调，反而降低了开发效率。

片段共置（Fragment Colocation）

在大型开发组织中，当许多开发人员同时工作时，协调会成为一个重大挑战。对前端工程师来说，后端 API 是一个重要的阻碍。他们往往需要等待后端工程师创建 REST API。与此同时，后端工程师也在等待前端工程师，因为他们不知道用户界面需要什么数据。这种沟通成本极高。

GraphQL 提供了一种解决思路。GraphQL 允许前端工程师自己编写查询语句，直接获取所需数据，而不必等待后端工程师提供接口。这样一来，前端开发可以更自主地推进，而不用来回沟通 API 细节。

在 GraphQL 中，有一个概念叫 “片段共置”（Fragment Colocation），它进一步优化了前端开发方式。传统上，React 组件和数据获取层是分开的，但片段共置的方式让 GraphQL 查询语句直接写在组件源码里，例如：

functionUserProfile(){
   const{ data }=useQuery(gql`
     query {
       user {
         name
         avatar
         friendCount
       }
     }
   `)

   return<div>{/* 显示用户数据 */}</div>
}

代码共置的基本理念是将相关的功能实现物理上放置得彼此靠近（在同一个文件或目录中）。这意味着组件所需的一切都在附近，开发人员可以在一个地方完成大部分工作，而无需在多个文件或模块之间跳转。

通过这种方法，组件变得自给自足，因为数据需求和 UI 逻辑都定义在同一个地方。相比传统的数据分层架构，这种方式减少了组件之间的依赖，使多个开发人员可以更高效地并行工作。

凝聚式编程的传播

这种凝聚式模式如今在很多地方都能看到：

TanStack Query：拥抱 “惰性” 代码

TanStack Query（前身为 React Query）允许开发者直接在组件中写 API URL。而在几年前，这还是被认为是不好的实践！

每个组件都自行发出 API 调用，而库会神奇地去重这些调用。这就好比在告诉开发者：“尽管放心地编写看似低效的代码吧，我们会让它运行得很好的。”

这种趋势表明，前端开发正在从 “严格的架构分离” 走向 “更灵活、更实用的代码组织方式”，也就是凝聚式编程的核心理念。

Tailwind CSS：可复制粘贴的 CSS 模板

还记得我们过去嘲笑那些使用内联样式的 “糟糕开发者” 吗？但现在，Tailwind CSS 直接把这种做法变成了一个流行的框架：

<!-- 如果是 2015 年，这种代码可能会让你被炒鱿鱼 -->
<button
   class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
>
   Submit
</button>

Tailwind CSS 的卖点是什么？ 你可以在不同项目之间复制粘贴组件，它们就能直接运行，而不必去理解某个项目特定的 CSS 结构。

shadcn/ui：“不是库” 的库

shadcn/ui 进一步推动了这种趋势。 它明确声明自己 “不是一个库”，而是鼓励开发者直接把组件源码复制到项目里。

为什么？因为几乎所有项目都会需要自定义组件，而与其等待官方库添加某个定制化属性，不如直接复制代码，自己修改。这种方式减少了依赖，提高了开发效率。

分布式开发的必然性

这些趋势的出现并不是偶然的，它们与远程工作和全球开发团队的崛起息息相关。

想象一下，你在旧金山，而你的后端开发同事在班加罗尔。你需要一个新的 API 端点。

传统模式下，你们会：

• 仔细协调 API 设计
• 共同制定完美的接口
• 然后分别进行实现

现实世界里呢？

你们有 12 小时的时差，每次提问都会导致一天的延迟。

这正是为什么越来越多的公司开始采用 “微服务架构”，以减少团队之间的依赖，让各自的工作更独立、更高效。

臃肿的视图控制器：堕落者的复仇

还记得 “臃肿的视图控制器” 曾是终极反模式吗？它又卷土重来了 —— 但这次有所不同。

旧的 “臃肿视图控制器” 是命令式的意大利面条式代码。新的内聚组件是声明式和函数式的。

在 React 组件里，我们可以同时处理数据获取、样式和业务逻辑，但它们并不会像从前那样导致代码不可维护。相比传统的架构分层，这种方法减少了不必要的抽象，提升了开发效率。

从 “优雅的代码” 到 “实用的代码”

这些趋势让我开始重新思考代码的价值。过去，我会用架构的优雅程度来评价代码，但现在，我更关注：“这套代码能否让 200 个开发者同时工作，而不会互相绊倒？”

如果抽象层造成瓶颈，那么再漂亮的抽象层也是徒劳。在实际项目中，冗余但实用的代码往往更有价值，因为它能让团队独立工作。

重复远比错误的抽象要便宜得多。

AI 加速这一趋势

有趣的是，这些趋势恰好与 AI 代码助手的工作方式完美契合。

像 GitHub Copilot 这样的工具，擅长生成可复制粘贴的代码，比如 Tailwind CSS 类。它们更擅长编写独立的组件，而不是理解复杂的项目架构。

换句话说，帮助分布式团队的模式，同样也更适合 AI 代码生成。

这就是为什么 Web 前端开发很可能是最早被 AI 自动化的领域之一 —— 因为现代的开发模式，本质上就更容易被 AI 理解和执行。

未来会怎样？

移动端开发会走上同样的道路吗？短期内不会。iOS 和 Android 仍然深度绑定于官方工具和开发模式，尤其是 Apple 生态，它更倾向于 “正确的做法”，而不是开发者的自由度。

但这种趋势终究会到来。SwiftUI 和 Jetpack Compose 正在引入声明式 UI 模式，而 Flutter 早已将这些理念融入其中。我预测，移动端开发将在 2-3 年内逐步采用这些模式。

这是好事还是坏事？

最初，我对这些变化充满抵触，后来逐渐接受，现在甚至感到兴奋。

是的，对于那些接受过传统软件架构训练的人来说，这些新模式可能看起来 “违背最佳实践”。但它们确实解决了现实开发中的很多问题，而传统架构往往无法有效应对这些问题。

问题不在于 “这是不是干净的代码？”，而在于 “这是否能帮助团队在没有瓶颈的情况下交付价值？”

作为一名日本工程师，我最初很难接受这种转变。我们的文化强调匠心和精细打磨，但我逐渐意识到，不同规模的开发需要不同的方法。

关于凝聚式编程的思考

在实际项目中，我看到团队将相关代码集中管理后，确实带来了好处，即使这种做法跨越了传统的架构边界。

• 独立开发，比完美的抽象更有价值
• 降低团队间的依赖，比层层分离的架构更重要
• 选择适合团队协作的技术，而不是执着于某种 “最佳实践”

有时候，最务实的解决方案，就是拥抱复制粘贴式开发，并接受那些真正能让项目推进的模式，而不是一味追求架构的 “完美” 与 “优雅”。

前端的未来不在于完美地分离关注点，而在于能够感知上下文的设计，这种设计能帮助真正的团队在分布式的世界中构建出真正的产品。
原文：
https://codingcafe.jp/posts/cohesive-programming