程序员进阶攻略-05 | 架构与实现：它们的连接与分界？

从定义上，你已知道架构是一种结构设计，但它同时可能存在于不同的维度和层次上：

高维度：指系统、子系统或服务之间的切分与交互结构。
中维度：指系统、服务内部模块的切分与交互结构。
低维度：指模块组成的代码结构、数据结构、库表结构等。
在不同规模的团队中，存在不同维度的架构师，但不论工作在哪个维度的架构师，他们工作的共同点包括下面 4 个方面：

确定边界：划定问题域、系统域的边界。
切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
连接交互：在切分的各部分之间建立连接交互的原则和机制。
组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。

有时，你会认为架构师的职责是要交付 “一种架构”，而这“一种架构” 的载体通常又会以某种文档的形式体现。
所以，很容易误解架构师的工作就是写文档。但实际上架构师的交付成果是一整套决策流，文档仅仅是交付载体，而且仅仅是过程交付产物，最终的技术决策流实际体现在线上系统的运行结构中。

我以交付一个功能需求为例，讲述下这个过程。

实现一个功能，可能全部自己徒手做，也可能选择一些合适的库或框架，再从中找到需要的 API。

确定了合适的选型后，需要从逻辑、控制与数据这三个方面进一步考虑程序设计：

逻辑，即功能的业务逻辑，反映了真实业务场景流程与分支，包含大量业务领域知识。
控制，即考虑业务逻辑的执行策略，哪些可以并行执行，哪些可以异步执行，哪些地方又必须同步等待结果并串行执行？
数据，包括数据结构、数据状态变化和存取方式。
开始编码实现时，你进一步要考虑代码的执行效率，需要运行多长时间？要求的最大等待响应时间能否满足？并发吞吐能力如何？运行的稳定性和各种边界条件、异常处理是否考虑到了？上线后，出现 Bug，相关的监控、日志能否帮助快速定位？是否有动态线上配置和变更能力，可以快速修复一些问题？新上线版本时，你的程序是否考虑了兼容老版本的问题等？

最后你开发的代码是以什么形态交付？如果是提供一个程序库，则需要考虑相关的依赖复杂度和使用便利性，以及未来的升级管理。如果是提供服务，就需要考虑服务调用的管理、服务使用的统计监控，以及相关的 SLA 服务保障承诺。

以上，就是我针对整个实现过程自己总结的一个思维框架。如果你每次写代码时，都能有一个完善的思维框架，应该就能写出更好的代码。这个思维框架是在过去多年的编程经验中逐步形成的，在过去每次写代码时如果漏掉了其中某个部分，后来都以某种线上 Bug 或问题的形式，让我付出了代价，做出了偿还。

“实现”作为一个过程，就是不断地在交付代码流。而完成的每一行代码，都包含了上面这些方面的考虑，而这些方面的所有判断也是一整套决策流，然后固化在了一块块的代码中。

因为实现是围绕架构来进行的，所以架构的决策流在先，一定程度上决定了实现决策流的方向与复杂度，而架构决策的失误，后续会成倍地放大实现的成本