向大家推荐一文《源代码就是设计》

我就是从建筑转过来的，所以，我能都体会的更深些，这篇文章说的确实不错，还针对dlee说得补充一点，老外还善于总结自己的错误，避免再犯。

而国内的建筑乃至软件业，如果说当初2者还有可比性，那么现在根本就没有可比性了，但有一个共同点，那就是2者都不是在一个健全的环境里成长的，这点我想各位能看见，也能感觉到！

btw:oz6说的，我认为一点都不错 

感觉中国走表面，走形式的很多

没有真正理解！

blueblue
msf绝对是一种轻量级的方法，它的思想和敏捷非常类似，我们完全可以认为它就是一种敏捷方法。而IBM除了有CRM，还有很多别的方法，水晶就是起源于IBM，并且我知道有些团队在实施XP。而那些大公司的主要着眼点都是在人而不是过程上，这个和CMM推崇的过程中心是完全不同的。
而说CMM是五十年的总结，你就太高看它了。软件工程的年纪和我一样大，而CMM说总结也只是总结了IBM这样的公司1970年代的方法体系。但是现在的情况已经不同了，DoD已经不是我们的主要客户，我们也不会得到那些只要成功，不要求成本的合同了。而同时即使是CMM的体系依然解决不了质量问题，从几次NASA的重大软件失误就说明这个方法体系根本就是不能保证质量的监控。
而实际上研究CMM的发展历程就会发现，CMM有骗取DoD资金的嫌疑。而同时ADA事件实际也告诉我们，不考虑成本的纯学术成果，即使在某种政策的保证下也只能是勉强维持，但是政策永远是会改变的。而且我认为CMM根本就不能和ADA相提并论，至少ADA还提出了自文档的概念，CMM有什么？说印度人从CMM得到了什么，其实他们得到的就是单和面对客户的托词，当然现在还有新的东西，就是他们可以来中国和那些汉奸一起骗国家骗公司。

呵呵，现在印度人跑到中国来骗钱的越来越多了，毕竟印度的市场太小。还有一些清华之类的名校、名教授也跟着印度人一起骗钱。“教育产业化”，赚钱是天赋人权！我赚钱你能拦着吗？！

印度的塔塔来杭州招人，我去面试过，他们希望员工对EJB了解和掌握，再加上我的英语对话简直就是鸡同鸭讲，所以，哈哈。

我曾经还是公司通过CMM 3 的功臣 ，在两周时间内编造了大量文档、评审记录、会议记录等材料，紧张地应付印度评估师的问答。而我正是部门中CMM的最大反对者，记得当时我也曾拿出这篇文章做武器，无奈公司大局已定。原来还以为是我们来骗印度阿三，却不知是我们和印度阿三一起导演的一出戏。果然，评审一过，马上恢复原样。

悲哀啊！！！！！！！！！！！
好好的一个软件行业，偏偏赶上一个盲从和浮躁的年代。但是最让人厌恶的是那些为了利益不要良知的人。
君子爱财，取之有道。不是什么钱都应该取赚。其实阿三很聪明，他们搞的那一套很适合他们的国情。而现在他们又来国内把他们的那些多于的成本转嫁到我们这里，就是不知道最后我们的成本会转嫁给说。不过我知道现在通过CMM是国家给财政补贴的，所以最后还是落到老百姓的身上。
可惜我只是一个忙碌于市井，感慨于书斋的碌碌闲人，不能振臂一呼应者如云，更不能挽狂澜于即倒。只能在此哀嚎几声，算是表达良心没有灭绝。不过我从来都不害怕历史会成王败寇，让历史取唾弃那些人吧。至少当我们成为老人的时候，我们会告诉我们的后辈有那么一些人干过那么一些事。

我始终觉得CMM就像针对产品加工流水线的规范，用对了方向还是有用的，但是同样的工作规范用来约束产品设计师就不对了。很多国内的软件公司并不明白自己的定位，在CMM热潮中沉不住气，首先考虑的不是实施CMM能给公司的软件过程带来什么好处，而是对公司的产品销售有什么好处。其实这是一种短视的做法，说到底就是没有一种打造百年老店的考虑。

先影响我们周围的人吧。比如经常来我们这里的朋友对于这个问题会有一个比较清醒的认识。目前也只能这样了。

有人问如果不搞 CMM 我们还能搞什么？这些人其实是眼界太窄，除了 CMM 还有 RUP、XP、FDD、Crystal、ASD......
可以做的正经事多了。例如重构、自动测试，要真的做好，几个月就过去了。这些才是实打实的工作。

谈谈我的看法.
CMM,RUP,XP等软件工程的方法,我觉得都是非常难得的经验的总结,我们这里抛开国内一些做表面文章的做法不谈,那个是另外一回事了.单就说这些方法和规范是值得大家去思考和斟酌的,可以和自己做项目中遇到的问题对比一下,这样做是否合适是否有道理,验证这些原理和规范.对于以前没有经过的过程,可以结果过去项目中出现的问题和经验去判断是否使用,尽管可能结果是错误的,但是,会对这些方法和规范有更深一步的认识.
我们的公司并不很大,去完整实施CMM或者RUP简直就是去自杀.所以,最常使用的方法是从这些过程规范中选择出适合的步骤加以实施,如果开发过程顺畅了,那么保留,当然这样需要判断准确,否则回头的次数多了会让大家对软件工程逐渐失去信心.
对于文档和代码,我的看法是文档比代码重要,规范比代码重要,一个项目中总会有些不能规范书写代码的人,也总有些路走偏锋的人喜欢玩一些小聪明,把代码写的希奇古怪.的确,他的代码功能正确,完全符合设计要求,通过了测试,但是,如果要有人去维护它还的找个基础好的人来.项目人员水平参差不齐,只能由规范来解决问题.我想大家都遇到过文档和代码不一致的情况,回头修改文档对程序员来说是一件非常痛苦的事情,我自己也是这样.不管你怎样降低要求,简化文档,即便只要求修改用例图和时序图都很难让大家保持修改文档的热情,更不要说冗长的用例说明了.但是一段代码如果有了即使只有一个框图给出一个框架,我都能很快的阅读完.如果注释非常完整,那么细节也不是问题.否则,要花几倍的时间去了解代码的框架.所以,关键在于如何选择合适的文档形式,让大家尽可能承受的形式保持文档和代码的一致性.
另外,我觉得软件工程应该不单单是方法论,它对管理人员的要求也很高,规范很容易编写,但是人最难管理.如何保持开发团队的良好气氛,队员之间的默契和相互支持,这些无形的东西对一个项目的影响也是非常大.气氛不好的团队常常相互指责扯皮,尽管看上去象是在"评审".
写到这里,我想表达的意思就是不要全盘否定,也不要全盘接收,既然这些东西是大师们写的必然有它的道理,既然我不是一个大师,那么就把适合我的东西拿过来,一步一步的验证,也许有一天我也会成为大师,也许不是,但是这个问题并不重要,因为对于每一个结论我都有自己的理由去说明它而不是不知所以然.