给Java程序员的Angular快速指南

太长不读版：

Spring + Angular 的全栈式开发，生产力高、入门难度低（此处省略一万字），是 Java 程序员扩展技术栈的上佳选择。

如果你动心了，接下来就是那省略的一万字……

痛点 - 团队分工与协作

在前后端分离的开发方式中，拆故事卡是个难题。

如果前后端同时工作于一张卡上，但配合不够默契或节奏不同步，就会出现一方空转的现象。如果前后端各一张卡，又不容易实现端到端验收，可能导致先做完的一方在另一个结束后还要再次返工的现象。而且，两个人都要深入理解这张卡所描述的业务细节，而这往往是不必要的。

更重要的是，BUG 最容易出现在边界处。

业务卡不像技术卡那样能跟其它卡片划出明确的边界，前后端之间必然具有千丝万缕的联系。这种联系越紧密，出 BUG 的机会也就越大。

技术架构上的挑战，也会反映到人员架构上。我们人类不是星灵，无法做到心灵相通。因此前后端开发者需要对合作方所拥有的知识进行很多主观假设。

如果这些假设中存在错误，又没能及时沟通来消除它（甚至可能都意识不到这些假设的存在），那么 BUGs 就要登场了。而像业务卡这种级别的密切协作中可能隐含的假设实在太多了，除非经过长时间的磨合，否则很难消除，但大多数项目上可没有那么多磨合时间。

解决方案 —— 全栈式开发

人员架构

该如何解决呢？克服上述问题的办法就是全栈式开发。也就是说，调整人员架构去适应技术架构。

简单来说：每个人都同时写前端和后端。他不必是前端专家也不必是后端专家，但是两边都要会写。他的关注点不是技术知识，而是业务知识。他的工作目标是贯穿前后端的价值流，对单个故事进行端到端交付。

但是，要如何克服实现中遇到的技术难题以及保障代码质量呢？那就要靠团队中的技术专家了。

总体来说，全栈式团队的人员架构就是大量全栈业务工程师 + 少量技术专家。当然，技术专家不一定要安排单独的人担任，只要技术满足要求，也可以由某位全栈工程师兼任，只是他做计划时要留出做技术支持的时间。

通过 Code Review、Pair 等敏捷实践，技术专家可以起到团队放大器的作用，让整个团队的生产力翻倍。

个人工作流

作为全栈工程师，你首先要对一个业务故事进行建模，包括业务模型、视图模型、领域模型、存储模型等，建模的过程也就是你理解业务的过程。这时候要注意多和 BA、UX、DBA 等沟通，以确保你的理解不存在方向性错误，不要太沉迷细节，防止见木不见林。

单源建模的优点是这些模型之间很容易保持一致，这无论是对前期开发还是对后期维护都是有帮助的。

建模完毕之后，就要开始设计前后端之间的接口了。接口是前后端分离式架构中最容易开裂的地方，也是对未来的演化影响最大的地方之一。它很重要，但也不必小心翼翼的 —— 全栈工程师对接口变化的适应能力要强大得多。因为接口的提供方和消费方都是你，信息非常透明，不存在任何额外的假设。对不完美的接口，你可以在后续开发过程中迭代好几个版本来把它打磨到最理想的形态，改接口将不再沉重和危险。

接口设计完之后，有两种路径，取决于界面和后台逻辑的特点。

如果对业务理解还不是很有信心，那就先用 Mock 的方式把前端写出来，然后把这个 Mock 版当做可执行的原型去跟 BA、QA，甚至客户进行实际操作演示，用可操作原型来验证你对业务的理解。对一般粒度的故事卡，线框图级的可操作原型通常能在半天内完成。通过原型尽早发现错误，可以避免以后沉重的返工。而且，这是一个可演化原型，不是一次性原型，不会浪费掉。

如果后端很容易实现（但先不必做优化工作），那么就可以不必 Mock，先初步完成后端开发，并让前端直接对接真实的后端。先拿这个比 Mock 版原型更逼真一点的原型串起流程，然后再进行优化和打磨工作。

在整个过程中，你可以根据不同的需要，来与不同的技术专家进行 Pair，并且你最终的代码也会在例行 Code Review 中得到前端专家、后端专家、DBA、DevOps 专家等人的点评和改进，不必担心自己在单项技术上的短板影响交付。

全栈的挑战

全栈固然美好，但也要迎接很多挑战，而 Angular 会帮你分担这些痛苦。

首先遇到的挑战是语言切换

前后端 JavaScript 全栈固然在特定场景下有效，但是在很多企业应用中是远远不够的。至少到目前为止，企业应用还主要是 Java 的天下。本文所讨论的也都是 Java + JavaScript 的全栈。

我们都知道，Java 和 JavaScript 之间的差异就像雷锋和雷峰塔之间的差异。Java 程序员通常很难适应 JavaScript，不过现在有了更像 Java 的 TypeScript。而 Angular 就是原生基于 TypeScript 的框架，稍后我会做一个摘要讲解，你会发现自己很熟悉它的味道。

（图片来自：http://t.cn/RobG5nA）

其次是基础设施

基于 JRE 的构建体系和基于 NodeJS 的构建体系看似差异很大，实际上却有很大程度的相似性。但前端两年一换代的疯狂迭代，以及层出不穷的新名词、新工具，仍然难免会让后端心生恐惧。不过不用担心，Angular 替你封装了一切，你只需要装上 NodeJS 环境和 Angular CLI 就可以了。你不需要关心它封装了哪些第三方工具，至于今后的工具链怎么疯狂迭代，那都是 Angular 开发组需要操心的事。

最后是最佳实践

前后端从表面上看差异很大 —— 前端轻灵，后端稳重。

但在我看来它们很少存在本质性的差异，更像是不同的社区文化导致的结果。而在更高的层次上看，两边的技术具有很大的相似性