我的关于软件工程的一些体会

软件开发最初就是写代码，为什么会变成一种工程？软件工程目前的状态还是处于初级阶段，比起建筑工程、机械工程这些有严格数学基础为支撑的科学，软件工程称为“工程”还很勉强。所以在目前阶段，你最好是采纳胡适的看法，把所有的理论都当作待证的假设。

我是程序员，我想更加安心地写程序，更好地满足客户的需求。但是我发现埋头写程序其它一概不管是不可能的，于是我求助于软件工程。但是尽管我关注软件工程，但是我最终的目的还是要更加安心地写程序。所以我相当于在走一个圆，我需要的是那种最后能让我走回来的软件工程，而不是学了一大堆软件工程和项目管理理论最后俨然成为这方面的专家权威，从此不再写一行代码到处贩卖管理咨询和《人间指南》。我今天是程序员，我一年以后还是程序员，五年以后仍然是程序员。我说的程序员不只是写代码，我可能主要去做设计，但是我仍然需要写大量的代码。Kent Beck 也仍然认为自己是一个程序员，你算什么！所以不要那么着急成为“非程序员”（我就是比你们这帮群氓要高，我已经不用写代码了！？）。

从这个目标来看，CMM、RUP 由于其庞大繁杂，最终都无法使我走回最初的起点，也就是说如果走这些重量级软件工程的道路这个圆是无法返回的。也许在大公司这是一条你走上仕途的必经之路，但是这些东西对于小公司无疑是一剂毒药。我不是没有大公司的工作经验，以前我所在的大公司也许比你们任何人在过的公司都要大，事实上它差不多算是中国最大的软件公司了，我的待遇也比现在好的多。但是，我不喜欢大公司，所以我离开了。

软件工程的学说很多，你不要一股脑地接受，而要有所鉴别。有些人很迷信各种大师，我则很少这样（也许我天生比较狂妄），我只相信胡适的学说。不管你是谁，你的理论都需要得到充分的证明，否则你就是在掏糨糊。别人承认你是大师，而我只认为你是普通的阿三。

如果说概念完整性对于软件产品的质量至关重要的话，那么概念完整性对于做人也是同样重要。对概念完整性不统一甚至相互排斥的各种理论不加鉴别全盘接受只会使你浪费很多生命，最终无法达到你所渴望的更高境界。说句不客气的话，最后你会死得很难看（你的大脑因为彼此矛盾的概念而死机了）。
Brooks、TDM、Kent Beck、Martin Fowler、Peter Coad 这些大师的理论从概念完整性的角度来说是和谐的、统一的，他们彼此存在着内在的一致性，相互构成了互补的关系。所以我建议如果学习软件工程，只读这几位大师写的书和他们的理论。如果必须要用到其它知识，比如 UML，再去学习相关的书籍。

再说一句，我不想贩卖《人间指南》，这些都是我自己的体会，仅供参考。可以根据自身情况决定是否采纳。

软件工程之所以只能勉强说是工程，因为它面向的人
其他工程面对的则是物
这就是决定性的差别。

人是多变的，不完全按照逻辑行事，软件开发注定是工程与艺术的结合体

我觉得还是遵循80/20原理好了，让工程、技术解决80％，剩下的就交给程序员吧

嘿嘿，美国人为什么在各方面都比我们高，就是落实在胡适先生的这句话上面。证明一个理论多费事啊，说说要容易得多。所以我从来不敢自居为研究者，还是技术商人更符合我的身份。

