过程简介

看JSPatch的官网简介，使用已经是非常简单，就初始化和执行脚本两步。文件传输和一些安全验证才是麻烦事，前前后后持续了一个星期。

• 最初的方案是程序启动，下载补丁文件，执行脚本，然后删除补丁文件。这个方案的缺点是每次都要访问网络和下载，如果没网络，就不能执行热更新。

• 改进的方案是在最初方案的基础上引入缓存机制，还会顺带引入文件操作，复杂度瞬间提升三四倍。缓存在任何情况下都是坑，文件操作在很多情况下也是坑。这个方案的重心是对缓存采取不信任态度：程序启动时，先从后台拿配置，检查缓存的有效性，再执行；如果没有网络，获取不到后台配置，那么信任缓存，执行热更新。

• 团队讨论的方案是执行缓存中的补丁文件，下载根据后台配置进行；两者是相互独立的两个过程，没有依赖。程序一起来，就执行缓存中的补丁文件。同时网络取配置，查是否的有新版本的补丁文件，有的话就去下载更新。这个方案的缺点是第一次只下载补丁文件，不执行热更新。当然，要解决也很简单，下载完后执行一下补丁文件就可以了。不过，这又会带来新问题，那就是可能会出现一开始有bug，后来bug又不见了的“诡异”现象。具体怎么做，就看怎么取舍了。

概要设计

通过这次经历，一个可取的经验是将概要设计引入开发过程中。这次从最初的方案过渡到改进的方案，就是通过评审概要设计的成果。
从改进方案到最终团队认可的方案，本来也可以通过概要设计来完成。不过，现实的情况是评审不会反复进行，其他人也不会花太多精力来看这个概要设计。这两个方案实际差别很大，但是差距就是一个串行依赖还是并行独立的问题，不仔细看还发觉不了（这次就没发觉，更新的概要设计也以邮件的形式发出，也没人提出不同意见）。
要解决这个问题，就是引入团队开发模式，一起讨论概要设计，一起编码实现，效果可能会好一点。
这次是在代码演示的时候，团队成员提出问题，表达不同意见，才改过来的。当然，这就是敏捷的原理了。再完美的概要设计文档，也不如现实能运行的代码来得实际。概要设计文档很重要，但是还是最终看到的效果更有说服力。

经验小结

• 将概要设计引入比较独立功能的开发过程，尽早进行团队讨论，处理分歧意见。

• 设计时的思路还需要更主流一点，奇思妙想要少一点。

• 概要设计的讨论还要更充分一点。不同意见尽量早处理。

• 实际效果更重要，文档再完善，也有考虑不周的时候。

• 对于合理意见，认可的话，及早处理，及早应用。