程序员进阶攻略

最近在读程序员进阶攻略这本书，做点笔记，供自己回看。不断完善中。。。

05架构与实现：它们的连接与分界？

什么是架构

从建筑学来，在计算机工程中，架构师描述功能、组织和计算机系统实现的一组规则与方法。

共同认知

软件系统的结构与行为设计。

架构关注：==《熵》==建立《边界》和《要塞》
实现关注：==《简》==建立《领地》

纬度

• 高维度：指系统、子系统或服务之间的切分与交互结构。
• 中维度：指系统、服务内部模块的切分与交互结构。
• 低维度：指模块组成的代码结构、数据结构、库表结构等。

架构师职责

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

你以为的架构师交付：一种架构（文档）文档只是载体。

实际上：==一整套决策流==，文档仅仅是交付载体（过程产物），最终体现在线上系统的运行结构中。

架构师需要考虑的方面

1. 选型评估
2. 程序设计
   1. 逻辑：即功能的业务逻辑，反映了真实业务场景流程与分支，包含大量业务领域知识。
   2. 控制：即考虑业务逻辑的执行策略，哪些可以并行执行，哪些可以异步执行，哪些地方又必须同步等待结果并串行执行？
   3. 数据：包括数据结构、数据状态变化和存取方式。
3. 执行效率
4. 稳定健壮
5. 维护运维
6. 集成部署

其他需要考虑

1. 你进一步要考虑代码的执行效率，需要运行多长时间？
2. 要求的最大等待响应时间能否满足？
3. 并发吞吐能力如何？
4. 运行的稳定性和各种边界条件、异常处理是否考虑到了？
5. 上线后，出现Bug，相关的监控、日志能否帮助快速定位？
6. 是否有动态线上配置和变更能力，可以快速修复一些问题？
7. 新上线版本时，你的程序是否考虑了兼容老版本的问题等？
8. 最后你开发的代码是以什么形态交付？
9. 如果是提供一个程序库，则需要考虑相关的依赖复杂度和使用便利性，以及未来的升级管理。
10. 如果是提供服务，就需要考虑服务调用的管理、服务使用的统计监控，以及相关的SLA服务保障承诺。

断裂带

架构和实现之间的鸿沟。
因为决策是静态的，实现是动态的。

解决方案：采用定期对系统状态做==快照==。
原则：关注战略性细节，只要没有越出==顶层宏观结构定义边界==即可。
桥梁：在鸿沟上建设，即==战略要地==。

原因

1. 沟通问题：如信息传递障碍。
2. 水平问题：如技术能力不足。
3. 态度问题：如偷懒走捷径。
4. 现实问题：如无法变更的截止日期（Deadline）。

06模式与框架：它们的关系与误区？

设计模式

设计复用

开发框架

代码复用
越是通用的框架，意味着抽象度更高。而现实是越抽象，越难理解。

关系

框架是程序代码，
模式是关于这些代码的知识。

总结

1. 都是前人总结的经验
2. 模式是代码层面，解决单个问题的成功方法。
3. 框架是设计层面，解决一系列问题的成功方法。

---

07多维与视图：系统设计的思考维度与展现视图

语言UML

组成视图

1. 子系统
2. 服务
3. 组件

划分原则

1. 单一化：每个服务提供单一内聚的功能集。
2. 正交化：任何一个功能仅由一个服务提供。没有类似功能的服务。

交互视图

定义：与外部系统的协作关系，即依赖于被依赖。
重点:聚焦。
局部细节交互图

部署视图

系统的部署结构和环境

1. 主机环境
2. 网络结构
3. 环境元素依赖

上图:强调的是应用部署的IDC和网络的关系。关键的网络通讯延时指标。

总结

以上三类图（交互、组成、部署图）表达的是==宏观视图==
关注系统组合、协作和依存关系。

流程视图（UML中的序列图）

表达系统内部实现的功能和控制逻辑流程。
业务和控制。

状态视图

表达系统内部管理了哪些==状态==及状态的变迁==转移路径==。