软件工程之系统设计

架构设计

为什么软件项目需要架构设计？

• 复杂的软件项目，通常有两个特点：需求不确定和技术复杂。
  
• 技术的复杂性，主要体现在四个方面：
  • 需求让技术变复杂：要响应需求的变化，也会让技术变复杂。对于明确的需求，相对来说技术实现是容易的。但是，随着需求地不断变化，新的需求可能会破坏原有的代码架构，导致系统越来越臃肿复杂，维护也越来越难。
  • 人员会让技术变复杂：一群人有效地协作也是很大的考验，简单的技术问题也会变成复杂的技术问题。
  • 技术本身也是复杂的：现在软件项目中选择编程语言、框架、技术组件、数据库等技术或工具，还可能需要应用像微服务、大数据、人工智能技术，这些技术本身就是复杂的，普通人都需要通过一定的学习才能掌握。
  • 要让软件稳定运行是复杂的：因为技术的这些复杂性，会导致软件开发变得很复杂，开发成本很高。

什么是架构设计？

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

• 架构设计，已经有很多成熟的方法。比如说：
  • 使用微服务这样的架构，把复杂系统拆分成一系列小的服务，服务再拆成功能模块，让人员更好地分工协作；
  • 通过前后端分离，让程序员更专注于某个知识领域，降低开发难度；
  • 用分层设计来隔离业务逻辑，减少需求变更带来的影响。
• 这些架构设计的方法，其实都是基于工程领域分而治之的策略，本质上就是将系统分拆，将人员分拆。但是光拆还不够，拆完了还得能拼回来，所以你要清楚架构设计的“道”。

架构设计的道，就是组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议相互通信，共同实现最终的结果。

如何做好架构设计？

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

第一步：分析需求

• 架构设计，最基本的就是要能满足业务需求，所以搞清楚需求是至关重要一步。而产品需求，只有功能的描述，界面的交互，还需要进一步进行抽象。
• 一个常用的分析方法就是分析用例，也就是了解主要用户角色和其使用的场景。

第二步：选择相似的成熟的架构设计方案

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

第三步：自顶向下层层细化

• 建议能从整体到局部，这样更具有大局观，不容易过早陷入技术细节中。架构设计也是如此，好的实践是自顶向下层层细化。在选择好成熟的架构设计方案后，可以基于方案，层层细化，逐步完善、调整和优化。

第四步：验证和优化架构设计方案

• 在技术方案完成后，还需要去验证方案是不是满足设计的目标，能否满足需求和未来需求的变化，能否保障软件有效地运行。
• 方案的验证是贯穿整个设计始终的，一个完整的架构设计方案，需要有多次的评审会议，充分收集各方面的反馈，反复修改后才能最终确定下来。
• 在架构设计确定后，就可以基于架构设计的结果大家一起分工协作了。架构设计并不是确定后就不修改了，在实际开发的过程中，还需要根据情况对架构进行优化和调整。

如何为项目做好技术选型？

架构设计的主要目标，是要能低成本地满足需求和需求变化，低成本地保障软件运行。

技术选型就是项目决策

• 技术选型，就是在两个或者多个技术方案中选择适合当时项目情况的方案。技术选型看起来是个技术的选择，但其实是一个和项目情况密切相关的项目决策。
• 要做好技术选型，就是要做好项目决策。那么怎样从做项目决策的角度来选择合适的技术选型呢？

受制于时间、范围和成本的约束

• 项目受制于三个因素：时间、范围和成本。技术决策作为一种项目决策，也要受制于时间、范围和成本，在决策时不能超出这三者的边界。

要分析可行性和风险

• 如果在项目决策时，不考虑可行性，不预估风险，就极有可能导致决策失败。

要考虑利益相关人

• 在做项目的决策时，如果决策时没有人代表利益相关的人，就可能会做出不考虑他们利益的决策。

什么是架构师思维？

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

抽象思维

• 抽象思维可以说是整个架构设计的基础。因为对于架构设计来说，是要为了满足业务需求的，而业务需求都是一些文字性的描述、原型、UI 设计图，这些需求要最终变成代码让机器执行，就必须先进行抽象，抽象成计算机能识别的模型。

分治思维

• 架构设计的一个重点，就是要对复杂系统分而治之，分解成小的、简单的部分。但光分解还是不够的，同时还需要保证分解后的部分能够通过约定好的协议集成在一起。
• 分治的思维其实不仅适用于架构上，也适用于平时程序员写代码。比如说有些程序员写代码，喜欢把大量的逻辑放在一个方法或者一个类里面，最后极其难以理解和维护，如果能分拆成几个小的方法或者小的类，不仅结构更清晰，也更容易理解和维护。

复用思维

• 复用是一种非常简单有效的提升开发效率的方法，通过对相同内容的抽象，让其能复用于不同的场景。
• 复用思维在日常写程序的时候也很常用，比如有的程序员喜欢复制粘贴代码，所以经常看到很多重复的代码，如果要修改，得修改好几个地方。如果能把这些重复的代码提取成公共的类或者方法，就可以减少很多重复，让代码更简洁和易于维护。

迭代思维

• 好的架构设计，通常不是一步到位，而是先满足好当前业务需求，然后随着业务的变化而逐步演进。

好的架构师什么样？

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

要成为好的架构师，需要具备几个条件:

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

如何成为好的架构师？

想要成为好的架构师，没有什么捷径，需要比普通程序员更多的努力才行。如果你有志向成为架构师的话，建议是：

• 要成为一个优秀的程序员
  • 技术好是成为架构师的基础条件。需要让你的代码容易读，容易扩展，能重用。这样通过大量的编码实践，才能逐步地培养出好的架构师思维。
• 多模仿多学习
  • 在刚开始的时候，不用想着闭门造车，想出一个特别牛的架构。反倒不如先把业界成熟的流行的架构吃透，用好。现在网络上也有很多好的开源项目，这些开源项目都有良好的架构设计，可以找几个跟你研究方向相关的项目，本地搭建一下，然后自己试一下，最好能弄一个自己的项目二次开发或者模仿一遍，做中学，是最简单有效的。
• 选择好行业和平台
  • 软件其实下面细分了很多行业领域，大类有像互联网应用、企业应用、游戏应用，大类下面又有细分的小类。比如说企业应用又和各行各业的业务结合在一起的，像建筑行业软件，就需要有建筑行业的专业知识。架构师要同时懂业务和技术，而这些行业知识，也不是短时间内能积累起来的。所以如果想当架构师，最好能选择一个合适的行业，能在一个行业里面早点积累足够的行业知识，后面做架构设计的时候，就能更好地设计出符合业务特点的架构。同时，这些行业领域的业务经验，和技术结合的架构经验，也会成为你个人独特的优势，不容易被替代。
  • 还有平台也很重要，好的平台，能给你更多的实践机会。