自从去年年初搬到新办公室后，各个项目组都分到了各个独立的空间了，平时'抬头不见低头见'的情形减少了，随意拉把椅子坐下来谈技术的情形也减少了，随之而来的是项目组'各自为战'，经过近一年的发展，各个项目组在局部的发展上已经出现差异了。
在现在带的这个项目之前，曾经有意识的去了解了一下其他组的技术发展情况，主要是针对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."
评论