《测试开发方法论》之 未雨绸缪

磨刀不误砍柴功。

在测试开发日常的工作中，对于某全新的领域开发工具/平台/框架/算法时，如果时间充裕，最好能提前准备好各种工具算法。

当然，按照我们之前的优化章节中意外性优化所说，很多麻烦的事 是开发过程中才发现的，如果预计后续会经常重复这个过程，建议立即转去打造一套小工具脚本。

小伟奉命打造一套 构造房源的 快速脚本，其中涉及到多个接口步骤，小伟迅速做好了这个工具。但是好景不长，没过两天，其中有个接口需要维护了。

此时的小伟用了大概5分钟，进行新旧接口的对比，找出了需要修改的部分，替换掉了原来的脚本代码，使工具重新有效。

然而，又过了俩天，又一个接口需要维护了，小伟这次用了20分钟才找到新旧接口的改动，进行替换成功。

这个情况，毫无征兆的第三次发生了，小伟面对着新的未知报错，陷入了沉思。此时的他，依然可以耗费几分钟，去解决这个报错，可是那又如何呢？能挺几天呢？ 那么为什么不在这套脚本开发前，设计成数据分离的架构模式，这样的话，接口数据和结构单独 脱离业务逻辑脚本来进行维护，就不用每次去修改代码重新部署到服务器了。而且也更方便开发一个小脚本来直接检查出新旧接口对比 自动修复的功能。 可是现在这样未分离的原始架构，维护起来太麻烦了。 

小伟下定决心进行大改重构，可是这样要花费的时间，至少也要一整天... 此时的他后悔不已，为什么在一开始时候没有预见到这个后续维护成本，没有设计一个很好的架构呢？

对于我们个人的心态里来说：

慵懒 是人之常情。每次面对修改的时候，在5分钟临时修复 和  5小时 永久解决 的选择上，总是困难的。虽然明知 长痛不如短痛。 但是 懒得的情绪 会导致我们 想着 先对付好这次事故，等有空再进行长期重构。

当然对于聪明的测开来说，要避免这种挑战自己本性的情况出现，最好就是未雨绸缪，在开发一开始就设计好架构组织，减轻后续维护成本。

标签：未雨绸缪,脚本,方法论,架构,接口,小伟,开发,测试,维护
来源： https://blog.51cto.com/u_15282986/2953205