《软件工程之美》—— 架构设计

看着看着就想着应该把一些好的建议和好的提问记下来，日常开发中实时提问。然后还有很多想法，比如总结一个项目体检表出来，对着检查项发现问题。
enmm……我是不是有点上瘾

技术的复杂性主要体现在四个方面：

• 需求让技术变复杂：软件要能不断响应新的需求
• 人员让技术变复杂：团队成员水平不一，擅长的技术方向也不一样
• 技术本身复杂：技术本身的使用门槛较高
• 保证软件稳定运行是复杂的：运行时的不确定性

1.2、架构设计如何解决“复杂”

因为技术的复杂性，会导致软件开发变得很复杂，开发成本高。而架构设计恰恰可以在这些方面很好地解决技术复杂的问题。
主要从四个方面来：

• 架构设计可以降低满足需求和需求变化的开发成本：通过对系统抽象和分解，把复杂系统拆分成若干简单的；对需求的变化，已经有一些成熟的架构实践。
• 架构可以帮助组织人员一起高效协作：通过抽象再拆分，可以把复杂的系统拆分成开发人员可以各自独立完成的模块。
• 架构设计可以帮助组织好各种技术：如分层架构
• 架构设计可以保障服务稳定运行：如分布式架构、异地多活等

1.3、什么是架构设计

架构设计的目标，使用最小的人力成本来满足需求开发和响应需求的变化，用最小的运行成本来保障软件的运行。

架构设计的方法都是基于工程领域分而治之的策略，本质上就是将系统分拆，将人员分拆。但是光拆还不够，拆完了还能拼回来，所以咬清楚架构设计的“道”。
架构设计的道，就是组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议互相通信，共同实现最终的结果。

1.4、如何做好架构设计

架构设计要做好，确实不是一个容易的事，需要大量的经验积累。但是业界已经有了很多成熟的架构设计模式，我们不需要闭门造车，可以在理解清楚业务需求后，找到相近的架构设计，然后基于成熟的架构设计方案，进行改造，变成适合自己业务需求的架构。

可以按以下步骤进行。
step1 分析需求
需要对产品需求进一步进行抽象。一个常用的分析方法就是分析用例，也就是了解主要用户校色和其使用的场景。

step3 自顶向下层层细化
从整体到局部，不要过早陷入技术细节中。
层层细化的示例来啦~

• 部署架构

• API设计、数据库设计、模块设计

step4 验证和优化架构设计方案

2、如何做好技术选型

技术选型是项目决策

对技术的个人偏好很可能让我们在技术选型时，忽略架构设计的目标，导致满足需求的成本变高，或者运行成本居高不下。要做好技术选型，需要从项目决策的角度来选择合适的技术。
项目决策需要考虑：

• 受制于时间、范围和成本的约束
• 要分析可行性和风险
• 要考虑利益相关人

项目决策中需要注意的坑：

• 把听到的观点当事实：每个人都有自己的观点没有问题，但不能把观点当事实，尤其在做决策之前，至少需要验证一下。
• 先入为主，有了结论再找证据

项目决策可以分为几个阶段来进行。

1、问题定义
问题定义阶段需要明确两个问题：

• 为什么需要技术选型
• 技术选型目标是什么

只有明确了技术选型的目标，才有一个标准来评判该选择哪一个方案。

2、调研
在明确技术选型的目标后，需要进行调研看有哪些技术选型可以满足目标，可以从这几个方面去分析：

• 是否满足技术选型目标
• 是否满足时间、范围和成本的约束
• 是否可行
• 有什么样的风险否可控
• 优缺点是什么

3、验证
可以通过一个快速原型项目，用候选技术方案快速做一个原型出来，做的过程中才知道，所做的技术选型是否真的满足技术选型的目标。

4、决策
在调研和验证完成后，需要召集所有利益相关人一起，就选择的方案做一个调研结果评审的会议，做出最终的决策。

3、架构师

架构的思维比架构的头衔更重要。

3.1、架构师思维

架构设计是要控制技术的复杂性。对于架构师来说，要控制技术复杂性，有几种有效的方式：抽象、分治、复用和迭代。架构师思维其实就是这几种思维的集合。

抽象思维：对需求进行抽象建模后，可以帮助我们隐藏很多无关紧要的细节，在高层次的架构设计时，可以关注在几个主要的模型上，而不必关心模型内的细节实现。

分治思维：架构设计的一个重点，就是要对复杂系统分而治之。
复用思维：通过对相同内容的抽象，让其能复用于不同的场景，是一种非常简单的提升开发效率的方法。
迭代思维：好的架构通常不是一步到位，而是先满足好当前业务需求，然后随着业务的变化而逐步演进。

3.2、好的架构师

一个好的架构师，不仅技术要好，还要懂业务；能从整体设计架构，也能在局部实现功能。

有一种架构师叫“PPT架构师”，哈哈哈哈
好的架构师应该具备以下能力：

• 有架构师思维
• 懂业务需求：能很好地理解业务需求，能针对业务特点设计好的架构
• 有丰富的编码经验：像抽象、分治、复用这些能力，都需要大量的编码才能掌握，另外保持一定量的编码经验也有助于验证架构设计。
• 良好的沟通能力：架构师需要沟通确认需求，需要让团队理解架构设计。

轻率-有意的债务：故意走捷径，没有设计、不遵守好的开发实践，对于债务没有后续的改进计划
谨慎-有意：清楚直到技术债务的收益和后果，并且制定了后续的计划去完善架构和提升代码质量
轻率-无意：团队不知道技术债务，也不知道要后续产幻技术债务的情况
谨慎-无意：重视架构设计和技术债务，但因为其他客观因素造成技术债务的产生

4.3、如何管理

技术债务有利息也有收益，如何管理才能保证软件项目中的收益大于支付的利息。

这张图时描述设计、时间和开发速度的关系的。可以直观看出，收益和利息是存在一个临界点的，最好能让技术债务控制在临界点之下。

1、识别债务
软件项目中有很多指标来发现存在的技术债务：

• 开发速度降低
• 单元测试覆盖率低
• 代码规范检查的错误率高
• Bug数量越来越多

2、处理技术债务策略
在识别之后，解决技术债务有三种策略：

• 重写：推翻重来，一次还清
• 维持：修修补补，只还利息。适用于不需要增加新功能的系统
• 重构：新旧交替，分期付款

3、实施策略

• 重写-正式项目来立项
• 重构-将任务拆分并进行跟踪
• 维持-制定计划

4、预防
最好的方法是预防技术债务的产生：

• 预先投资：好的架构，高质量的代码是一种技术投资
• 不走捷径：做好代码审查、保障单元测试代码覆盖率等
• 及时还债：记下欠的债务，及时还债。

来源：一个假的程序媛