最近一段时间一直忙于对现在的一个系统进行优化，现在把这些感悟写出来和大家分享。
        首先，系统优化本身由于其所处的产品周期或项目周期的关系，和其他诸元有着这样或者那样的联系。由于我们的现在的系统是建立在我们自己的一个开发平台的V1之上，这次优化不仅仅是因为系统本身存在优化的可能性和必要性，还有一点是希望借此来增加领导者对现有平台的认可度，为新平台的开发奠定基础并增加信心，能够给与V2平台更大的支持力度。要让领导者意识到，给予.Net技术的平台是能够有很好的性能表现的。不论是本地局域网还是VPN网络或者是窄带网的大型企业应用。
       另外，从技术上来说，我们原来有一个验证命令是否可用的方法，在优化之前执行删除某条记录后，这个方法会被执行48次，更要命的是，这48次是远程方法调用。总共花费了4.288秒。使用者可能会觉得“科技进步进步到什么地方去了？”。为此，我们通过将所有验证汇集到一点，再从这一点进行验证，减少到1次，测试后发现平均耗时：0.2秒。可见速度优化的不是一丁半点（窃喜，呵呵）。另外，在程序启动时，要进行大量Assembly的注册和反射扫描过程，以便能够发现我们所希望的信息，然后再对这些信息进行分类加工和整理。每次启动都作这样的动作，岂不是多余？况且Assembly的更新也不会比MS发布补丁包频繁。但是系统还是每天被用户打开和关闭的。难道希望用户每天上班的第一件事打开电脑登录系统的时候就心情不好？（呵呵，我们客户的容忍度还是很好的。）当然我们希望自己和用户一样可以心情愉快的开始每一天的工作，为此，立刻动工，我们通过将中间结果缓存的方式减少了部分反射和扫描。节省了20%左右的启动时间。在进行缓存的过程中，我们发现需要掌握一个平衡点。就拿二进制序列化来说吧，如果序列/反序列化的对象过大，性能还不如直接进行扫描。

        在优化的过程中，还发现一些没有被测试到的Bug，在进入某个文档后，工具栏的编辑按钮不可用，而上下文菜单中的编辑项确实可用的。点击之后却没有任何反应。不要说用户，我自己都被搞晕了。这个问题本应该在前期测试中就应该发现的（说明什么呢？……）。看起来虽然不是关键性的问题，但是这些问题如果在早期的测试中就能够发现，可以避免招致不必要的麻烦，节约维护和沟通的成本。想象一下，销售人员Demo时尴尬的表情，客户电话里困惑的声音，维护人员满脸的愁云，难道我们就不能把测试工作做得更好一些吗？虽然我不是专业的测试人员，但是通过这次优化我还是能够发现，测试这点事，不是一件小事。
      性能就像是海绵里面的水，你必须去不断地挤压，只要海面里面有水，你用的力道越大，被优化的性能也就越多。作为一个中型或大型的项目来说，往往在复杂度、开发成本、性能等多个纬度之间进行均衡。也许有什么公式可以计算出一个合理的数据，可惜我孤陋寡闻还没有找到这样的公式，那么我们只能在有效的控制开发成本和复杂度的情况下，必须重视性能！也许我是一个急性子，我不能容忍一个慢如蜗牛的系统！
      重视性能和测试工作吧！