Part5 系统设计篇

21 | 架构设计：普通程序员也能实现复杂系统？

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

精英稀缺、全栈稀缺，通过架构设计让普通程序员也能参与其中，一起实现复杂系统。

复杂系统，需求不确定、技术复杂。

Chaos.jpg

技术的复杂性体现在

• 需求让技术变复杂

• 人员会让技术变复杂

• 技术本身也是复杂的

• 要让软件稳定运行是复杂的

架构设计要解决技术复杂性的问题

• 降低满足需求和需求变化的开发成本

• 帮助组织人员一起高效协作

• 帮助组织好各种技术

• 保障服务稳定运行

什么是架构设计？

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

目标

用最小的人力成本来满足需求的开发和响应需求的变化，

用最小的运行成本来保障软件的运行。

常见的架构设计

• 微服务，把复杂系统拆分成一系列小的服务，服务再拆成功能模块，让人员更好地分工协作。

• 前后端分离，让程序员更专注于某个知识领域，降低开发难度

• 分层设计，隔离业务逻辑，减少需求变更带来的影响。

架构设计之道

组织人员和技术进行系统和团队拆分，

安排好切分后的排列关系，

使拆分后的各部分能通过约定好的协议相互通信，

共同实现预想的结果。

如何做好架构设计？

一、分析需求，满足业务需求是架构设计最基础的目标。分析功能、界面、用户、场景。

二、选择相似的、成熟的架构设计方案。选择架构方案、开发语言、框架，根据项目情况、团队情况综合考虑。

三、自顶向下层层细化。

四、验证和优化架构设计方案。架构设计并非一成不表，在实际开发的过程中，需要根据实际情况不断进行优化和调整。

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

技术选型就是项目决策

技术选型看起来是个技术的选择，但其实是一个和项目情况密切相关的项目决策。

• 回到项目金三角，技术选型同样受时间、范围和成本的约束。

• 要分析可行性和风险。

• 要考虑利益相关人

项目决策中常见的坑

• 把听到的观点当事实，片面相信网络上的技术言论。

• 先入为主，有了结论再找证据。个人喜好，主观出发。

如何做好技术选型？

四个阶段，问题定义、调研、验证、决策。

问题定义

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

提升开发效率，降低开发成本，不是为了使用新酷技术。

Make It Work！Make It Right！Make It Fast！

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

调研

从以下方面对技术进行分析

• 满足技术选型目标吗？

• 满足范围、时间和成本的约束吗？

• 是不是可行？

• 有什么样的风险？风险是不是可控？

• 优缺点是什么？

验证

试用、demo，做的过程中才能知道，选择的技术选型是不是真的能满足技术选型的目标。

决策

在调研和验证完成后，就可以召集所有利益相关人一起，就选择的方案有一个调研结果评审的会议，让大家提出自己的意见，做出最终的决策。

讨论区归纳

宝玉老师的选型原则

• 成熟的好过新酷的

• 流行的好过小众的

• 团队熟悉的好过陌生的

• 简单的好过复杂的

• 开源的好过商业的（有时候也视情况而定）

23 | 架构师：不想当架构师的程序员不是好程序员

前言

拿破仑那句名言：“不想当将军的士兵不是好士兵。”原句是Every French soldier carries a marshal’s baton in his knapsack”，意思是“每个士兵背包里都应该装有元帅的权杖”。

其实拿破仑的本意是激励每一名上战场的士兵都要有大局观，有元帅的思维，并不需要每一个人都一定去当将军、当元帅。

这同样适用于技术领域，对程序员来说，并不代表一定要有一个架构师的头衔，而应该心中有大局观，有架构师的思维。从而能理解架构设计，能写出好的程序。

什么是架构师思维？

架构师思维，其实就是这几种思维的集合。

抽象思维

抽象思维可以说是整个架构设计的基础。需求进行抽象建模，隐藏无关紧要的细节，在高层次的架构设计。

分治思维

对复杂系统分而治之，分解成小的、简单的部分。但光分解还是不够的，还需要保证分解后的部分能够通过约定好的协议集成在一起。

复用思维

通过对相同内容的抽象，让其能复用于不同的场景。

迭代思维

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

好的架构师什么样？

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

好的架构师，应具备以下几个条件：

• 有架构师思维：具备良好的抽象思维、分治思维、复用思维和迭代思维；

• 懂业务需求：能很好地理解业务需求，能针对业务特点设计好的架构；

• 有丰富的编码经验：像抽象、分治、复用这些能力，都需要大量的编码练习才能掌握；另外保持一定量的编码经验也有助于验证架构设计；

• 良好的沟通能力：架构师需要沟通确认需求，需要让团队理解架构设计。

架构师能力模型.jpg

如何成为好的架构师？

