原来是这样的，所噶

今天周六加了一天班，终于完成了客户端本地更新的基本流程，就是傻瓜式的补丁生成和打补丁，都是一键的哦，亲~

但是对于这些资源包，它们作为游戏运行的基础，我还是有点担心：使用的StormLib库对于删除操作有点BUG，会影响到之后的打补丁，花了些时间把库代码出错的那个地方小修正了一下，但是作者大哥的一句话又让我感到前途未卜，具体见这里



忽然想到一个办法，可以做一个方便的小工具，用来对一个资源包进行检测，通过了检测，那基本上游戏里面使用起来我就可以放下心了。工具做的工作很简单，对资源包里面的所有文件进行一次遍历，对每个文件都测试读取其数据成功与否。这样，即使有错误，都是能马上得知了，而不是跟整个游戏运行搅合在一起，崩掉了不知道是不是资源包的纠结问题。很奇妙的是，虽然我之前都没接触过单元测试这个概念，但是想到做这个工具后，我脑海立即浮现出了“单元测试”几个字。一查资料，我的这个想法还真是符合单元测试思想啊，内牛满面啊，公司里写代码都没人提到过这最基本的开发活动啊，不给力啊。还真是得靠自己看书，自己学习领悟。

单元测试：在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

然后又看到了"Code Review"这个词汇，看了看介绍，又有点恍然大悟。。。。。。话说某周周六，主程把我叫到他电脑上，让我给他阐述一下我功能的实现思想，接口的参数含义，接口对外的逻辑功能，还给我讲了代码规范和提高维护性什么的东西。我当时下来就有点囧，这是什么情况。现在看来这应该是很平常简单的代码审核。更高级和完善的Code Review远比这强多了呢，想想一群精英(肯定有几个是评审者)在那里尝试改善软件的代码结构，提高可维护性。唉，我想我们每天的早会，每周的周会能不能更给力点呢，汲取点高级的开发活动思想~