每天早晨都是坐公司的班车上班的，从家到公司大约需要40分钟，这段时间不短也不长。为了打发时间，也曾经想过要充分利用这段时间，我选择过听音乐、看书。但音乐听时间长了就听烦了；在车上看书时间长了还有些头晕，所以多数时间我还是选择"思考"。"思考"的同时，眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。

建筑物上的几扇"破窗户"，很多人即使注意了，也会不以为然。但是对于看过 Andrew Hunt 和David Thomas合著的"程序员修炼之道"一书的程序员们也许都会"见景生情"，因为在工作中身为程序员的我们时常(甚至总是)和"破窗户"打交道。

万事万物都是有其共同的规律的：建筑物上的破窗户、牙齿上的"小洞"、软件中的低劣设计、糟糕代码的等等，在其出现的初期也许并未显现出问题，但是如果你没有及时修复，建筑物上也许会出现更多破窗户、被丢了很多垃圾、被胡乱的信手涂鸦；牙齿上的洞洞越来越大，周围的牙齿也受到牵连，开始出现"小洞"；软件中低劣的设计风格被继承、糟糕的代码被复制并被散布到系统的方方面面，以至于到最后无法控制，或者是花费很大力气来修复。

面对"破窗户"，常有这样几类情形：
1) 无法识别"破窗户"；
2) 识别出"破窗户"，但不愿修复；
3) 识别出"破窗户"，有修复意愿，但"破窗户"难于修复，或者修复成本太高，或外部因素(时间、人员、成本)导致资源不足以修复这些"破窗户"；
4) 遇到"破窗户"，立即修复。
前两种情况，一个是水平问题；另一个就是职业素养问题了，这里不多说；我们常遇到的情况往往是最后两种，如果是最后一种，其实你是幸运的，多数这种情形下你从事的一个新的系统或者项目，没有太多的遗留代码，一切都在自己的控制之下，通过重构可以达到修复"破窗户"的目的；但是如果是第三种情况，那往往是最让人痛苦的-自己无法控制，即使有渴望有热情有能力去修复那些"破窗户"，但迫于系统庞大，业务复杂，时间有限而不敢轻易出手，更让人痛心的是，系统中"破窗户"的设计和代码渐渐传染给新人，新人在维护系统时就会"以丑为美"，继续在系统上"涂鸦"，引入更多"破窗户"。由此可见及时的修复"破窗户"还兼有"整治歪风邪气"之作用。

在有"破窗户"的项目上增量开发风险很大，特别是当系统业务复杂、架构复杂时，添加一个很小的功能都应谨慎，最好能有完善的单元测试Case做保障。说到单元测试Case，设计起来又谈何容易，特别是对于由C写成的复杂业务系统，C语言本身就缺乏足够理想的单元测试工具，或者说像C这样的语言好似天生就和"单元测试"的概念无法和谐共生。对于复杂的业务单元，我们很难或者无法从纷繁芜杂的业务逻辑中剥离，或者说还是由于代码设计上的"破窗户"导致的不可测性，让"破窗户"得以延续。除非管理层狠下决心，重写系统。现在开始觉得与编写上层复杂业务逻辑相比，能编写一个独立底层库或者实现某种算法算是幸福了，因为你会有一种"可控"的感觉，而不是写完代码心里发虚的很；至于在有"破窗户"的系统上写业务逻辑，那就会又多出另外一种感觉-无奈了。

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

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