第二章写完了，不过有关JUNIT的内容，放到后面再写吧，说不定就不要了。在国内对JUNIT看热闹的要比实际去用的多吧，用自动测试方式的开发思路，基本上每个类都要写相应一段测试代码文件，工作量是加了两倍都不至，如果不是项目经理强制推行，程序员谁会想用JUNIT呢？那不是自找苦吃吗？现在的项目都是做完就扔，有些项目甚至都结构一团糟，改都不敢改，更不用说去用JUNIT了。
我朋友的朋友，一个北京名牌大学的研究生和我聊天时说，他们导师以学校名义低价接下国家某部委的软件单，十个人左右做了六个月，原计划是1个月三个人搞定的，最后却.......。而且做完以后都不敢改，没有总体设计，没有规划，不用设计模式，扛着键盘就上，埋头就写代码。到最后用一根根木头勉强把房子搭起来了，看看和用户要求的样子表面是一样，但却是个危房，里面代码混乱不堪，注释少得可怜，客户要修改一个地方，sorry，不敢改，有bug，sorry不敢动，因为动一处而动全身，改了一个bug说不定就会出N个BUG......。这样的项目绝不少见，而且可以说很多很多。
做事都要估计得宽松一点，因为实际情况经常会超出预期，很多未知的事都会拖慢进度。我在IBM的项目有点这个味道，原定5月结束的项目搞到了9月，不过人数倒没增加多少，控制得很好。而且产品听Grolia说很得客户好评，满意度很高，听到真开心呀，软件都得到客户好评可是真不容易的一件事。
再回到说JUNIT，做一个长期产品的人都知道，开发软件的第一个版本不难，难的是后期维护升级。要能经得住不断的修改就要有灵活而强健的的设计，要保证质量，还要全面测试。测试是质量的关键，再优秀的程序员都会编出有BUG的代码，因为一个系统需要考虑的事太多了，总会有想得不周到的地方，所以测试是必须的。
在微软，一个软件要打包出版，任何一个BUG的修改都要做评估以决定：改还是不改。因为根据实际统计一个繁杂的系统，平均改一个BUG就会生出三个新BUG（不良设计和劣质代码则更糟），打包出版前一刻任何改动都是很危险的。如果决定修改这个BUG，那么修改完成以后，微软还会对此软件重新做一次全面的测试，以确定此次修改不会产生新的严重的BUG。
测试优先，这是长期实践得出的结论，也是JUnit得以发展的原因。要得到同一质量的软件，用JUnit，用3小时编程，10小时维护；不用JUnit，用1小时编程，100小时维护。你选那一种。当然是第一种不用JUnit了，因为国内的软件项目，一开发完成再做过初期维护就不再管了，要升级？OK，重新来过吧。呵呵，现状就是这样的。
