前端工程化系列三：减少编码

虽然上面讨论了许多当下社区比较流行的编码提效方法，但更理想的方案实际上应该是少写，甚至不写代码！也就是所谓减法的智慧，而这又回到一个老生常谈的问题：如何让同一份代码尽可能被重复使用？

1. 可复用代码

方法论很简单：提升模块的内聚性，同时降低模块之间的耦合度，以保证代码模块能被灵活组合在多种场景中消费，但实操中这也正是"编码"动作最为困难的点(之一?)。首先，"内聚"与"耦合"这两个概念本身就非常主观，很难客观量化评价具体实现方案在这两个维度上的表现；其次，两者虽然重要但并不影响代码最终呈现的效果，站在 Code Reviewer 视角，除非花时间深入理解代码否则很难做出准确评估；再次，在互联网这种需要快速响应变化的行业，编码质量的重要性往往会让位于进度，迫于压力在工作中我们总会做出妥协，牺牲质量与长期可维护性而把时间花费在实现各种花里胡哨的功能中。

所幸，软件行业已经有非常多前辈对“内聚”与“耦合”做出过许多深入的研究与探索，沉淀了许多相关书籍，包括：

• 《设计模式：可复用面向对象软件的基础》
• 《面向对象程序设计》
• 《设计模式之禅》
• 《重构 - 改善既有代码的设计》
• 《编写可读代码的艺术》
• 等等

虽然目前依然缺乏相关量化评估标准，但这些书籍至少已经帮我们搭建了一套完整的知识体系(内功)，能够在感性层面将大多数人对“内聚”“耦合”概念放在同一位面，以相似的理论基础评估代码设计的好坏，而这能帮助我们规避许多低级问题，并在一定程度上提升可复用性。

因此，虽然我们依然很难通过自动化工具精确地量化评估代码的可复用性，但理想情况下，应该投入适当的时间精力，在技术方案设计与 Code Review 环节有意识地多加甄别。方案评审环节鼓励团队内更多有经验的同学参与到对抽象架构的讨论中，能提供视角更完整的评审与讨论，发现潜在问题与不必要的重复；而 Code Review 阶段则可以更细粒度地关注每一个模块、方法具体实现的输入输出数量、副作用、全局状态依赖等等，保证每一个模块、函数、代码都尽可能遵循上述书籍所给出的最佳实践。

PS: 我们应该重视 Code Review！这是自动化之外最后一道质量防线，后面会有章节专门展开讲述 Code Review 的作用、最佳实践等。

复用性是一个很复杂的话题，有非常非常多可以探讨的点，我会在后续单独开篇深入讨论。

2. 提升复用率

