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

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

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

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

有时,你会认为架构师的职责是要交付 “一种架构”,而这“一种架构” 的载体通常又会以某种文档的形式体现。
所以,很容易误解架构师的工作就是写文档。但实际上架构师的交付成果是一整套决策流,文档仅仅是交付载体,而且仅仅是过程交付产物,最终的技术决策流实际体现在线上系统的运行结构中。
程序员进阶攻略-05 | 架构与实现:它们的连接与分界?_第1张图片

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

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

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

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

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

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

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

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

你可能感兴趣的:(职业规划)