《软件工程之美》打卡第四周

最近笔者参加了极客时间的21天打卡行动，从年初开始到年末，21天无间断完成了打卡行动。虽然打卡行动已经结束，但还是不想因此就懈怠了，人一尝点甜头就容易忘乎所以，所以我想继续保持学习的习惯。

上周学习完了《软件工程之美》中的需求分析篇，这周会学习系统设计篇，以下是这周的总结：

20 | 如何应对让人头疼的需求变更问题？

这节课很有指导意义，软件工程的存在的目的和意义就是为了解决改善软件项目管理过程中的问题，需求变更就是我们程序员深恶痛绝的问题。
为什么软件项目需求会经常变更？
原因有以下两点：

1. 需求的不确定性，前期需求的抽象和模糊，导致需求的变更
2. 需求的变更成本的意识不足

如何解决需求变更问题？

• 提升需求确定性，把需求分析做好，减少需求变更
• 提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。
• 降低响应需求变更的成本，可以方便快捷地响应需求变更。

这三种不同解决方案，不仅仅只是对工程师提出要求，对项目经理、产品经理等不同角色都提出了要求。只有每个角色都能意识到需求变更给项目带来的后果，提高对需求的理解能力，提高协作效率，减少无用功，提升工作的满意度，不至于疲于应对需求变更。

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

说起架构设计，大部分普通程序员偏向于代码实现，很少有机会站在全局的视野去进行架构设计，这也是我想去加强的地方。

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

• 需求不确定性
• 技术复杂性

架构设计的好处在于：

• 降低满足需求和需求变化的开发成本
• 可以帮助组织人员一起高效协作
• 可以帮助组织好各种技术
• 可以保障服务稳定运行

什么是架构设计？

• 目标：最小人力成本满足需求的开发和响应需求变化，最小的运行成本保障软件的运行
• 方法：组织人员和技术把系统和团队拆分，安排好切分后的排列关系，让拆分后的部分通过约定好的协议相互通信，共同实现最终的结果

如何做好架构设计？

1. 分析需求
2. 选择相似的成熟的架构设计方案
3. 自顶向下层层细化
4. 验证和优化架构设计方案

通过良好的架构设计，可以有效降低开发难道和成本，让普通程序员也能实现复杂系统。

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

技术选型这个话题跟工程师就很相关了，我们日常工作总会遇到要引入新的技术框架，这个时候技术选型就派上用场了。
宝玉老师提到技术选型就是项目决策，受限于以下几个方面：

1. 项目金山角

• 时间
• 范围
• 成本

2. 可行性和风险
3. 考虑利益相关人

常见的坑

• 把听到的观点当事实
• 先入为主，有了结论再找证据

如何做好技术选型？

• 问题定义清楚：为什么需要技术选型和目标是什么
• 调研清楚技术方案
• 科学验证技术方案
• 勇于做出决策

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

作为一个有追求的程序员本就不应该守着自己的一亩三分地，努力学习架构设计，站在更全局的视野思考业务问题，通过良好是技术来帮助业务成功。

架构师思维：

• 抽象思维（针对需求进行建模，进行高层次的架构设计）
• 分治思维（将复杂系统分而治之，分解成小的、简单的部分）
• 复用思维（减少重复实现，提升代码简洁和维护性）
• 迭代思维（先满足业务，再随着业务变化逐步演进架构）

如何成为好的架构师？

• 首先要成为一个优秀的程序员
• 多模仿多学习
• 选择好行业和平台

1580547687142.png

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

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

技术债务产生的原因：

• 轻率/有意的债务（时间成本原因，故意走捷径，不遵守好的开发实践，后续没有改进计划）
• 谨慎/有意的债务（团队清楚技术债务的收益和后果，并且也制定了后续的计划去完善架构和提升代码质量的情况）
• 轻率 / 无意的债务（团队不知道技术债务，也不知道后续要偿还技术债务的情况）
• 谨慎 / 无意的债务（团队其实很重视架构设计和技术债务，但因为业务的变化，或者其他客观因素的原因，造成技术债务的产生）

如何管理技术债务：

• 识别技术债务
• 选择处理策略
• 实施策略

处理策略（主要取决于投入产出比哪个更好）：

• 推翻重写
  • 优点：更好的设计，精简功能和代码；
  • 缺点：工作量大，压力大，稳定需要一段时间
• 修修补补
• 优点：成本低，不用投太大精力
• 缺点：后续维护成本高
• 重构
• 优点：对业务影响小
• 缺点：过程耗时持久

预防才是最好的方法

• 预先投资
• 不走捷径
• 及时还债

课后思考：

我们项目中的技术债务有很多，举个例子，App最开始采用的动态化技术是React Native，但随着技术的演变RN的弊端逐渐暴露出来，比如问题定位困难，需要联动前端，后面Flutter出来之后，老大又想趁着这次技术更新将动态化切成Flutter，但这不是个简单的工作，需要评估好成本，然后去逐步验证。对我来说项目中采用的旧技术方案就是技术债务，承载了很多业务需求。我这边打算采用的策略是重构，新旧交替，分期付款。 在过渡期间做好降级策略，避免引入新技术导致线上问题，能够降级继续使用RN。等到Flutter技术应用稳定之后，才把旧的一套完全废除不再维护。

最后

这周完成的学习目标是软件工程中的系统设计篇，从这周开始就不强求一定要打卡完7天，对我来说习惯的养成比强制性的执行要来的更有效，所以我允许自己有空隙，因为总会有其他更重要的事情可能会打断你。本周的学习最大的收获是，更清晰认识到架构的作用和成为架构师需要培养的思维模式。下周继续学习软件工程中开发编码篇，感谢你的阅读。