回归工程视角，在团队协作时，可能还会面临这么一个问题：协作规模增长容易导致信息传递效率下降(Brooks's Law)，有时候即使已经封装了一些很优秀的组件，似乎也很难按最初设想般被广泛复用，排除组件功能与接口形态的适用性问题，有部分原因就在于：团队其他成员很难感知到这些潜在的可被复用的代码片段，毕竟很难有人能时刻站在全局视角完整理解团队范围内到底产出了多少功能模块。为此，可以尝试落地一些有助于提升信息传递效率的方式方法，帮助开发者更容易理解全局代码进而提升代码的复用率，比较常见的措施包括：

• 建立公共物料托管平台：代码复用的难点之一就是模块相关功能与设计信息分散杂乱且过于具体，理解成本高。那么理所当然地只要把这些“信息”整理归纳成“知识”，并收敛存放到团队全局可存取的知识空间中，必然是更有助于知识传播与代码复用的。例如，可以借助 Storybook、MDX、VitePress 等工具为公共组件编写使用手册，充分介绍组件的使用方法并发布托管到内部域名，供团队成员分享学习。
• 使用 Monorepo 管理项目：Monorepo 是业界比较流行的代码管理模式之一，它鼓励将所有代码集中存放到同一个代码仓库中统一管理，虽然这会相应增加工程的管理成本与技术复杂度，但能在代码层面构建一个更加开放、透明的协作环境，身在其中的开发者都能轻易获得所有代码进而更容易理解项目全貌，也更容易捕捉到当下正在以及可能发生的变化，这对公共组件开发者而言这意味着更容易感知到潜在用户与需求；对组件消费者而言则意味着更容易挖掘到潜在的可复用组件，进而提升整体的复用率。
• 基于代码重复率推测复用性：简单场景中，相似需求“可能”会实现为相似度较高的代码 —— 例如参数格式判断、安全的 JSON.parse等，理论上应该将这部分代码片段收敛沉淀成业务内普适、通用的底层组件，而不是在各处自行编写各种形态“重复”代码，因此可以借助一些重复率工具(例如 jscpd)在工作流的适当环境 —— 例如 CI 中扫描增量代码的重复度，并给出提示，实现自动检测、预警的效果。更进一步的，条件允许时还可以尝试借助 LLM 搭建 RAG 应用实现更智能化的代码重复率检测，基本逻辑是定期将团队所生产的全量代码转换为 AST，借助 Embedding 将 AST 转换为向量后存入数据库，之后在开发、CI 阶段与 LLM 交互，基于向量数据推算出增量代码的重复率。
• 鼓励跨团队分享：在管理学中，将大团队拆分为若干小团队并合理定义各自的职责与边界有助于保持个体的专注、专业度，人尽其才，进而提升整体协作效率。但站在微观视角，团队之间的职责边界很容易演变成信息屏障，身在其中的普通个体通常没有驱动力主动跨越团队边界将工作成果分享出去。因此，站在管理视角我们应该通过一些适用的方式方法鼓励成员将优秀的代码与知识分享到更大范围 —— 并将此沉淀成团队的底层文化。而站在工程视角，我们也可以尝试建立一些工程工具协助成员们做好知识分享，例如可以基于 LLM 自动生成关于代码片段的功能、原理、使用说明、最佳实践之类的说明文档。

这些举措的目标本质上都是将代码提炼为更易于阅读理解的信息描述并充分暴露在公共空间中，供有需要的成员随时取阅，久而久之甚至有可能在团队内形成更开放透明的技术交流文化，这虽然无法直接提升代码质量与复用性，但会反向鼓励生产者投入更多时间不断优化代码模块的可读性、易用性、可复用性等。

3. 自动生成代码

除了提升代码可复用性(这依然是需要尽力追求的核心要素)之外，如今的业界还有许多工具与技巧能够在特定场景下有效减少编码，其中最具革命性的变化来自大模型技术的成熟与普及。

3.1 使用 AI 编程助手减少编码

在 2024-2025 年，AI 编程助手已经从"辅助工具"演变为开发者的"编程伙伴"，能够在合适的场景下显著减少手动编码量。市面上主流的 AI 编程工具包括：

• IDE 集成类：Cursor、GitHub Copilot、Claude Code 等，直接集成到编辑器中，提供实时代码补全和生成
• 对话式工具：ChatGPT、Claude、Gemini 等，通过自然语言交互生成代码
• 专用工具：v0.dev (UI 组件生成)、Bolt.new (全栈应用生成) 等垂直领域工具

这些工具的核心价值在于：将开发者从重复性、模式化的编码工作中解放出来，让你能够更专注于架构设计、业务逻辑和质量把控。

3.2 AI 生成代码的最佳实践

从我的实践经验看，AI 生成代码的质量高度依赖于你的使用方式。以下是一些经过验证的最佳实践：

3.2.1 提供充分的上下文

AI 生成代码的质量与你提供的上下文信息成正比。好的上下文包括：

❌ 不好的提示：
"写一个函数处理用户数据"

✅ 好的提示：
"在我的 React + TypeScript 项目中，写一个自定义 Hook useUserProfile，需要：
1. 从 /api/users/:id 获取用户信息
2. 支持 loading 和 error 状态管理
3. 使用 SWR 库处理缓存
4. 返回类型包括 user、loading、error、mutate 方法
5. 需要完整的 TypeScript 类型定义"

关键要素：

• 明确技术栈（React、TypeScript、SWR）
• 具体需求（API 地址、状态管理、返回值）
• 代码风格约束（TypeScript 类型定义）

3.2.2 善用多轮对话迭代优化

AI 生成的代码往往需要多轮优化才能达到生产级别。建议采用"生成 → 审查 → 反馈 → 优化"的迭代流程：

第一轮：生成基础实现
第二轮：要求添加错误处理和边界情况
第三轮：优化性能和代码结构
第四轮：补充单元测试

示例对话流程：

你："生成一个函数，从数组中移除重复项"
AI：[生成基础版本使用 Set]

你："考虑对象数组的情况，根据 id 字段去重"
AI：[优化为支持对象数组]

你："性能优化：如果数组很大（10万+），如何优化？"
AI：[引入 Map 数据结构优化查找性能]

你："添加完整的单元测试，覆盖边界情况"
AI：[生成测试用例]

3.2.3 分解复杂任务

不要期望 AI 一次性生成复杂的完整功能，而应该拆解为多个小任务：

❌ 不好的方式：
"帮我写一个完整的用户管理系统，包括增删改查、权限控制、日志记录"

✅ 好的方式：
1. "先写用户数据的 TypeScript 接口定义"
2. "写一个 useUsers Hook 处理用户列表获取和搜索"
3. "写一个 UserForm 组件处理用户新增和编辑"
4. "写权限验证的中间件函数"
5. "为以上功能编写单元测试"

这种方式的优势：

• 每一步都能得到高质量的代码
• 便于审查和调整
• 降低出错概率
• 更容易理解和维护

3.2.4 指定代码风格和约束

明确告诉 AI 你期望的代码风格和约束条件：

"生成代码时请遵循：
- 使用函数式编程风格，避免副作用
- 所有函数必须有 JSDoc 注释
- 遵循 Airbnb JavaScript Style Guide
- 变量命名使用语义化的英文单词
- 复杂逻辑必须添加注释说明
- 不使用 any 类型"

3.2.5 验证和测试生成的代码

永远不要直接使用 AI 生成的代码而不经过验证。必要的验证步骤包括：

1. 代码审查：检查逻辑正确性、边界情况处理
2. 类型检查：运行 TypeScript/ESLint 确保没有类型错误
3. 单元测试：编写或要求 AI 生成测试用例
4. 性能测试：对性能敏感的代码进行 benchmark
5. 安全审查：检查是否存在安全漏洞（如 SQL 注入、XSS）

3.3 AI 适合生成的代码场景

根据实践经验，AI 在以下场景能够显著减少编码量：

1. 样板代码（Boilerplate）

• CRUD 操作的基础实现
• API 路由和控制器
• 数据验证逻辑
• 表单处理代码

2. 单元测试

AI 非常擅长生成测试用例，特别是：

• 边界情况的测试
• Mock 数据的生成
• 测试覆盖率的补充

3. 数据转换和处理

• 格式化函数（日期、货币、文本）
• 数据结构转换（扁平化、树形转换）
• 数组/对象操作工具函数

4. 类型定义

• 根据 API 响应生成 TypeScript 类型
• 根据数据库 Schema 生成接口定义
• 复杂类型的组合和映射

5. 正则表达式

AI 能够根据自然语言描述生成复杂的正则表达式，并附带解释和测试用例。

6. 配置文件

• Webpack、Vite 等构建工具配置
• ESLint、Prettier 配置
• CI/CD 工作流配置

3.4 AI 编程的注意事项

尽管 AI 能够显著提升效率，但也需要注意其局限性：

1. 代码质量参差不齐：AI 生成的代码可能存在性能问题、安全漏洞或不符合项目规范
2. 缺乏业务理解：复杂的业务逻辑需要人类的判断和经验
3. 依赖训练数据：AI 可能生成过时的实践或不推荐的模式
4. 隐私和安全：避免将敏感代码或数据发送给公共 AI 服务
5. 过度依赖风险：保持独立思考能力，不要盲目信任 AI 的输出

核心原则：AI 是工具而非替代品，最终的代码质量和架构决策依然需要由工程师把控。

3.5 从对话式到 IDE 集成

对于日常开发，推荐使用 IDE 集成的 AI 编程助手（如 Cursor、Claude Code），而非纯对话式工具，原因在于：

• 更好的上下文理解：能够读取当前项目的代码、依赖、配置
• 即时反馈：在编写过程中实时提供建议和补全
• 无缝集成：直接插入代码，减少复制粘贴
• 多文件编辑：支持同时修改多个文件，保持一致性
• 版本控制集成：与 Git 工作流无缝配合

基础版本示例（ChatGPT 对话式使用）：

优化版本一（提供更多上下文）：

优化版本二（多轮迭代优化）：

3.6 其他代码生成方案

除了 AI 编程助手，还有一些传统但依然有效的代码生成方案：

代码模板和脚手架

使用脚手架工具针对特定场景生成模式化代码，业界相关实践已经非常成熟，比较知名的有：yeoman、vue-cli、CRA、plop 等工具。虽然场景比较局限，灵活性也不是很高，但这种方式能非常有效地节省重复投入，例如我们不必一而再再而三地配置 Eslint、Webpack 等，因此也是一种性价比比较高的提效方法，建议每个团队甚至个人都应该花点时间维护一套模板集。

💡 结合 AI：可以让 AI 帮你生成和维护这些模板，显著降低维护成本。

Design To Code 工具

在开发 Web 页面时，常规流程通常需要首先将设计稿还原为页面代码，这部分工作并不轻松，需要耗费比较多时间精力一比一还原 UI 稿的交互细节。所幸基于 Figma 产出的设计稿已经能导出比较结构化的 UI 描述信息，因此市面上有不少商业机构在尝试将结构化描述转换为 Web 代码 —— 主要是 HTML 和 CSS。

以我个人使用经验来看，这些 D2C 工具虽然没法达到"人"的精细度，但在一些质量不太敏感的场景 —— 例如短期活动页，适合将 UI 首先转换为一个比较粗糙的代码框架再由"人"来逐步补充优化细节，这种方式也能一定程度上减少人力投入。

💡 AI 增强：如今的 v0.dev、Bolt.new 等工具结合了 AI 和 D2C，能够直接从自然语言描述或截图生成 UI 代码，效果比传统 D2C 工具更好。

低码/无码平台

低码和无码比 D2C 更进一步，期望在尽可能少编码甚至不编码的情况下，通过低码平台搭建可工作的应用。底层逻辑通常是：由平台方提前准备好各种组件 —— UI 组件、逻辑组件、流程组件、数据组件等等，再由用户按业务规则组合这些组件"拼凑"出符合要求的完整应用。

我个人观点是：编程是一件复杂的事情，没有银弹！即使在 LLM 加持下也几乎不可能实现完美的"代码生成代码" —— 功能、稳定性、性能、可维护性，必然有一些地方出现问题。但退一步说，假如允许适当降低要求，在功能整体符合预期的情况下，性能慢点，Bug 多点，代码难看点都能接受，那么低码或许会是一种不错的提效选项。

不过，使用这类平台务必要慎重慎重再慎重！它在减少编码的同时一定也牺牲了一些别的东西（性能、稳定性、可维护性，甚至是整体生产效率），你需要甄别这些东西对你来说，是否比减少编码更重要。

4. 总结

减少编码的核心策略可以归纳为三个层次：

第一层：提升代码复用性

• 编写高质量可复用代码：遵循高内聚低耦合原则
• 重视 Code Review：在方案设计和代码审查环节把控质量
• 学习设计模式和最佳实践：建立扎实的理论基础

第二层：提升代码复用率

• 建立物料托管平台：让可复用组件易于发现
• 采用 Monorepo：构建透明的协作环境
• 借助工具检测重复：自动化发现可复用机会
• 鼓励知识分享：形成开放的技术文化

第三层：借助工具生成代码

• AI 编程助手（重点推荐）：显著减少重复性编码工作
  • 掌握最佳实践：充分上下文、多轮迭代、任务拆解
  • 选择合适工具：IDE 集成优于纯对话式
  • 保持警惕：验证和测试生成的代码
• 传统代码生成：脚手架、模板、D2C、低码平台

核心观点：

1. AI 已经改变了游戏规则：在 2024-2025 年，AI 编程助手已经成为减少编码的最有效手段，但需要掌握正确的使用方式。

2. 工具是手段，质量是目标：所有减少编码的方式都不应该以牺牲代码质量为代价，工程师的核心价值在于把控质量和架构设计。

3. 没有银弹：建议不要过度迷信"由代码生成代码"，编程毕竟是一件极具创造性且极度抽象复杂的事情，在功能准确性之外还需要考虑规模化、可读性、性能、稳定性等等非功能需求。机器（包括 LLM）虽然能解决一部分基础、重复的问题，但当下依然无法在所有场景下完美满足各个维度的诉求，许多时候我们依然需要由工程师完成编程任务。

4. 工程师的角色在演变：从"编写代码"向"设计架构 + 质量把控"转变，这要求我们不断提升系统设计能力和工程判断力。