自从去年年初搬到新办公室后，各个项目组都分到了各个独立的空间了，平时'抬头不见低头见'的情形减少了，随意拉把椅子坐下来谈技术的情形也减少了，随之而来的是项目组'各自为战'，经过近一年的发展，各个项目组在局部的发展上已经出现差异了。

在现在带的这个项目之前，曾经有意识的去了解了一下其他组的技术发展情况，主要是针对Java开发这块。了解的结果让我意识到我们组的Java开发已经'落后'了。其实我们组的Java开发人员论实力也都很不错的，唯一让我感觉有些遗憾的是：他们似乎缺少了一种自我改善的意识和动力，也许也是因为平时的维护工作量太大了，少有时间向这个方向思考。这回我就替他们考虑考虑、规划规划。

改进的两个方向包括持续集成和页面的自动化测试。其实Java开发人员是很幸福的，这个世界上有这么多可以为Java人员所使用的工具，甚至Java人员已经开始抱怨-"框架和工具太多了"。除了思想意识之外，好用的工具对改进过程至关重要。当一个人要去接受一件新事物时，心里总会守着自己的'既有利益'，甚至对新事物会有排斥和戒备心理，这时一个好的工具也许会让你对新事物产生亲切感。持续集成是今年部门的一个改进方向，部门已经在多个项目组做了试点,使用的工具是CruiseControl。我没有实践过持续集成，但是我首先相信这个东西会对我们这个10多个人组成的项目组带有益处，我会将之引入到我们组，即便我们在本期项目中在这持续集成方面哪怕仅有一点点的改善，我也会觉得我们的工作是有意义的，正如今天下午redwood和我说的：即使初期只能达到daily-build这个目的也是很不错的，build的过程也是一个检查点啊。

编写单元测试一直是Java组的一个弱项，虽然Java有很好的辅助单元测试的工具，但是毕竟实际项目中的单元测试用例不像教科书中的测试一个加减法那样简单，单元测试用例需要设计，也许想到了要这样或那样去编写测试，但却发现目前的工具很难支持。碰到的问题多了，也就打击了开发人员写用例的积极性了，这时开发人员大多会索性减少用例个数甚至干脆不写用例了。本期项目我还是极力建议开发人员去尝试写测试用例的，甚至我都想亲自给他们指导如何写用例(虽然我是一个C开发人员，呵呵)，我心里的期望单元用例覆盖率是15%，如果能达到这个目标，我想已经可以让我心满意足了。

页面的自动化测试源自rubyforge上的一个叫Watir的工具，最初是部门内部一个做国际业务的同事使用的，偶尔让我们组的同事发现，便引入到我们组内。Watir是一个用ruby写的类似类库之类的工具，用于控制IE对象。由于是ruby语言编写的，所以语法简单，容易掌握，甚至测试组的人员也可以利用这样的工具来设计集成测试和系统测试的自动测试用例。对页面开发人员来说，他更是可以作为单元测试的一个部分纳入持续集成脚本中，定期运行。Watir还支持录制功能，但是还不够完善，同时其对中文的支持也不甚完善。面对这样一个好用的工具，开发人员的态度还是观望，他们总希望能有人做出些什么东西后在考虑使用，而缺乏一种主动尝试的魄力。

面对这样的情况，我只能默默的安排人手先将前期工作-持续集成工具安装和配置、Watir工具使用培训做了，之后的路还是开发人员自己去走，至于能走成什么样子，我心里也没底。

如果持续集成工具环境搭建顺利的话，我也计划将C工程纳入持续集成过程中，还是那句话，虽然C的单元测试更难做，但是build本身就是一个很好的检查点，能有一点点改进也值得去做。

附：Watir使用的一个例子，你不妨安装一个Watir(还需安装ruby)用下面代码试一试。
# the Watir controller
require "watir"

test_site = "http://www.google.com"
ie = Watir::IE.new
ie.goto test_site
ie.text_field(:name, "q").set "pickaxe" # "q" is the name of the search field
ie.button(:name, "btnG").click # "btnG" is the name of the Search button
puts " Actual Result:"
if ie.text.include? "Programming Ruby"  
  puts "  Test Passed. Found the test string: 'Programming Ruby'. Actual Results match Expected Results."
else
  puts "  Test Failed! Could not find: 'Programming Ruby'."
end
puts "End of test: Google search."

上周日下午，接到同事的一个寻求支持的电话，原来是部门以前给中国联通做的一个运行在PC服务器上的程序在每天凌晨出现'挂死'情况，导致程序运行中断，问题连续几天复现。程序是老程序，在不下十多个省运行，一直都很稳定。通过联通的人发过来的截图，很难定位问题所在，所以只能打车到了联通机房现场查看了。

还是那句话，维护别人的又是自己不熟悉的程序那真是痛苦的，好久都不在Windows上写程序、调程序了，API都需要现到网上查。由于程序一直在现网运行，即使到了现场也依然只能从外围来看，把配置信息和一些现网数据拿到自己的Windows环境下进行模拟测试，看是否能够重现问题，可无论如何模拟都不能重现问题。

问题出在源代码中一处调用DeleteFile的地方，在凌晨那个时刻，DeleteFile总返回失败。微软的帮助文档给出了DeleteFile失败的一些原因，比如文件是只读的、文件是受保护的系统文件或者用户没有删除这个文件的权限等等。我们重点检查了那个出问题的文件夹中是否有特殊文件，将Windows设置成显示所有文件，包括隐藏文件后，依然没有发现。由于是现网主机，不便过多操作。

程序有个缺点就是没有后台日志输出，也许当初开发这个程序的同事也许开发惯了GUI的程序，没有意识到这应该是一个服务器端程序，居然在出错的时候弹出对话框，试想这个24 x 7小时运行的程序谁会眼睛一直盯着它和它交互呢，呵呵。这也是在出错的时候导致挂起的直接原因。

但是导致DeleteFile失败的深层原因还需要继续查找。经过和联通工作人员商量，决定做一次升级，增加后台日志，以便查到'幕后真凶'。

像联通这种效率不高的公司，做一个小小的升级走的流程都要耽误几天。这不昨晚才把升级程序替上去。上午我们技术支持人员将后台日志发给了我，打开一看居然是一个叫'autorun.inf'的文件导致的删除失败，通过FormatMessage和GetLastError配合得到的原因是"拒绝访问"，显然是这个文件的权限很高，即使用管理员权限也无法删除，甚至我们在屏幕上根本看不到这个文件的存在，只是通过Win32 API才能找到这个文件。这时我们的技术支持发来信息说：在网上查了一下，autorun.inf可能是病毒或者是木马；一句话点醒梦中人啊，我也在网上搜索了一下，的确这个autorun.inf是病毒的产物。这时我的同事又发过来一条信息说：联通人员确认过了他们的这台PC服务器居然一直在'裸奔'，就是没有安装任何防毒软件。我晕！

对这些运营商我就不再做太多评价了，地球人都知道。

通过这次事件我们也可以看到：实际软件运行时产生的问题真是多种多样，防不胜防啊。其实不考虑其他原因，我们的软件本身如果做的更好些的话，也是可以避免上述问题的发生的，细节我就不说了。