如何编写可测试的代码
重构和测试是要成对出现的。
重构是在不改变原先功能的前提下就行的代码调整。那你怎么确保没有改变原先的功能呢，就需要测试。
要测试，不是说，我硬写一个Junit、Spock，最关键的是你的代码要可测试。
下面这段代码可测试吗？
代码片段选自极客专栏《遗留系统现代化实战》
看到这样的代码，你可能会说，这质量还行啊，可读性不错，职责也比较清晰。的确是这样，但这样的代码却是不可测的。因为 EmployeeDao 内部会访问数据库，从中读取出一个 Employee 对象。而这个 EmployeeDao 是在方法内通过 new 的方式直接构造的，就意味着这个方法对 EmployeeDao 的依赖是固定的，无法解耦的。
所以需要修改。
把会访问数据库的 EmployeeDao 提取成类的私有字段，通过构造函数传入到 EmployeeService 中来，在 getEmployeeDto 方法中，就可以直接使用这个 EmployeeDao 实例，不用再去构造了。由于传入的 EmployeeDao 并不是 EmployeeService 构造的，所以后者对前者的依赖就不是固定的，是可以解耦的。
SRP最贴切的定义
这周一天，我在群里问大家一个问题，关于单一职责哪一种说法最正确。
SRP的定义其实经历过三次更新，也就是从只干一件事，到只有一个修改原因，再到只对一类行为者负责。
关于只干一件事，这个并不是SRP的全部。
只有一个被修改的原因，差不多已经到位了，如果要更深入挖一挖的话，谁会促使功能发生修改呢，肯定是跟这个软件功能的利益相关者。也就是行为者。
另外，1、2、3中的只局限到一个类里面就狭隘了，所以最终，最正确的是6。
互联网三高
一直以来我们都知道，互联网有三高，高并发、高性能、高可用。
在一定的环境下，做到高并发有难度，做到高性能有难度，在高并发、高性能的环境下，还要做到高可用，实际上是难上加难。
我们都知道，高可用有个衡量的标准，就是我们常说的4个9，5个9等等，那实际上要保证4个9以上的高可用，也就是年度不可用时间要小于53分钟。
从一个客户端发起一个请求，需要经过系统接入层、系统应用层、系统服务层、资源层，层与层之间，和每个层的内部都有可能发生各种各样的问题。
图自20220423MsupA2M大会.阿里.严明明老师PPT分享.《云原生混沌工程实践》
如何实现系统的高可用，具体都有哪些手段呢？
那么能不能提前发现，或者我们可以人为地做什么动作，能够验证整个应用系统架构的鲁棒性到底如何呢？
TIP：如果大家对混沌工程感兴趣，可以加我微信wangxindong2015，帮你联系明明老师^_^
昨天下午，作为出品人在A2M大会上串场了一次高可用架构相关的分享，分别由来自阿里、腾讯、快手和京东的四位老师共同贡献了精彩的演讲。
TIP：更多精彩内容大家可以关注Msup官方内容。
搭建行动框架
这周在池老师的知识星球里面，看到盖总的这段描述，感觉很有感觉，分享出来。
如果现在还没有年、月、周这样的时间框架，那我们理解未来的日子，就像是站在海边，深情地看着茫茫无际的大海一样，心生辽阔，却无从下手。
年、月、周这样的刻度，给了我们时间的框架，我们就会在这样的框架里面，工作、生活、向前。
实际上，我们每年做年度计划、季度计划，也是搭建一个框架，计划里面有目标，有我们的动作，就成了行动框架。然后我们就可以在我们搭建好的行动框架里面，迭代，重复，向前。