其实UP还是一个简单的过程，但是RUP则复杂多了，否则怎么卖那一堆昂贵的工具呢？我就见过和原始的UP，我看比XP也重不了多少。而且RATIONAL也在逐渐给RUP减肥，我有理由相信敏捷已经成为面向对象社区的主流声音。包括现在SEI的CMM领袖也在对XP这样的方法表示充分的善意，并且它在最新的版本中已经承认人是最重要的因素。这些无疑说明，世界正在敏捷化，而不是重型化。
而其实开发大工程完全可以使用FDD。它的第一个项目规模是这样的，3500个用例，一个数百个类的分析模型，包含了数千个属性。不知道那些所谓的说敏捷不能使用在大项目上的人开发的项目有没有这样的规模。这个新加坡项目团队有50个人（测试应该是另外一个地方在作），而且都是世界顶级人才，可见其管理水平要有多高。那些说敏捷的管理一团糟的家伙，有几个管理过这样的团队。而ASD和水晶可以算是最为数学化的逻辑严密的方法，而RAD的代表DSDM在世界范围的成功可以说已经是任何人都不能否认的。
实际上这些敏捷的思想来源不是按照一般人想象的小公司的黑客，而是IBM这样的大型企业。不是那些人们眼中的黑客，而是TDM这样的领袖。而我们在SEI已经转向的今天，还是走印度人的老路，真的让人费解。对于先行CMM的不满应该是绝大部分人的看法，所以SEI才推出CMMI，但是CMMI据说现在也不成功，很可能要回到CMM。这些无疑都是SEI在痛苦的改变自己，在迎合潮流。其实DoD对于敏捷生产和并行工程是做过巨大贡献的，这才是他的潮流，CMM这个逆流的东西，只是他庞大体系中不重要的部分。而且严格遵守敏捷方法的组织在我看来达到CMM3根本就不成问题，比如XP中的持续集成在我看来是现在SCM范围内的最高成就，在CMMI的体系下这个根本就知道应该放在什么地方，也许是8级的实践了。而XP的TDD可以说是最严格的质量控制体系，在加上最严格的PP和代码共享这样的代码评审手段，什么CMM可以做到这么严格的质量保证。在CMM追求千行代码BUG数的提高时，XP早就在讨论怎么提高黑盒测试水平以检查设计功能缺陷这样的高级话题。而大家看看FDD的彩色文档，看看什么CMM的问题体系比它还明确，比它还量化。看看FDD对于需求的量化水平和对于项目的管理的量化水平，是什么CMM4的企业能达到的。
现在一些人就是放着主流的东西不去搞，偏要搞一些落后，并且联创造者都承认落后的东西。真的让我不好发表什么评论，我只能认为他们的智力水平有问题。

呵呵，抛了一块砖，引得玉出来了，经 ozzzzzz 兄这么深入地一解释，我有茅塞顿开的感觉，将来的方向更加明确了。
以前还以为自己是另类呢，原来这些早就是业界主流的看法。我的朋友的爱人在加拿大滑铁卢大学计算机系念博士生，她也说学术界其实根本就不承认 CMM，CMM 在学术界的地位是非常低的。
我觉得无明说的也很好。我念博士生的朋友有不少，所以对于学校的情况还是略知一二的。

希望这些讨论对于刚出校门的朋友规划好自己的职业生涯能够起到帮助。

其实我看到的事实让我对于CMM还是抱有很大的希望的，其实我知道SEI也是在不断的改变他们的做法。比如CMM开始设立的时候也是为300人以上的企业准备的标准，现在不也可以用来作几十个人的评估了吗？不是也允许对于起作裁剪了吗？但是这个裁剪又往往给不怀好意的人利用。
问题还是在于SEI改变其标准的速度太慢，不能跟上形式。而学术界对于标准的不认同，早就不是新闻。可是SEI有DoD这棵树作靠山，也就是没有办法。可是当年ada语言的势力是不是比cmm大，可是现在你看看ada怎么样了？已经非主流了，天天被C和cpp抢市场。没有办法，我们这些老家伙看够了这些过眼云烟。

确实，象 CMM、ERP 这样庞大复杂的东西实施起来是不能不考虑公司政治的，往往会变成政治斗争的工具。到是象 XP、FDD、ASD 这些敏捷方法更加简单，目标明确，不容易产生歧义，给不怀好意的人可趁之机。
我第一次读 CMM 的时候也是带着一种非常崇敬的心理读的。CMM 的设计者也明确说一定不要把 CMM 当作千年不变的教条。但是问题是 CMM 过于复杂，设计者又没有给你提供裁减的依据，你知道哪些重要哪些不重要？只能全盘照搬，老虎吃天，感觉无从下口。而项目的工期明摆在那儿，万一没有收效，责任由谁来担？所以 CMM 的可操作性是非常低的，这也是为什么有那么多咨询机构产生的原因。果真这些咨询机构经验丰富而且认真负责到还罢了，万一又碰上一个掏糨糊的安达信，你就等着死翘翘了。

