• 4

东看西看，加上工作中的一些感触，产生了一些零碎的想法，记在这里。

1. 最糟糕的一些软件工程观念

Steve McConnell前两天到Redmond为他的新书Code Complete 2做宣传，有人在MS internal blog上记载了Steve McConnell的一些谈话内容。

He presented a list of "worst code construction ideas of the '90s and '00s".? He contrasted the '90s "spec everything up front" or "design for unknown requirements" with the '00s "spec nothing up front"? ideas, the '90s "uninformed use of the waterfall model" with the '00s "uninformed use of extreme programming", and the '90s "components will solve everything" with the '00s "outsourcing will solve everything".? This section of the talk wasn't spectacularly informative or maybe it didn't resonate since I haven't been subject to any obnoxious application of extreme programming and the outsourcing I've had knowledge of has been handled well.

我来翻译一下：Steve McConnell列举了'90年代以来最糟糕的一些软件工程观点。九十年代的时候，人们相信，之所以项目进行过程中出现需求变更是因为需求分析没有做好；九十年代，人们很重视在设计中的可扩充性，人们坚持认为项目就是严格应该按照“设计，开发，测试”的阶段进行，人们相信模块化开发，认为将来软件开发一定会变成搭积木。到了二十一世纪，人们走向另一个极端，认为应该抛弃一切软件过程模型改走极限编程，软件外包盛行，有人开始鼓吹设计无用论，提倡边开发、边设计、边修改，还有人迷信重构，反对做任何可扩充性设计。

就我来看，无论是"spec EVERYTHING up front"还是"spec NOTHING up front"，都是走极端。软件工程里面还有很多走极端的说法，比如有些人坚持认为，绝对不可以不做unit test。正确的认识世界、改造世界的方法是辩证唯物主义。对待软件工程也是如此。我们要辩证，没有绝对正确和绝对错误的；我们要唯物，要结合具体项目情况来操作，不能空谈一套方法论。

2. Continuously Integration?

前两天听到一个人讲Agile Development。他说到要做continuously integration。他举例说，在他们公司里有一个持续集成的环境。code base里面每一次check-in，这个集成环境都会做一个新build，一旦发现build break，就会报错，停止开发，直到找到build break的原因。

听到这里，我的Bullshit探测器响了：

1. 一次Build耗时几十分钟是很正常的事情，每一个check-in都做一次build，来得及么？
2. 在某些“复杂”项目里，比如开发的是一个3-tier的系统，需要在一个环境中才能运行起来。对这样的项目进行如此频繁的集成、部署、测试，都要做成自动化，成本上划得来么？
3. 一遇到build break就停止开发？难道十几个人几十个人都停下来等上一两个小时？
4. 对大的项目，怎么能等到做build的时候再来发现build break呢？应该先local build，然后再check-in，这样能确保正式的build不会break。

3. Test Driven?

Test Driven说，我们在开发一段新的code之前，就要把这段code的unit test写好；我们在开发一个新功能之前，就要把这个新功能的test case和test automation建好。我不同意。我同意在测试前必须根据Functional Spec写好Test Case，但我_不_认为我们_必须_写好test automation和unit test再开发。

假设PM的func spec说，我们要做一根圆的棍子。根据Test Driven，test开发了一个圆的套子作为测试。等到dev把圆的棍子开发出来以后，只要放到圆的套子里面套一套，就知道棍子是不是圆的了。但问题是，谁能保证套子本身是圆的呢？

Ok, 我承认上面这个例子有点抬杠。事实上，从鲁班开始，我们国家的木工就一直用类似的工具。比如，有直角尺。桌子腿和桌子面是不是垂直，用直角尺量一下就知道了。所以，在15%的时间里，我也觉得Test Driven有些道理。据说微软的产品组也在推广Test Driven。我不太清楚，至少还没推广到我这里。

4. Functional Spec不是法律条文

Dev和Test都要做spec review，确保spec中没有歧义、没有矛盾、说得充分清楚。Review的时候，dev要确保Functional Specification是“可开发”的，test要确保spec是“可测试”的。例如，spec说：“季度的客户满意率是每个月客户满意率的平均值”。对于这样的spec，

• dev和test不应该问：“每个月”指的是该季度的每个月还是从年初到当前所有月份。
• dev和test应该问：这是什么平均？是每个月满意率的算术平均，还是根据每月被调查人数进行加权。

Spec不是法律条文，不是数学证明。有很多东西要凭sense去review的。否则就会变成抬杠、挑刺。

5. 关于self-motivate

我现在处于一个很有趣的状态：我的people manager是A，在北京；但在Outlook里面，我的上级给B，也在北京；我所作的项目，在北京这边由C负责；我在项目里做测试，这个项目的测试主管是D，在美国；D太忙，把我的绩效考评交给E来负责，伊也在美国。可以说，我有五个上级，但这五个上级谁都只会关心我一点点，初工作的人遇到这种状况大多会士气很低落，会不适应被放羊。

正确的做法是自己对自己负责，自己管好自己，工作按期交付，遇到问题自己去找各种资源想办法解决，解决不了就寻求上级支持。不要去操心谁到底是自己真正的老板这种问题。操了也白操。