这一章要面对的是第三方系统引发的几类故障。在开源火爆的今天,考虑使用开源项目已经不是稀奇事,但是毕竟开源代码的控制权不在自己手里,在使用时难免会碰到一些问题。
在使用一个服务时,应当先看看有没有其他人也在使用。如果用的人很少应该先思考一下为什么很少人用。如果要继续使用的话,要注意保持警惕,进行全面的测试。并且要准备好备选方案,当服务不符合预期时就不会手足无措。
【有时候在网上查找一些解决方案时会很难搜索到,这个情况下可以先想想,是不是解决的方向错了,其实这个问题有更合理更简单直接的方法。不过有时候迎难而上也会有很多收获。感觉第一节《面对小众需求,切记未雨绸缪》的小标题起的不是很准确,面对让人觉得是要去满足这个需求,而实际上主角是需求方。】
第三方服务并不可靠,和这个服务的受欢迎程度无关。对于依赖第三方服务的项目,一定要确定如何获知服务发生变更的情况。
【第三方服务发生变更是一个很常见的事情,文中的服务提供方宣布变更的方式并不正式。但是在日常使用中,经常乎出现用了第三方服务后就忘了这件事,哪怕第三方发布了服务变更也根本不会知道,这无疑是埋下了定时炸弹。所以对第三方服务做好追踪是很有必要的。另外,在使用第三方服务时,尽量选择大的提供商,比如他们会有正式的通知,保留旧的api接口,在接口快过期时调用会有提示。】
不太理解这里的模拟对象具体是指什么,大意是每次系统升级都要做好自动化测试,查找过期的模拟对象。
有时候烂代码不仅仅是来自于项目内部,还可能来自于外部(比如别人的爬虫)。让异常报告系统和客户通知系统分开投递。异常报告系统最好能把相似问题合成一个报告,否则一旦发生异常很可能会立刻耗尽报告的发送次数。
没有纯粹的内部问题,每个内部问题都可能对客户产生影响。所以不应该仅仅关注客户提出的需求,自身系统的稳定和质量也会影响到客户的评价。
【所以自动化测试一定要做好,保证代码最起码的质量。】