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

在现在带的这个项目之前，曾经有意识的去了解了一下其他组的技术发展情况，主要是针对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."

之所以再写这个话题，源于今天发生一个"小事件"。今天是主管绩效反馈的最后一天，我负责评价其中的三个新员工，其中一个员工对我的评价提出了'异议'。

为了这次'异议'，我安排了一次和他面对面的谈话，其实这次谈话早在其试用期结束时就该安排了，只是当时副部长替我把这个活儿做了。这位新员工去年年初到公司实习，实习后，带他的mentor给他的评语不错，以致07年中期他入司的时候我们对他期望很高，当然要求也比其他新员工高一些。但是半年的工作后，他给我的最直接感受就是"恨铁不成钢"，也许期望太高，失望就越大。这位员工各方面能力都不错，也爱钻研学习，但就是在'做事'方面显得不够'开窍'。这里的'做事'是一个抽象的名词了，无论在哪个行业，从事什么样的工作，其实我们都是在学习'做事'，把事情做好的原则都是一样的，无论在何岗位。试想一下，如果你是主管，你是领导，什么样的下属在你心中会占有一席之地呢？你可能会脱口而出：工作主动、态度积极、有奉献精神、能有效沟通、问题解决能力强等等。

恰恰与此相反的是：很多刚入司的新员工没有过职业素质的培训，他们不能够意识到这些，往往接到一个要求10天完成的任务，不拖到第10天他就是不完成。实际上你的上级在分配任务的时候都是带有期望的，虽然说了任务可以10天来完成，但是在他们的期望中，这个任务对于新员工可能6天就可以完成，剩余的4天是给这个新员工总结和消化用的，上级期望这位新员工能发现些问题，新员工在工作过程中肯定会遇到问题的，但如果这位员工视问题而不见，或掖着藏着，那么显然会让上级对他有所失望，好比我上篇文章中的小A。

一批新员工工作半年后，肯定会分出高低，当然也许不是技术上的，也许就是在我上面所说的'做事'上面有高低。这时还会有一个问题就是其他的新员工是否就发现了某个同伴在各个方面都已经领先了，他们是否意识到了要以这位优秀的员工作为目标，是否意识到自己的差距了呢？

在今天我和这位新同事的谈话中，我就发现了这样的一个问题：他自己并没有意识到自己和某些优秀新员工在各方面的一些距离了。也许他真的看不到，但是站在我这个高度，我有横向对比的条件。这样一来他没有意识到差距，他又如何给自己设立新年度的目标和改进方向呢？

在我的评语中，我同样也犯了一个错误或者说是经验不足导致。比如我使用了"xxx方面、xx方面需加强、在xx方面需提高"等等让人看了后感觉自己哪哪都有问题这样的评语，就是这个评语引起了这位新同事的'异议'。我在这方面的确欠考虑。下午，副部长给出了关于评语的建议：使用类似"XX、XX方面等都得到有效改进，还有更进一步提升的空间，期望能够XXXX"会让人更易接受。这种评价就是一种正面的鼓励性的评价，虽有一定的技巧性，但是又不乏诚恳，的确是值得我日后学习的。

如果生活工作中多些鼓励和赞扬，世界也许会变得更美好，更向上，更具希望。