饭谈:软件测试的下水道井盖为什么是圆的?

本文通过探讨下水道井盖为何通常是圆形,引导读者思考问题背后的逻辑和场景适应性。作者指出,技术选型并非一成不变,应根据实际需求和环境选择最优方案。例如,软件开发中,选择JS/JQ、是否前后端分离等决策,应综合考虑技术成熟度、开发效率、维护成本等因素。作者强调,避免盲目跟风,培养独立思考能力,才能成为出色的测试工程师。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

大家都听过这样一个问题:**下水道井盖为什么是圆的?**

这个解答有很多,有说是因为圆形受力面积最均匀很安全,有说圆形便于生产,有说因为下水道是圆的,有说如果做成方形那你就会问为啥是方形等等,很多答案。

但是在你认真思考这些原因的时候,其实你已经错了。因为你一开始就被带偏了,出题者把你的注意力转移了,从题面转移到了答案上,如果你张嘴回答的时候,其实已经陷入了出题者给你画的思维定式中了,说白了,被洗脑了,你思考答案的时候,潜意识里就默认了出题者的这个假命题了,不管你的回答是什么,他的目的已经达到了,就是让你无比确信,世界上的下水道井盖都是圆的,而这种常用的心理控制情况很多见。  



破解的办法是,你不该马上去思考井盖为什么是圆的,而是应该反问他一句:**下水道井盖全是圆的么?**   

上面给出的所有各种各样的答案中圆形井盖的优点,如果真的是圆形吊打了其他所有形状。那为什么还有其他形状的井盖呢?比如矩形井盖?连我们外行都能七嘴八舌的说为什么要用圆形井盖,人家内行工程师为什么还有用矩形的?甚至六角形等各种?



当然有,小区里的砖路面,马路牙子紧紧贴着的下水道方形井盖等等。  

  

所以看看上面的反问,打破一个结论,最简单的办法,就是举一个反例,一个可以直接让其颠覆的反例。  



而事实上,**下水道井盖的形状,是取决于适用场地的!**  



我曾看过一些人士对此的细心研究结论,圆形井盖的确有很多优点,但不绝对!

比如小区中多是矩形,因为小区内车辆较少,不如马路上车多。所以此时优先考虑的是小区的地面砖的形状,井盖形状要符合砖的形状,这样才易于安装。  

比如马路边的井盖也是矩形,因为要紧贴着马路牙子,所以形状也要符合周围建筑。  

比如马路中间,都是圆形,因为马路上都是沥青下的水泥路面较多,什么形状都可以的情况下,优先考虑的就是材料成本。下水道井是圆的,所以盖也是圆的,因为砌成圆形,是同样周长中面积最大的。  

  

所以我们得到了一个结论,在不同的使用场景中,我们优先考虑的因素是不同的。没有什么东西能在所有场景中都排第一,如果真的有,那么这世界上就不会再见到那些“看起来更差和更弱”的设计了。  



**然后带着这个结论,我们回到测试领域上来...**  

  

在我开发一些测试平台的时候,总有很多粉丝问我一些问题,类似上面的井盖为什么是圆的问题。



比如:饭佬?为什么你的平台用的是JS/JQ 而不是VUE呢?  

比如:饭佬?为什么你的平台不做成前后端分离的呢?  

比如:饭佬?这个算法为什么不要线程的那个第三方库呢?  

比如:饭佬?这些数据为什么要用ORM方式存储而不用原始SQL呢?  

比如:饭佬?为什么这里我们不用jenkins来实现部署呢?  

比如:饭佬?为什么你这个ui自动化脚本不用page-object设计模式呢?  

比如:饭佬?为什么平台首页不做成很多数据报表的样式呢?  

比如:饭佬?为什么不把整个平台代码都用pep8工具自动整理一遍呢?  

比如:饭佬?为什么你不搞视频教程,非要写图文教程公众号呢?  

比如:饭佬?为什么你不去bat公司,非要在一些小公司混呢?  

.......  



上面的这些问题,以前大家可能总问,但是经过我今天拿井盖的例子给大家讲完后,相信你自己的心里应该有答案了......  

  

没有什么技术是能在所有场景下都是最优秀的,也没有什么设计是永远最差的,视频教程在很多人心里也不如图文教程方便,也不是所有人都喜欢在大公司996的。  

你应该自己去实践一下,自己主动思考一下。思考哪些点呢?比如技术流行度,技术当前的材料资料多少,技术的开发者团队稳不稳,这个技术难不难,物理成本高不高,开发周期长不长,风险大不大,维护简单还是复杂,交接好交接么,推广好推广么,理解起来更容易还是更反人性。等等等等…

 而你在完全忽略自身技术水平,时间充裕度,公司任务周期,同事的技术水平,工具平台的作用和侧重点,后期维护排期的时候,只会去百度上随便搜搜,或者听着周围人嘴里随便说说,就盲目的跟风确定,那样的你,就成为了盲从,一个随波逐流的测开工程师,一个永远赶不上热乎,吃不到行业红利的人。而我的培训班区别于其他的,就是因为我想培养的是一个个有灵魂的测开工程师,而非流水线的批量机器人。



所以,在特定的具体环境下,最优先考虑的因素并**不**固定。我只能根据自己当时的条件和具体背景来择优选择,比如之前,一周时间做成一个自己都没见过的技术的行业内都没有先例可循的平台,相信我,那时候顾不了太多所谓的技术选型,代码规范了,因为做不完就失业~ 那时候最优先的因素就是速度和简单。



当然,我的所有结论并不一定适合所有人,因为人不一样,自己身处的场景也不一样.....而且也不适合自己的任何时期 或者任何平台,所以大家看到我的很多平台其实设计 技术,甚至语言都有区别。

所以这种选择类的问题 就不要多问了,自己想用什么就用吧,只是要结合自己当下的自身情况,工作环境,评估好成本收益,风险即是最优解。

 当然,如果你觉得思考太多很麻烦,那么最简单的办法还是相信我的判断,本来也应该多听取一些经验丰富的人的建议。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我去热饭

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值