从程序员开始，付出比普通程序员更多的努力，成为好的架构师，没有捷径。

宝玉老师的建议：

• 成为一个优秀的程序员。技术好是成为架构师的基础条件，首先让代码易读，易扩展，能重用。通过大量的编码实践，逐步培养出好的架构师思维。

• 多模仿多学习。先把业界成熟的流行的架构吃透，用好。

• 选择好行业和平台。想当架构师，最好选择一个合适的行业，积累足够的行业知识，以后才能更好地设计出符合业务特点的架构。

24 | 技术债务：是继续修修补补凑合着用，还是推翻重来？

什么是技术债务？

技术债务，就是软件项目中对架构质量和代码质量的透支。

技术债务是有利息的

债务的“利息”，就是在后面对软件做修改的时候，需要额外的时间成本。

技术债务不一定都是坏的

刻意欠债的场景，如

提升短期的开发速度，让软件能尽快推出，抢占市场。

快速原型开发中，通过欠技术债务的方式快速开发快速验证。

技术债务产生的原因

《重构》中 Martin Fowler从两个维度分析技术债务产生的原因

1. 轻率（reckless）还是谨慎（prudent）；

2. 有意（deliberate）还是无意（inadvertent）。

TD Quadrant.png

不同债务定义、现象及影响

• 轻率 / 有意的债务

定义：团队因为成本、时间的原因，故意走捷径没有设计、不遵守好的开发实践，没有后续计划改善债务。

现象：不做设计直接编码，后期也没有打算重构代码。或者是团队成员以新手程序员为主，没有足够的资深程序员指导和审查代码。

影响：通常这类债务会一直积累，会导致利息越来越多，最终带来的负面效果会越来越大。

• 谨慎 / 有意的债务

定义：团队清楚知道技术债务的收益和后果，并且也制定了后续的计划去完善架构和提升代码质量的情况。

现象：比如说为了尽快发布产品，先采用“快猛糙”的方式开发，后续再对代码进行重构。

影响：因为能及时偿还，所以既可以短期有一定时间上的收益，长期也不会造成负面影响。

• 轻率 / 无意的债务

定义：团队不知道技术债务，也不知道要后续要偿还技术债务的情况。

现象：对于什么是架构设计，什么是好的开发实践一无所知，代码一团糟。

影响：这类债务最危险，既没得到技术债务的收益，还要偿还其产生的利息。

• 谨慎 / 无意的债务

定义：团队其实很重视架构设计和技术债务，但因为业务的变化，或者其他客观因素的原因，所产生的债务。

现象：设计的时候，无法准确预测后面业务的发展，随着业务的发展，设计无法满足好新的需求。

影响：债务难以避免，但如果能及时的对架构升级、重构，就能保证不会造成严重的影响。

如何管理技术债务？

software design effort.png

Is it worth the effort to design software well?

策略：让技术债务控制在临界点之下

识别技术债务

• 开发速度降低

• 单元测试代码覆盖率低

• 代码规范检查的错误率高

• Bug 数量越来越多

• 其他，如语言或者框架的版本太老，开发人员总是需要加班加点才能赶上进度

选择处理技术债务策略

• 重写：推翻重来，一次还清。缺点，工作量很大，新系统没完成之前，同时要对旧系统维护和增加新功能，压力非常大；另外新系统重新稳定下来需要一段时间。

• 维持：修修补补，只还利息。缺点，越到后面，维护的成本就越高。

• 重构：新旧交替，分期付款。缺点，整个过程耗时相对更久。

三种策略并没有绝对好坏，需要根据当前项目场景灵活选择。

实施策略

• 对于重写的策略，要当作一个正式的项目来立项，按照项目流程推进；

• 对于重构的策略，要把整个重构任务拆分成一个个小任务，放到项目计划中，创建成 Ticket，放到任务跟踪系统中跟踪起来；

• 对于维持的策略，也要把需要做的修补工作作为任务，放到计划中，放到任务跟踪系统中。

实施策略的关键就在于要落实成开发任务，做为项目计划的一部分。

预防才是最好的方法

• 预先投资，好的架构设计、高质量代码。

• 不走捷径，日常能做好代码审查、保障单元测试代码覆盖率。

• 及时还债，把欠下的技术债务记下来，放到任务跟踪系统中，安排在后续的开发任务中。

课后感

• 需求分析师和架构师都是IC但又需要leadership的角色。他们是从两个维度降低软件开发的复杂性。需求复杂度和技术复杂度。同时，他们又要组织好团队内的相关活动和知识管理，促进组织发展。

• 康威定律，Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)。关联到架构设计，通俗的理解就是，组织沟通方式决定系统设计。

• 技术债，可以借债加速发展，但债是有利息了。当债务巨大的时候，体现在系统就是系统维护需要大量人力，极小的需求改动也需要大量开发。