T
tuti
Unregistered / Unconfirmed
GUEST, unregistred user!
曾经泛泛地看过本叫《代码大全》的书，其他都没记住，只记得讲到一个类比的问题，
即“软件的开发”与 哪种人们比较熟知的事务有可比性，以便不熟悉软件开发的
人（各级管理层，客户等）可以得到个大致合适概念。很多人都把“软件开发”类比成
“房屋的建筑”，我也很同意这个类比。
在上海有很多在建的高楼大厦，路过那些工地，我常常会想：即便是100万行规模的
软件开发，难道就比造一幢10来层的楼难度更大吗？ 虽然也有劣质的楼房，但我武断
地认为，豆腐渣的软件系统要比豆腐渣的楼多得多。我常自问这是为什么。
我不知道，是否有刚入行2年的建筑工去主持厂房的设计建造。 但我知道常有
刚入行2年1年甚至几个月的人在担当软件项目的负责人。
我不知道，是否有心急的建筑商看不得设备的闲置，而在没有设计图纸的情况，就让
施工队开始建筑“商务楼DEMO”。 但我常看见，管理精英们看不得资源的闲置，而在无开发
设计的情况下，驱动开发团队先做个“商务软件DEMO”出来。
我不知道，是否常会有客户要求把3年的盖楼工程期，压缩到1年（新闻联播中到是常有）。
但我常听到管理人员心急如焚地要求把3个月的开发时间，压缩到1个月。
昨晚在看《非程序员》第9期， Alan Cooper的访谈里面有段对话(翻译稿):
smilemac: 例如市场压力、预算、管理水平等等，这些都可能造成项目时间限制，许多
产品是它们之间相互妥协的结果。
alancooper: “...市场压力，预算...”，所有的都是管理者掩饰他对程序不了解的借口。
看似偏激，但我觉得说得是一语中的，现实就是这么一个样子，无论你如何臆想它，或者
忽视它，现实始终还在那里。而真正要面对现实是很不容易的，因为现实总是残酷的。
而比现实更残酷的是，管理层往往都很激情洋溢地盘算着商业计划，他们信奉的是“跳一下
才能完成的计划才是好计划”，至于你原来能达到哪里他却并不清楚。而开发人员几乎都是
天生的乐观主义者，对于他们来说没有“Mission Impossible”。任务越是困难越含糊不
清，越能激发他们克服困难的热情和所谓的创造自由度。这有点象我们这些单身汉在灯光
昏暗的酒吧里看到一位线条突兀,衣着似露未露的性感MM，所激发得某种生理反应。而当
一个相信电脑能算命的客户+ 激情洋溢的管理人员+ 一个（群）乐观向上的开发人员，
基本上大概一幕悲剧的演员就全齐了，然后大家一起想象着项目会自然出落得丽质天成，
结果多半是“为什么受伤的总是我"。
抱怨了半天，又要提到软件工程了。目前有这样一种情况，
每次项目挫折总结的时候，上上下下都会说“这是因为没有执行软件工程的原因”。
这时候“软件工程”就象是个大垃圾袋，任何令人讨厌的东西都可以往里扔。至于什么是
软件工程，很多数人只怕只有个模糊的概念。多半自己也分不清“软件工程”和“幸福生活”
之间有什么区别。不少人站出来说：“软件工程就是要把开发中的一切文档化可交流可维护
，而不要搞心口相传。” “要出一些什么样的文档呢？” 有不少人沉默了，
仍然有一些勇敢的人站出来列出一串文件名列表，或者拿出“CMM”或“RUP”的文档模板来。
“那怎么才能填写好这些文档，并使这些文档的资料足以做为进一步开发的基石呢？"。
“...”一片寂静。角落里有几个声音说到“找个咨询公司来做方案，或找个行业专家”。
也许有人有这样的好运气，但对大多数项目来说，这几乎是要老鼠给猫去挂个铃铛,把一个
问题偷换成另一个问题。
为什么一幢幢楼能建起来，而一个个软件项目在泥潭中挣扎下去。我只能说与建筑
和其他产业相比，软件开发几乎没有工程。因为在如此短暂产业的时间里，还没有足够多的
失败与教训来让大家摸索出一条被广为接受的工程方法来。请注意，总结出一是回事情，
被大家知道是一回事，而被大家采纳执行就是完全不同的别的事情了。到幼儿园走一圈，
我们可能知道健康的孩子是什么样，但我们却不知道怎么才能生出并养育个健康的孩子来。
知道目的地，和知道如何到达目的地，也是完全不同的两件事情，虽然他们之间有关系。说到
这里，突然想起那些信誓旦旦要在多久时间里，通过CMM X 级的老总们，即便他们生过
孩子，只怕由于工作繁忙也没养过孩子。
出路何在呢？只有去试验、去试错，土法上马。代价是什么？代价就是痛苦与失败。
软件工程方面的试验是困难的。一个人一台机器1、2个小时就可以试出一个API的使用来,
而4、5个人1、2个月也未见得，试出一个工程方法的优劣来。而在一个新软件工程方面
的导入在初期，引起开发混乱度的增加也是很常见的，谁也无法保证某个别人行之有效的
方法就一定适合你的项目团队。况且，也很少有哪个老板愿意给你个项目试着玩。
难归难，日子还要过。有前辈说了：痛苦的经历是改善流程的源动力。
这里我推荐两本书,管不管用就看各人的造化了。
1.《软件需求》机械工业，书很薄，有操作性。薄书就能说清的事，为什么要去看厚书呢?
2.《软件创新之路》电子工业 . 程序写多的人应该看看。想以MS为模仿对象的人也该看看。
也许我们知道未来是怎么样，但不知道怎么样能活到未来。
鼠目寸光，挂一漏万，见笑见笑。
即“软件的开发”与 哪种人们比较熟知的事务有可比性，以便不熟悉软件开发的
人（各级管理层，客户等）可以得到个大致合适概念。很多人都把“软件开发”类比成
“房屋的建筑”，我也很同意这个类比。
在上海有很多在建的高楼大厦，路过那些工地，我常常会想：即便是100万行规模的
软件开发，难道就比造一幢10来层的楼难度更大吗？ 虽然也有劣质的楼房，但我武断
地认为，豆腐渣的软件系统要比豆腐渣的楼多得多。我常自问这是为什么。
我不知道，是否有刚入行2年的建筑工去主持厂房的设计建造。 但我知道常有
刚入行2年1年甚至几个月的人在担当软件项目的负责人。
我不知道，是否有心急的建筑商看不得设备的闲置，而在没有设计图纸的情况，就让
施工队开始建筑“商务楼DEMO”。 但我常看见，管理精英们看不得资源的闲置，而在无开发
设计的情况下，驱动开发团队先做个“商务软件DEMO”出来。
我不知道，是否常会有客户要求把3年的盖楼工程期，压缩到1年（新闻联播中到是常有）。
但我常听到管理人员心急如焚地要求把3个月的开发时间，压缩到1个月。
昨晚在看《非程序员》第9期， Alan Cooper的访谈里面有段对话(翻译稿):
smilemac: 例如市场压力、预算、管理水平等等，这些都可能造成项目时间限制，许多
产品是它们之间相互妥协的结果。
alancooper: “...市场压力，预算...”，所有的都是管理者掩饰他对程序不了解的借口。
看似偏激，但我觉得说得是一语中的，现实就是这么一个样子，无论你如何臆想它，或者
忽视它，现实始终还在那里。而真正要面对现实是很不容易的，因为现实总是残酷的。
而比现实更残酷的是，管理层往往都很激情洋溢地盘算着商业计划，他们信奉的是“跳一下
才能完成的计划才是好计划”，至于你原来能达到哪里他却并不清楚。而开发人员几乎都是
天生的乐观主义者，对于他们来说没有“Mission Impossible”。任务越是困难越含糊不
清，越能激发他们克服困难的热情和所谓的创造自由度。这有点象我们这些单身汉在灯光
昏暗的酒吧里看到一位线条突兀,衣着似露未露的性感MM，所激发得某种生理反应。而当
一个相信电脑能算命的客户+ 激情洋溢的管理人员+ 一个（群）乐观向上的开发人员，
基本上大概一幕悲剧的演员就全齐了，然后大家一起想象着项目会自然出落得丽质天成，
结果多半是“为什么受伤的总是我"。
抱怨了半天，又要提到软件工程了。目前有这样一种情况，
每次项目挫折总结的时候，上上下下都会说“这是因为没有执行软件工程的原因”。
这时候“软件工程”就象是个大垃圾袋，任何令人讨厌的东西都可以往里扔。至于什么是
软件工程，很多数人只怕只有个模糊的概念。多半自己也分不清“软件工程”和“幸福生活”
之间有什么区别。不少人站出来说：“软件工程就是要把开发中的一切文档化可交流可维护
，而不要搞心口相传。” “要出一些什么样的文档呢？” 有不少人沉默了，
仍然有一些勇敢的人站出来列出一串文件名列表，或者拿出“CMM”或“RUP”的文档模板来。
“那怎么才能填写好这些文档，并使这些文档的资料足以做为进一步开发的基石呢？"。
“...”一片寂静。角落里有几个声音说到“找个咨询公司来做方案，或找个行业专家”。
也许有人有这样的好运气，但对大多数项目来说，这几乎是要老鼠给猫去挂个铃铛,把一个
问题偷换成另一个问题。
为什么一幢幢楼能建起来，而一个个软件项目在泥潭中挣扎下去。我只能说与建筑
和其他产业相比，软件开发几乎没有工程。因为在如此短暂产业的时间里，还没有足够多的
失败与教训来让大家摸索出一条被广为接受的工程方法来。请注意，总结出一是回事情，
被大家知道是一回事，而被大家采纳执行就是完全不同的别的事情了。到幼儿园走一圈，
我们可能知道健康的孩子是什么样，但我们却不知道怎么才能生出并养育个健康的孩子来。
知道目的地，和知道如何到达目的地，也是完全不同的两件事情，虽然他们之间有关系。说到
这里，突然想起那些信誓旦旦要在多久时间里，通过CMM X 级的老总们，即便他们生过
孩子，只怕由于工作繁忙也没养过孩子。
出路何在呢？只有去试验、去试错，土法上马。代价是什么？代价就是痛苦与失败。
软件工程方面的试验是困难的。一个人一台机器1、2个小时就可以试出一个API的使用来,
而4、5个人1、2个月也未见得，试出一个工程方法的优劣来。而在一个新软件工程方面
的导入在初期，引起开发混乱度的增加也是很常见的，谁也无法保证某个别人行之有效的
方法就一定适合你的项目团队。况且，也很少有哪个老板愿意给你个项目试着玩。
难归难，日子还要过。有前辈说了：痛苦的经历是改善流程的源动力。
这里我推荐两本书,管不管用就看各人的造化了。
1.《软件需求》机械工业，书很薄，有操作性。薄书就能说清的事，为什么要去看厚书呢?
2.《软件创新之路》电子工业 . 程序写多的人应该看看。想以MS为模仿对象的人也该看看。
也许我们知道未来是怎么样，但不知道怎么样能活到未来。
鼠目寸光，挂一漏万，见笑见笑。