什么是追踪溯源，这个词语放在 “测试开发” 工作中要怎么理解 我们先放一放。
先来想一下，在测试开发工程师写一个复杂平台的时候，最担心什么？
如果是一位初级测开，那么他最应该担心的是能否搭建成功，实现功能。
如果是一位中等测开，那么可能他最担心的是功能的性能，效果，以及推广问题。
如果是一位高级测开，那么他最担心的八成就是后续的维护成本，自己能不能有精力维护，能不能交接给新人。
而其实最影响后续维护成本的，也是最让人操心的，就是自己和后续的人，很难看懂之前的代码，或者很难去再次置身于当时开发阶段的场景中。想要维护修好的精力 甚至比当初开发还要大和难。
比如：其他系统拿过来的接口/脚本
小王是公司的一位测开，这天，他准备打造一套复杂的业务处理平台- 数据工厂。
数据工厂，就是自动去生成各种测试数据的平台。其中牵扯到各种复杂业务，即便是公司老员工，也不可能知晓各个业务的技术细节。
所以，小王凭借自己优秀的人脉关系，迅速联系了很多其他系统和业务支撑的开发同事。打造的这套数据工厂利用了很多很多 开发同事提供的接口 和脚本。
小王只简单的 给这些脚本 接口，写了一个和用户交互的 前端页面，即完成了这个数据工厂。
可是好景不长，一年后，数据工厂的各个功能开始逐渐失效，小王解析代码发现，是这些引用的外部接口 或 脚本出现了问题。
但是因为当时没有明确的注释，导致小王维护的时候，完全想不起来这些外部接口的功能，参数字段的含义，更想不起来这些要去找哪位开发同事......
甚至有些接口的负责人，早已离职，业务也早已交接给别人。 好一点的接口，也是因为服务器地址变更失效，但是小王也不知道要去问谁。而更简单的接口/脚本字段变更的情况，榜一大哥同样不知道找谁负责，也不知道对应的接口文档在哪。
小王预感到，如果现在要捋清这些，恐怕付出的代价不会少于当时从头开发。所以就把这个恶心的维护任务交给了新人，新人的热血工作立即见效，但小王也逐渐失去了核心测开工作的地位。
上述的例子中，其实小王如果在一开始就想好 这一步，那么就可以很好的避免了。
毕竟做的平台，并非底层的算法类工具，或者说技术框架 架构。而是一个 超多增删改查，引用外部接口脚本的 重业务平台。那么 对应的文档的重要性就大大提高了。
比如 一个良好的习惯就是，凡事引用了外部接口/脚本，都在文档中记录好，对应的 一切有关信息：时间，作用，原理，接口文档，字段含义 规则规范，最重要的是 对应的负责人。把这些整理成一个文档，每个月拿出来重新检查一遍，把有改动的，趁着自己没忘，赶紧更新了。那么之后也就没有上述的重新沟通成本的麻烦事了。
尾语：
开发平台诚可贵，推广运营价更高，若为维护故，俩者皆弟弟。
