然后是对项目不熟悉，新同学加入或业务交接等，会让开发人员面对一个全新的项目。这种陌生的情况下，许多开发人员就会产生重复造轮子的问题，只顾着自己开发的部分，完全没考虑到项目原先的代码状况。
这个怎么解决呢，一个是组件化，通过人工手段进行分析，提取 NPM 包，推动业务侧改造，减少重复代码。另一个是代码审计，通过工具化手段进行分析，给出建议，避免重复代码形成。
这里的组件化，其实是指 NPM 包的提取，怎么做呢，可以分析现有公共文件，分析常见业务代码，提取成 NPM 包。然后再对 NPM 包的 API重新设计、评审以保证它的合理性。最后使用 JsDoc 同步生成详细的 API 文档，推动业务侧改造。
也许有人会问为什么不一开始就使用 NPM，答案很简单，微信小程序初期并不支持，实际上他从基础库版本2.2.1开始支持 NPM，但到目前为止，我们小程序仍然有12.8%的用户低于此版本。这个问题可以在打包阶段处理，通过 CLI 将 NPM 包的引用修改为相对路径引用。
前面讲到通过 NPM 来减少重复代码。另外一个手段则是通过代码审计来避免重复代码的形成，通过 CLI 我们可以找出重复的代码片段，输出统计结果和详细对比结果(本章开头的示例)。进一步，可以找出相似代码。
可以看到，在改造前，我们 js 的重复率有12%，12%是什么概念？如果你只有两个一模一样的文件，重复率就是50%。12%意味着每8行代码代码里有2行是一样的。重复代码很多，那重复检测的依据是什么，常见的有基于 token 的对比和基于 AST 的对比。
来看看基于 token 的重复检测原理，其实也很简单，就是将代码转换 token，然后再判断一定长度 token 的 md5 值是否相同。基于 AST 的重复及相似代码检测复杂一些，这里就不细讲了。
好，冗余问题我们通过组件化、代码审计的方式可以解决，接下来讲测试问题。
由于规模暴增，页面越来越多，有些公共文件的改动几乎会影响到所有页面，直接导致测试工作量飙升，质量无法保证。因此我们开发了一个模拟用户行为的小程序自动化测试工具 —— Sandbox。
Sandbox 架构分4层，第一层是测试用例层，第二层是用例步骤控制层，提供 api 供测试用例调用。第三层为沙盒环境，会预处理输入的小程序代码，创建小程序运行时，然后运行在 V8 引擎上，最后一层则是微信 api 的模拟供沙盒调用。需要提一下的是，今年6月份官方提供了小程序自动化 SDK，下一步我们对其进行整合。
这是结合 Mocha 编写的测试用例，可以看到测试用例调用沙盒 api 进行流程编排，有加载页面、模拟点击等。在最后的 check 方法中可以拿到当前页面的 data 和路由来检查是否符合预期。