代码中的边界问题(简洁代码阅读注意事项 #7)
注:正文中的引用是直接引用作者的话,两条横线中间的段落的是我自己的观点,其他大约都可以算是笔记了。
在一个完整的系统开发过程中,我们一般不会所有的代码和细节实现都自己去完成,那么不可避免地要用到第三方类库、开源实现或者公司内部其他团队的子系统的实现。在这种时候,我们就要给自己负责的这部分定义「清晰的边界」,来让我们的软件更加健壮。本章将讨论一些对边界问题的处理的几个实践和技巧。
使用第三方代码
使用「第三方类库」总是会碰到这样一个问题,第三方包的提供者往往费尽心力要把接口设计得更加通用和普适,然而第三方包的使用者(往往是正在开发某个系统的我们)却只想要「我们要使用到的那部分功能」被开放出来,而对于不使用的功能我们并不想将之暴露给代码的其他部分。这就造成了第三方库和我们自己的代码间的边界问题。
这里拿Java基本类库中的java.util.Map
来举例,这个类本身提供了很多方法(如列表7-1所示),对于Java基本类库来说这种强大而且灵活的Map是设计良好且很有必要的,但是如果我们的场景是我们使用Map存储手机上的传感器列表,此时我们并不希望接每个能拿到这个列表的人都能删除列表中的项——这可能会带来系统的不稳定,但是实际情况则刚好相反,拿到这个Map的人甚至可以使用一个clear()
函数就可以清空整个列表,这就是代码中的边界问题:「第三方类库(这里是java.util.Map
)的边界(它提供的接口)和我们代码中所需要的边界并不相同」。
//列表7-1 java.util.Map中的方法
• clear() void – Map
• containsKey(Object key) boolean – Map
• containsValue(Object value) boolean – Map
• entrySet() Set – Map
• equals(Object o) boolean – Map
• get(Object key) Object – Map
• getClass() Class<? extends Object> – Object
• hashCode() int – Map
• isEmpty() boolean – Map
• keySet() Set – Map
• notify() void – Object
• notifyAll() void – Object
• put(Object key, Object value) Object – Map
• putAll(Map t) void – Map
• remove(Object key) Object – Map
• size() int – Map
• toString() String – Object
• values() Collection – Map
• wait() void – Object
• wait(long timeout) void – Object
• wait(long timeout, int nanos) void – Object
要解决这个问题,只需要对这个容纳传感器的Map进行简单的面向对象封装。更理想的情况应该是,在你的代码中永远不要传递像Map这样边界十分「宽」的对象,它们永远应该被包裹在其他边界更「窄」的类中。
探索和学习边界
在项目中使用第三方的库可以加快开发进程,同时提供更多的功能。通常在准备把一个第三方库加入项目时,我们可能要花一段时间来查看它的文档,然后试着写一些代码来测试这个库是否能达到我们的要求,但是这样往往会发生这样的情况,当其中出现问题时,我们需要通过不断地调试「我们的项目中使用这个第三方库的相关代码」,来判断到底是我们的代码中的bug还是这个类库本身的bug。
与此不同,我们可以采用另外一种方法来对待第三方库,我们在拿到这个类库之后先写一整套的单元测试——这些单元测试涵盖了所有我们会用到的这个第三方库的功能——来验证这个库是否可以符合我们的要求,在此同时也学习了如何使用这个库。这个方法被称为学习测试(learning tests)。
学习log4j
比如我们想要使用Apache的log4j
来作为我们的项目的日志系统,那么我们首先做的就是写一个单元测试,来测试它「是否可以」和「如何」在屏幕上打印一个字符串hello
。那么我们通过查看它的文档和在搜索引擎中的检索问题,我们写出了代码7-2中的这样一个单元测试。
//代码7-2
public class LogTest {
private Logger logger;
@Before
public void initialize() {
logger = Logger.getLogger("logger");
logger.removeAllAppenders();
Logger.getRootLogger().removeAllAppenders();
}
@Test
public void basicLogger() {
BasicConfigurator.configure();
logger.info("basicLogger");
}
@Test
public void addAppenderWithStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n"),
ConsoleAppender.SYSTEM_OUT));
logger.info("addAppenderWithStream");
}
@Test
public void addAppenderWithoutStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n")));
logger.info("addAppenderWithoutStream");
}
}
写完这个测试,我们就已经知道怎么去使用log4j
了,包括怎么去初始化和配置它,然后我们就可以按照学到的知识把log4j
封装成一个我们自己的类,这样它的边界变成我们想要的样子。
「学习测试」还能带来更多的好处
我们通过以上的单元测试的编写学习了如何使用这个类库,同时也没有浪费时间,因为我们本来就要花时间去写测试代码,倒不如直接这样写成单元测试,既清晰又不会污染我们项目中的其他代码。
与此同时,学习测试还带来了其它更积极的作用,如果这个第三方类库的版本更新了,我们只要把我们的单元测试再跑一遍,就可以「其中我们要使用的这部分功能是否有了变化,是否仍然满足我们的需求」,如果单元测试直接通过,那么我们可以放心的升级新版本,否则我们也可以直接知道哪里出了问题,马上就可以在生产代码中做出修改,避免了产生毫无头绪的bug。
学习测试其实最根本的作用就是在第三方类库和我们的项目中间构建了一个边界,通过编写的单元测试就可以很清晰地测试这个边界是否有效。
我们经常为了避免产生bug而不愿意去升级项目中依赖的第三方库,甚至在这个过程中做出各种各样的妥协,让项目的维护和升级变得越来越难。如果使用这里的讲到的边界测试,升级第三方库也会变得十分容易。
使用未来的代码
使用边界可以带来另外一个好处就是,可以使用未来的代码。
我们经常碰到这样的场景,两个团队a和b合作开发一个项目,他们分别负责不同的模块,模块a依赖另外一个模块b,此时b的接口还完全没有定义,行为也完全可能有变化,但是b模块大致要做的事情是确定了的。那么a团队就可以在a模块中先自己设计一套简单的接口并作出简单的实现(可能返回的是假的数据),然后在这个基础之上a来写一个自己的适配器类c,来对所有这些接口进行包装。这样就定义好了a和b之间的边界,适配器类c就是连接a模块和b模块之间的桥梁,然后a就可以继续进行其他工作而不需要考虑b的开发进度了。
如果有一天b团队说它们的接口需要变化,那么a模块中要做出的修改也只局限在这个适配器类c中,其他的模块完全不受影响。
清晰的边界
关于边界问题有很多有趣的事情,变化就是其中之一。有时候我们的项目中不得不做出各种各样的改变,好的软件设计可以让项目以很小的代价来做出这种改变,而边界问题在这里起到了很重要的作用。
好的软件设计中应该有清晰的边界和在边界之间表示互相期许的单元测试。这样就防止了我们的代码知道太多的它依赖的第三方库的具体实现,所有边界之间的耦合可以轻松被控制在可接受的范围之内。
上一篇: 边界值分析法软测试教程
推荐阅读
-
代码中的边界问题(简洁代码阅读注意事项 #7)
-
源阅读:VictoriaMetrics 中的 golang 代码优化方法
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
入门讲解:Spring源代码探索系列" 1. Spring源码剖析导论 2. Spring容器基础操作实战 3. Spring核心容器组件详解 4. 详解Spring基础:XmlBeanFactory源码解析 5. 掌握关键技术:如何获取并处理Document 6. 精读细节:BeanDefinitions的解析与注册过程 7. 深度解析:bean标签在源码中的执行与注册路径
-
MAX_LEN) {
int pivot = partition(arr, left, right);
quicksort_optimized(arr, left, pivot - 1);
quicksort_optimized(arr, pivot + 1, right);
} else {
// 使用插入排序处理小数组
}
}
```
- 合并相同值进行分割:在每次划分后,我们将与枢轴相等的元素聚集在一起,以降低后续迭代中的重复处理。例如:
原序列: 1 4 6 7 6 6 7 6 8 6
- 选取枢轴(6)并划分:1 4 6 7 1 6 7 6 8 6
- 划分结果(未处理相等项):1 4 6 6 7 6 7 6 8 6
- 处理相等项后的划分结果:1 4 6 6 6 6 7 8 7
- 下次划分得到的子序列:1 4 和 7 8 7
通过这样的优化,我们可以明显减少迭代次数,从而提高排序效率。">
改进版快速排序:针对部分有序列的策略与优化技巧" - 随机选枢轴:当数据部分有序时,传统快速排序通过固定枢轴可能导致效率低下。为此,我们采用随机选取枢轴的方法,代码如下: ```c int SelectPivotRandom(int arr[], int low, int high) { srand(time(0)); int pivotPos = (rand() % (high - low)) + low; swap(arr[pivotPos], arr[low]); return arr[low]; } ``` - 优化小数组交换:针对小且部分有序的数组,快速排序不如插入排序高效。因此,当待排序序列长度小于等于10时,我们会切换至插入排序: ```c #define MAX_LEN 10 void quicksort_optimized(int *arr, int left, int right) { int length = right - left; if (length > MAX_LEN) { int pivot = partition(arr, left, right); quicksort_optimized(arr, left, pivot - 1); quicksort_optimized(arr, pivot + 1, right); } else { // 使用插入排序处理小数组 } } ``` - 合并相同值进行分割:在每次划分后,我们将与枢轴相等的元素聚集在一起,以降低后续迭代中的重复处理。例如: 原序列: 1 4 6 7 6 6 7 6 8 6 - 选取枢轴(6)并划分:1 4 6 7 1 6 7 6 8 6 - 划分结果(未处理相等项):1 4 6 6 7 6 7 6 8 6 - 处理相等项后的划分结果:1 4 6 6 6 6 7 8 7 - 下次划分得到的子序列:1 4 和 7 8 7 通过这样的优化,我们可以明显减少迭代次数,从而提高排序效率。
-
南邮OJ Web任务大揭秘:层层挑战剖析 1. 挑战一:迷宫般的目录探索 题目作者似乎穷举了所有可能的目录组合,最终在404.php中的