前端工程

Architecture 可以帮助我们回答很多重要的问题。

它帮助团队理解系统的边界、职责和依赖关系，也帮助我们设计一个可以长期演进的结构。

但仅有 Architecture，并不等于已经具备了成熟的软件工程能力。

一个边界清晰的系统，仍然可能缺少可靠的测试。一个设计合理的方案，也可能因为不稳定的 Delivery Process 而难以维护。团队可以做出很好的 Architecture Decision，却仍然在每次 Release 之前感到不确定。

即使代码本身写得很好，如果团队不知道怎样安全地修改它，系统仍然很难长期维护。

这里所说的 前端工程，关注的就是这些问题。

不只是写代码

Frontend Engineering 并不仅仅讨论如何实现一个 Feature。

它更关注真实 Frontend System 周围的工程实践：如何开发、验证、交付、观察、修改，以及如何让系统在长期变化中保持可靠。

这包括 Software Quality、Tests、Quality Gates、Code Reviews、CI/CD、Tooling、Technical Governance 和 Development Process。

同时也包括人与团队：不同角色如何协作，决策怎样被做出，知识怎样在团队中传播和保留下来。

这些内容有时不如一个新的 Framework 或一个很漂亮的 Pattern 那么吸引注意。

但在真实项目中，它们往往直接决定一个系统是否能够持续、稳定地被开发。

Architecture 周围的工程实践

战略级和战术级设计主要关注系统本身。

战略级前端设计 讨论系统的 Boundary 在哪里，以及哪些部分应该一起演进、哪些部分更适合保持独立。

战术级前端设计 则进一步讨论，这些 Boundary 和 Responsibility 在实际 Code 中应该如何表达。

Frontend Engineering 关注的是：这些设计决定需要在什么样的工程环境中，才能长期有效。

我们如何确认一次修改真的正确？团队希望达到什么样的质量水平？哪些规则值得自动化？什么时候 Code Review 已经足够，什么时候还需要更机械化的 Verification？

又如何避免重要的 Knowledge 只存在于少数人的经验里？

当然，还有一个很现实的问题：

哪些 Tool 真的能改善我们的工作？

Tooling 的价值不在于它是否新，而在于它是否真正解决了问题。

专业的软件工程是一个系统

Software Quality 很少来自某一个单独的措施。

有 Tests，并不等于已经拥有 Test Strategy。Linter 不能代替 Architecture Understanding。Pipeline 本身不会自动提高团队速度。Quality Gate 如果没人理解背后的原因，也很容易变成一个只会阻止 Merge 的规则。

成熟的 Engineering 更像是很多实践共同作用的结果。

好的 Tool 可以减少重复劳动。清晰的 Process 能降低不确定性。Automation 可以更早发现问题。Review 能帮助团队共享 Knowledge。Documentation 可以让重要 Decision 在人员变化之后仍然被理解。

有时最有价值的改进甚至不是一个新 Tool 或新 Pattern。

可能只是把 Responsibility 说得更清楚。

Frontend Engineering 关心的正是这些实践如何共同作用。

Roles 也是 Engineering 的一部分

Software Development 不只是 Code、Pipeline 和 Architecture Diagram。

不同的人承担不同的 Role，也会从不同角度理解同一个系统。

Senior Developer 并不会自动成为 Software Architect。Architect 也不一定是团队里技术实现能力最强的 Developer。Tech Lead、Staff Engineer 或 Solution Architect 可能又会承担不同类型的 Responsibility。

这些名称不应该只是职级上的标签。

更重要的是，它们代表了不同的视角、决策范围和责任边界。

因此，这个区域未来也会讨论 Role、Responsibility 和 Collaboration。

不是为了建立新的组织理论，而是为了理解这些角色如何在真实的软件开发中互相配合。

AI 也进入了这个工程体系

LLM 和 Coding Agent 已经成为我自己工作中很重要的一部分。

我并不把它们看成一种独立的 Architecture Layer，也不认为它们只是暂时的潮流。

它们更像是 Software Engineering 工具箱中的一类新工具。

能力很强，但仍然是工具。

它们改变了 Code 生成的速度，改变了我们寻找信息和分析 Requirement 的方式，也让越来越多的工作可以被自动化。

与此同时，Verification、显式 Knowledge 和清晰的技术 Boundary 变得更加重要。

所以 AI 很自然地属于 Frontend Engineering 的讨论范围。

不是因为它是热门话题，而是因为它正在成为真实开发工作的一部分。

系列

Agentic Work in Real Life

这个区域的第一组较完整系列，讨论 LLM、Coding Agent 和 Agentic Work 在专业 Software Engineering 中意味着什么。

内容从 LLM 和 Benchmark 的基础开始，逐步进入 Coding Agent 的真实使用场景，包括 Context、Memory、Requirements、Architecture、Data Protection、Verification、AI-friendly Software，以及 Agentic Work 的经济影响。

到最后，更值得讨论的问题已经不是：

“现在哪个 Model 排名第一？”

而是：

当 Code 越来越容易生成之后，Software Engineering 中哪些能力会变得更重要？

这个系列既不会刻意放大 AI，也不会否定它。

它试着在真正使用这些工具的地方观察它们的能力和限制：真实的软件开发。

这个区域还会讨论什么

Frontend Engineering 将长期关注 Architecture Diagram 和 Production System 之间的那些工程问题。

Quality 与 Verification、Delivery 与 Tooling、Development Process、Large-Scale Applications、Technical Governance、Role 与 Responsibility，以及不断出现的新工具。

并不是每个问题都需要一套完整理论。

有时候，一个合适的方法已经足够。

有时候，需要的是一个可靠的 Process。

还有时候，最好的 Tool 只是安静地把自己的工作做好，而不需要变成下一种“唯一正确的方法”。