50 人以内的软件公司如果能管理好，是一种非常健康的状态，XP 完全可以应付得了。应该先练好内功，不必急于扩张。托普软件园一年招聘 5000 名软件工程师的神话居然也有人相信。你托普一年的产值能顶的上华为吗？华为都没有能力一年招聘 5000 名软件工程师。可见在软件业打鬼已经是非常必要，希望软件业也多出几个王海这样的人。

我用了很多可是可是其实其实，嘿嘿。原因无他，一些事实早就摆在那里，可是就是没有人关注。

软件行业还是不能依靠大公司，在美国是这样，在中国也是这样。市场和战略在大公司，技术在小公司。大公司出方向，小公司出产品。大公司以小公司为武器补剂战，小公司以大公司为人才储备所。大公司收购小公司来组织大舰队，小公司从大公司出来造战舰。小公司的兴亡才是软件行业的兴旺，现在国家只是把资源放到大公司是一种战略失误。比如今年联想的问题可以说就是国家政策的问题，要是它不扛民族大旗，不搞政府工程，不会像现在这样发不出奖金。
小公司可以开发出功能单一的好产品，大公司的优势在于可以把这些产品买下来组成一个互为依托的产品线。
而大公司的优势就在于可以提供一揽子解决方案，小公司的优势就在于可以提出具体问题的最优方案。
这也给我们的软件工程思想提出的根据公司规模大小，把握公司发展的方向的问题。而方法也必须适应公司的实际规模。管理不可以移植，方法其实也不可以移植。XP/FDD/UP都不可能移植，我们能作的就是吸取自己有用的营养，建造自己的方法。在我看来一个软件公司如果联自己的方法都没有，天天喊XP/FDD/UP根本就只能说明他们还不成熟。引进这些方法的实践是好的做法，但是如果不能在这些实践的基础上摸索出适合自己的方法就很有问题。毕竟我们有我们的具体情况，解决的问题也是我们的具体问题。
所以为什么现在CMM自己也在强调它只是一种标准而不是一种方法，强调可以通过多种方法达到其目标。而国内的一些人总是希望玩一些类似高考的把戏，希望通过同一的教材，同一的考试，考察出一个似乎是公平的结果。我们要作的就是掀起一个务实求稳的软件工程思潮，把前一个阶段的浮躁情绪打下去。先不在乎什么标准，而先考虑我们面临的具体问题，看看外国人是怎么解决的。看看这些方法究竟是如何运作的，然后在根据自己的具体情况制定一个适合自己的实践。而不是硬性规定我就要TDD，我就要以architecture为核心。有什么厨子就作什么筵席，而不是今天粤菜，明天历家菜，后天又谭家菜。最后其实吃来吃去，还是一个味道，还是你自己的菜。何必搞那些形式主义的命题呢？

确实，不应该照搬任何软件过程，而要借鉴各种软件过程中的一些最佳实践（就是我说的杂合多种过程的优点）。
说来说去，围绕的核心问题就是“如何能把产品更好地做出来”，这个更好含义是广泛的，更高的生产率、更好的质量、更高的客户满意度等等。不能解决这个核心问题的软件过程不是好的软件过程，所以 FDD 教材的开始就批判“为过程而过程”的荒谬。XP、FDD、ASD 不是真理，它们只是比 CMM 更接近真理。
比如我在读《人件》时就发现虽然这本书是我令我无限佩服的大师的著作，但是其中很多做法其实是不可以移植的。这本书在美国或者西方（“自由”世界）有普遍适用性，但是在中国就要有所取舍。中国的程序员从交流能力、主观能动性上比美国的程序员都要差很多，所以那种 PDP-11 老板叫停手下的人私下继续做最后成功了老板给他们发奖的情况在中国几乎不可能发生。

这些问题讨论起来还很复杂，今天时间不多，以后再做深入探讨。