1、架构设计的目的

软件项目中的架构设计是想要解决一个问题：让普通程序员也能参与其中，一起实现复杂系统，而不必依赖于很多精英。

架构设计，就是通过组织人员和技术，低成本满足需求以及需求的变化，保障软件稳定高效运行。

1.1、什么是复杂的软件项目

复杂的软件项目通常有两个特点：

需求不确定技术复杂

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

需求让技术变复杂：软件要能不断响应新的需求

人员让技术变复杂：团队成员水平不一，擅长的技术方向也不一样

技术本身复杂：技术本身的使用门槛较高

保证软件稳定运行是复杂的：运行时的不确定性

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

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

个方面来：

架构设计可以降低满足需求和需求变化的开发成本：通过对系统抽象和分解，把复杂系统拆分成若干简单的；对需求的变化，已经有一些

成熟的架构实践。架构可以帮助组织人员一起高效协作：通过抽象再拆分，可以把复杂的系统拆分成开发人员可以各自独立完成的模块。

架构设计可以帮助组织好各种技术：如分层架构架构设计可以保障服务稳定运行：如分布式架构、异地多活等。

1.3、什么是架构设计

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

架构设计的方法都是基于工程领域分而治之的策略，本质上就是将系统分拆，将人员分拆。但是光拆还不够，拆完了还能拼回来，所以咬

清楚架构设计的“道”。 架构设计的道，就是组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定

好的协议互相通信，共同实现最终的结果。

1.4、如何做好架构设计

架构设计要做好，确实不是一个容易的事，需要大量的经验积累。但是业界已经有了很多成熟的架构设计模式，我们不需要闭门造车，可

以在理解清楚业务需求后，找到相近的架构设计，然后基于成熟的架构设计方案，进行改造，变成适合自己业务需求的架构。

可以按以下步骤进行。

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

step2 选择相似的成熟的架构设计方案 在了解清楚需求后，就可以从业界成熟的架构设计模式中选取一个或几个。具体选择哪些架构设计模式，需要根据平时的学习积累来做判断。 在选好架构方案后，还需要考虑选择什么语言和开发框架。这部分选择需要根据团队情况和项目情况来综合评定。

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

分层和分模块

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

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

2、如何做好技术选型

技术选型是项目决策

对技术的个人偏好很可能让我们在技术选型时，忽略架构设计的目标，导致满足需求的成本变高，或者运行成本居高不下。要做好技术选

型，需要从项目决策的角度来选择合适的技术。 项目决策需要考虑：

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

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

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

结论再找证据

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

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

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

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

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

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

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

的目标。

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

3、架构师

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

3.1、架构师思维

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

就是这几种思维的集合。

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

不必关心模型内的细节实现。

分治思维：架构设计的一个重点，就是要对复杂系统分而治之。 复用思维：通过对相同内容的抽象，让其能复用于不同的场景，是一种

非常简单的提升开发效率的方法。 迭代思维：好的架构通常不是一步到位，而是先满足好当前业务需求，然后随着业务的变化而逐步演

进。

3.2、好的架构师

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

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

有架构师思维懂业务需求：能很好地理解业务需求，能针对业务特点设计好的架构有丰富的编码经验：像抽象、分治、复用这些能力，都

需要大量的编码才能掌握，另外保持一定量的编码经验也有助于验证架构设计。良好的沟通能力：架构师需要沟通确认需求，需要让团队

理解架构设计。

要成为一个好的架构师，没有什么捷径，需要比普通程序员更多的努力才行，宝玉老师的建议：

要成为一个优秀的程序员多模仿学习选择好行业和平台：更多的实践机会

4、技术债务

技术债务时用来形容架构或代码上的质量问题的。

4.1、什么是技术债务

范围不减、成本不加，还想节约时间，就会影响到质量。技术债务就是软件项目中对架构质量和代码质量的透支。 技术债务具有以下特

点：
有利息：后期对软件做修改的时候，需要额外的时间成本。不一定都是坏的：如快速原型模型，就是通过技术债务的方式快速开发快速验

证。验证不可行，则无需偿还债务。

4.2、产生的原因

技术债务的原因可以分为两个维度：

轻率/谨慎有意/无意

轻率-有意的债务：故意走捷径，没有设计、不遵守好的开发实践，对于债务没有后续的改进计划

谨慎-有意：清楚直到技术债务的收益和后果，并且制定了后续的计划去完善架构和提升代码质量

轻率-无意：团队不知道技术债务，也不知道要后续产幻技术债务的情况

谨慎-无意：重视架构设计和技术债务，但因为其他客观因素造成技术债务的产生

4.3、如何管理

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

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

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

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

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

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

3、实施策略

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

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

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