项目优化之路

项目优化之路

吴旻

泰岩网络工作室

SZL2项目终于在程序员被折腾的“鼻青脸肿”后上线了。没有人表示庆祝，就像一群人终于爬到山顶，已经累得没有力气了，全部倒下休息，喘粗气！这中间还曾发生过一次严重的项目延期事件，由于性能原因，上线日期不得不推迟了一个月。

其实不用测试我都知道：虽然大家忙了这么长时间，其实还是很差！于是我找个机会提出申请，由我主导对项目进行优化。

高层领导同意了。

一、开发测试环境

没有测试环境一直是我中途加入这个项目后倍感困惑的一个问题。已有的程序员不愿意做这些额外的工作，而且时间也似乎不太允许我们再开发别的什么东西，于是程序测试是从上生产线开始的。问题的多与乱我简直没法形容，总之我是一直处于晕的状态。现在，经过一周的努力，我开发出了和现有程序完美结合的测试程序：数据发布端和客户显示端。这两个端点的好处是可以动态配置，我可以随时改变测试内容，而无需更新太多代码，所有的技术其实只是一点点XML文件。甚至，我还计划把它的某些功能做成B/S架构的，以便于测试使用。当然，这是后话。

现在，我可以在我的测试程序上模拟全部BUG了。

令人兴奋的消息很快就来了。一些原来定位不清的问题马上知道了原因，在哪一端，在什么地方。同时也解决了一些长期困扰我们的问题，比如，虽然是其它部门的显示错误，但连我们都以为是我们的计算错误。

那一瞬间的感觉真是云开雾散呀！想想看，不是你的问题，可所有的人都觉得是你的问题，当你最后证明的它的所在时，那是什么感觉！

后来再开发相关的项目时，我把自己的测试环境做了推广，负责需求的同事用了以后觉得非常好，也大大提高了那个项目的开发进度！可见，这是磨刀不误砍柴工！

二、整理相关开发文档

要想优化，得先知道原来我们都做了什么，是怎么做的。

由于没有相关的设计文档，也没有系统架构图，所以我只能把程序的类图打出来，以供优化参考。VS2008在这一点上比较好用，有根据代码生成类图的功能，虽然还很简单。

真是不看不知道，一看吓一跳。

有些类的写法明显不对头，比如程序实现了一个HASH类，其实与std::map本质上没什么区别，却无端引入了复杂度。而这个类的引入主要是因为原有程序员觉得需要引入，并没有什么实际数据证明std::map差。后面接手的程序员因为看不懂这个HASH类，又不得不再次使用std::map。所以程序中就出现了两种数据保存方式。

有些类最初的设计和实际使用不相符。比如，有一个log类，这本来是好事，也是程序必需的。但这个类的使用很不方便，而我后来根据程序的实际特点，利用std::cout完全做到了日志功能，这个方法也被其他同事采用，所以原来的log类就显得非常无用。

还有一些命名上的误会，或者叫一些根本让人猜不出实际含义的通用名称，比如，一个类A的成员函数名叫Do()，另一个不相干的类B的成员也叫Do()。这实在是让人晕的事情。Do()是个通用概念，做抽象可以，实际具体应用就是表达不清的另一个说法。

还有一些类的划分过于分散。比如，有一个登录某服务器并接收数据的功能，程序却安排了两个类，一个connector，一个receiver，其实两个类都只有几十行代码，根本没必要分开。分开了，还要在两个类之间传递socket才能运行。

还有一个类过于庞大。它是处理一个消息，此消息却会内嵌若干更小的消息。这么一个庞然大物显得非常复杂，极不便于理解和维护，而把这些内嵌消息单独处理，就显得合情合理。

二、架构调整

有了类图，有了上面的分析，基本上可以确定修改方向。

先是尽可能的不改动代码进行调整，以便使程序的架构明确，同时也能保证程序编译通过并运行。

再是修改类的内部实现方式，而不改变其接口，以保证架构的稳定。

进一步是合并或者拆分不合适的类，以便于降低架构复杂度，提高可理解性。

最后就是一个模块一个模块的调整及测试相关代码。

三、代码整合及性能测试

代码整全与架构调整是同时进行的。因为有了前面的测试环境，每一次架构的修改，代码的调整，都可以通过测试环境进行验证。

我甚至可以在下班后把程序启动起来，让它跑上一个晚上，第二天早上来时再看看有没有什么异常。

适当的单元测试也辅助了我顺利进行优化。它会告诉我哪里是性能瓶颈，何处是效率关键。

四、集成测试

在经过若干次申请与努力后，我终于在生产线上得到了一台测试机。它的运行时间比正式服务器要早15分钟，有一次上位机出了问题，测试机首先报警。等我把问题解决后，正式服务器还没开始运行呢！

那感觉真是一个爽！

每一次代码确定上线，我都在测试机上先一天运行，发现正常稳定后再部署到正式服务器上。同时相关服务器也会保留最近几次的代码，一旦发现错误，立即回滚到上一版本。

前两天，领导转给我测试部门发的报告，上面说，我们的产品比同类公司的其它产品速度要快！我长长的出了一口气，这是同事对我的工作的最好肯定。

五、几点经验

1、搭建测试环境很重要。

开发时的测试环境不好，直接就会影响到开发的情况。有些问题如果没能及时发现，很有可能使问题越藏越深，使后来的处理成本大大增加。

2、架构设计图不能少

好多程序员觉得我自己明白就行了，用不着那么麻烦。或者大多数程序员还不明白什么是架构图。我就遇到过一个兄弟把类图当架构图给我，还说很多大公司都是这样的，都能看懂。言外之意，只有我这种土老冒才不明白他是什么意思。

架构设计图其实就是工程建设的图纸，要有专人维护，要及时更新。

3、适当利用集成开发环境

我遇到了几个兄弟都坚持使用自己原来的编辑器，比如vi。不是说这些工具不好，而是说效率太差。尤其是进行代码重构时，先进的工具一个命令就做完了，差的工具要手动的一个一个去改。这也是好多程序员不愿意重构的原因，全程替换根本不可靠， 搞不好会引入更多的错误。

4、利用svn等工具的版本管理优势

都这年月了，还是有很多程序员不会用这些版本管理工具。他们所谓的会用其实就是check in 与 check out，我甚至都觉得很难沟通。计算机里左一个工程目录，右一个工程目录。其实适当建一些临时的svn库，以防止大量中间代码被提交到正式库中，对以后的版本回溯会带来N多好处。个别程序员甚至连编译的中间代码（如obj文件）也一同提交到svn中去，好好的管理工具从此变得难以管理。这个时候如果临时代码管理库的出现，会使新手们省去了很多畏惧。项目负责人在适当的机会再把这些代码整理上传到正式服务器，代码管理就会简单很多。

当然，这也有一定的难度。有些公司就明确规定，所有代码必须上传到公司指定服务器！言外之意，垃圾代码也得上传上去。海量的垃圾数据与管理混乱其实没什么区别，这就需要项目负责人与公司高层进行适当协商，以利于项目开发。

软件开发一开始是技术问题，然后是沟通问题，最后就会深刻成管理问题！