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

刚刚开完会，公司需要制订一个适合自身特点的开发流程，讨论了几个小时，初步的雏形已经有了，但仍需细化到一个有形的东西（ps:总经理总想看到一个实实在在的东西）我也不知道如何才算有形，有这么几个疑问，欢迎大家讨论！

1。测试里的测试用例，测试点，大家是怎么写的，或者说具体到每个项目，又是采用什么方式来操作的；

2。测试里的易用性测试（从用户的角度考虑软件操作及主要功能的体现是否方便易懂），这个是否有必要；

3。软件开发流程步骤真有必要形成一个有形的东西吗？打个比方，软件开发流程好比水，现在我们讨论的是需要有一个容器把水给装起来，要设计的是这个容器，不知道这个比方恰当与否（我指实现它的步骤，而非该做什么）


我的观点：有必要；
同事观点：没有必要，理由是按照正确合理并充分体现用户需求的设计出来的就应该是易用的，所以没有必要。

大家认为呢？

我觉得这是实实在在的工作，呵呵，比讨论CMM强 

这里有一个极端重要的问题被你忽视了，那就是实施的成本问题。我提倡我们要以一个商人的实用角度来考虑问题。尤其是如果你做一个 PM，你要清楚自己可以动用的资源（人力、财力、时间），时时刻刻要把成本意识放在头脑里。不能笼统地认为 CMM、RUP、XP 等等都是软件工程，所以都是好东西。这样的话表面上不偏不倚（也是最容易说的），其实是很大的误导（我并不是说有意，只是说你了解得还不够深入）。其实 CMM、RUP、XP 三种软件工程范畴的概念在核心实质上有极大的差别（我说的 CMM 包含相关的 PSP/TSP，这些才是属于过程的内容，与 RUP、XP 才有可比性）。
CMM 我只读过 CMU SEI 的教材，PSP/TSP 同样读的也是 SEI 的教材。尽管只读过一点点书，甚至大部分内容都没有读完，读完的内容也只是囫囵吞枣，但是我仍然认为我比某些人更清楚 CMM 是什么东西。o6z 老兄除了读书，更是完整地思考过 CMM 的整个思想体系和实施过程中会产生的各种问题。我的朋友 xel 对 CMM 研究的也很深。以前我和他在另一家公司是同事。当时（两年前）公司的 CEO 问我，我们如果开发一套 CMM 实施方面的软件（就是 jlinux 所做的那种项目管理软件）会不会有市场？我当时很迷信 CMM，没怎么思考就回答肯定会有市场的，因为 CMM 就是整个软件业的方向。CEO 跟我说我们马上要来一位新同事，对 CMM 非常了解。这位新同事就是 xel。我最初以为他是类似于 xx 博士、xx CMM 实施顾问一类的人，没有多少实践经验，但是后来发现他在算法方面有很高的造诣，这时候才真正地佩服上他。幸运的是我们后来并没有去做这个 CMM 实施软件。xel 现在仍然和我在一起，但是已经绝口不谈 CMM 了（以前他也很少谈，更多地是谈具体问题的解决方法。他觉得你和我谈某方面的问题时我就只和你谈这方面的问题，把问题谈深入，针对这个具体问题提出最佳的解决方法。而不是你和我谈东我偏要和你谈西，以显示出我确实比你广博和高明得多。他认为这是很丢人的事情，凭他的能力完全没有必要这样做。任何问题都是可以研究清楚的，没有什么神秘主义。典型的一个研究型人才）。为什么？因为我们对 CMM 有了更深入的理解。

很多反对 CMM 的都是对 CMM 非常了解的人，这不是偶然的。再谈到成本问题，CMM 是让我们花钱的，而以 XP 为代表的各种敏捷开发过程（简单地称为 XP，其实不光包括 XP）如果我们能认真做好的话可以帮我们赚到钱（至少不会有什么坏处，重构会有坏处吗？单元测试会有坏处吗？迭代会有坏处吗？即使仍然是假药也吃不死人的）。一个简单的 ROI（投入/产出）分析就使 CMM 与 XP 有了天壤之别。请大家仔细体会《源代码就是设计》中说的好的软件工程和坏的软件工程的差别。CMM 如此复杂和代价高昂，一个最直接的威胁就是使我们的关注焦点离开了对于我们最重要（生死攸关）的问题——建造市场最需要的、创新的应用软件。因为我们每个人总是倾向于认为最复杂的问题就是最重要的问题，那么既然有这么多名专家、名教授都在追捧 CMM，而且这个 CMM 看起来是如此华丽，似乎就是任何软件企业多年以来苦苦追寻和梦寐以求的东西，显然通过更高级别的 CMM 认证就是软件企业的核心任务。对于员工来说，我只要把文档写漂亮，严格遵照模版，我就是一个好员工。这就陷入了 o6z 兄所说的文牍主义的泥潭。最后一个富有创新精神的企业蜕变为一个保守、不愿意承担任何风险的官僚机构。可是什么样的软件才是值得我们建造的软件？TDM 大师说的好，只有那些足以使你们的 CMM 评级降低一级的软件才是值得你们建造的。市场真正需要的软件大多是别人没有做出来的。满世界的人都会做了你还有钱可赚吗？按照 CMM 的观点，Windows 这样的产品根本就不应该出现，因为 M$ 开发 Windows 直到第 3 版才取得了成功（市场的响应），这样的巨大风险是一般人无法想象的（好在那些年 M$ 还有一棵摇钱树 DOS）。

我并不是说 CMM 中的思想全都不好，CMM 中很多思想（例如 PSP 提倡开发人员自己为自己做计划）都是非常好的。但是把 CMM 作为宪法性质的东西（《人件》中称为“大方法论”）确定下来、甚至把整个公司的前途押在 CMM 之上是绝对错误的。CMM 最有害的就是它基本上是基于瀑布式模型的，而瀑布模型会造成软件开发成本的提高和工期的拖延。为什么？如果现在你还要问这个问题说明你完全没有仔细看《源代码就是设计》这篇文章，以及 o6z、potian 等老师以前发的帖子。还有一个问题是文档驱动，就是一切以文档为中心。这为什么是荒谬的也请你仔细读完《源代码就是设计》这篇文章。CMM 企图以一种大方法论把开发人员的一切行为规范起来，整齐划一。似乎这样就能建造出高质量、创新的软件产品。这是非常荒谬的，只会使人们思想僵化，阻碍创新的出现。这又回到了一个老问题上：软件公司真正需要的是什么样的人才？是那种没有个性、唯唯诺诺、一点不敢犯错、文过饰非、对上司必恭必敬的人（千人一面，即插即用的 peopleware）呢；还是有个性、有想象力、勇于承担责任、不怕犯错（做得工作越多犯的错也越多，这是必然的）、勇于进取的人？凭常识你就可以回答出，肯定是第二类人，第一类人似乎更适合待在机关里。软件领域有什么是永恒的？变化才是永恒的，所以我们需要拥抱变化。CMM 能帮助我们拥抱变化吗？CMM 可能是所有软件工程里最害怕变化的了。为什么，想想 CMM2 的名称：可重复级。可是技术的发展是日新月异的，可能下一次我们即使做相同类型和规模的项目或产品时已经在用更新更好的技术了，那么这还是“可重复”的吗？是不是在自欺欺人啊？“软件蓝领”这个说法也是直接来自于 CMM 的思想。我们难道还需要让这些错误思想毒害刚走上工作岗位的、朝气蓬勃的年轻人吗？
CMM 为什么是错误的，请看《人件》中精辟的论述以及我以前贴过的《程序员》杂志对 TDM 的访谈（直接搜索 TDM，发帖人为 dlee）。

可能大家看得都已经很累了。我说了这么多，不是为了证明我是就一个软件工程方面的奇才，只是为了讲明白一些道理。我其实对于这类讨论非常不感兴趣，以前曾经建议我公司的开发人员少读一些软件工程方面的书（软件工程分成两大块，技术和管理，我是说少读些一些管理方面的书）
如果你跟我具体谈谈某种设计模式的作用、适用的场合，如何对一段代码做重构，我会感兴趣的多。而你在我心目中的地位也会比 xx 博士、xx CMM 实施顾问要高得多。这里还有一个幻觉是认为 CMM 提高了软件的开发效率（可能国内的很多情况是，越是认真起劲地实施 CMM，开发效率越低。这没有什么好奇怪的，CMM 教材中早就说过了，达到 CMM2 级是会降低开发效率的。不过这里还是假设你们实施 CMM 后提高了开发效率）。这绝对只是一个幻觉，真正提高开发效率的是开发人员经验的积累和技能的提高（对于技术和工具掌握得更加熟练，认识更加深刻），以及采用更好的技术和工具造成的，而不是 CMM 本身。这归根结底还是“人”的问题，你如果硬要把它归功于 CMM 我也没有办法。

关于我们需要什么样的文档，在《源代码就是设计》这篇文章中已经说得很清楚了。o6z 兄也说过这个问题，就是自文档技术。“代码即文档”，“代码即设计”这两种提法表面上很极端，但是其实是业界多年来成功开发软件的经验总结。我基本上同意这两个说法。但是为了让代码真正成为文档我们还有大量的工作需要做，增加代码的可读性，通过重构消除重复，得到更加容易理解的结构。这些说来容易，难的是要落在实处，真正做好。大家共同努力吧。

由于我们目前还没有开展很全面的单元测试，所以谈不出很多经验，只谈谈我目前的一些想法。
1、要写好测试用例，首先要写好用例（UseCase）。用例是软件设计、开发和测试共同的基础，这是用例驱动的基本思想。《编写有效用例》是很好的指导。如果用例能够写的很细，将项目充分分解为一些可以并行完成的功能用例，那么针对这些功能用例再写测试用例就会简单很多。第一步可以先做好功能测试，我说的就是 HTTPUnit 所能做的事情。针对每一个用例编写测试用例，每一个业务上功能（特性，feature）都要测到。
当然用例不可能一次写完，在迭代式开发中可以一次迭代完成几个用例、下一次迭代再完成一些用例。以后根据用户的反馈，还需要添加一些新的用例和测试。这里说来简单，但是对于 PM 在任务分解上的能力要求是非常高的。任务分解一定要做得足够细，并且能看清楚其中的依赖关系和瓶颈，还要根据不同开发人员的开发效率估算出他的完成时间（因人而异，估算不能任意，最好先让开发人员自己先做估算，不能采用命令式。而且要根据他以前的工作日志来做估算）。
如果用例写好，再为每个用例写好测试用例，有时候还需要把几个用例合在一起测试，用 HTTPUnit 写好自动测试代码，全部运行正常，这就为今后添加新功能和进行重构打下了坚实的基础。

这种测试方法只适合于不是很复杂的项目的开发，对于框架、可重用组件的测试要复杂得多，因为框架刚设计出来时还没有客户代码，所以很难采用 HttpUnit 来测试，这时候就必须用 JUnit 来进行更低层次的白盒测试。我目前还没有多少经验，我们可以以后探讨。

2、易用性测试一定要有最终用户参与进来，完全由程序员自己来测试是不行的。当然可以在多次获得用户反馈后自己制订出一些标准。我来举个最简单的例子，比如用户在你的网上商店注册一个帐号，某些必填的信息未填写，返回到原先的注册页面，这时候就应该保留他以前填写的所有内容，如果这些内容全部丢了，必须由用户重新填写，那么这个系统无论如何也不应该被看做是易用的。
易用性测试是非常重要，对于什么是易用性要建立在以前做项目时用户反馈的基础上，平时要注意收集这些信息。

3、软件开发流程非常有必要有一个有形（成文）的东西。目的是什么？还是为了改善沟通。大家在已经形成共识的前提下就不必再为一些早已搞清楚的问题而争论不休。这个作用就象是设计模式，你知道了 Abstract Factroy，我就不需要告诉你这个模式具体是怎样实现的了。沟通方面的成本是软件开发最大的成本，成文的东西就是为了降低这些成本。但是这个流程绝对不能过于繁琐。另外如果新员工到来了还要给他讲清楚为什么我们要采用这样的流程，这样做有哪些好处。他只有真正理解了，才能自觉地按照这个流程去工作。
我来举个例子，向 CVS 中提交代码，就非常有必要制订一个制度，不能随便想怎么提交就怎么提交，那样肯定会影响到别人的工作。

看了dlee的分析，解惑，思路比较清晰了，也明白为何老总想将软件开发流程融入自身特点并最终形成规范的目的（这周还要具体讨论并细化乃至成文）。



我认同这个观点；



我就是这个观点，可当初开会讨论时，我一时也举不出好的例子，因此也对自己的想法抱有怀疑，特别是自己经验不足的情况下，如何进行测试，的确需要积累，也要结合大家好的经验。




目前自己还没有这种基本思想，因此很有必要看看你推荐的《编写有效用例》一书并将其用到实际项目中，这样，思想才能活用。

欢迎大家继续讨论，感谢dlee，多多共享你的经验  

对于什么是软件的易用性，可以看看这本书：
《软件创新之路——冲破高技术营造的牢笼》
http://www.china-pub.com/computers/common/info.asp?id=1803

作者是 VB 之父，人机界面设计的大师 Alan Cooper：

还有这里：网站设计的宗派
http://www.zdnet.com.cn/developer/design/story/0,1000001288,39045224-1,00.htm

这些资料仅供参考。

原来这篇文章在《敏捷开发》的附录里就载入了，我是前晚才看见了，尽管已经是3年前写的，依然具有前瞻性.

个人经历，我看到的ISO9000，都是走过场。CMM没有做过，大致的情形，也可以想象。IBM最近出过一次错误，韩国市场电子商务的价格出现问题，所以IBM的手提电脑价格显示成为100美金一台。所以内部调查为什么会出错。但是，检查的内容是：密码是否符合标准，有没有人非法使用生产系统，有没有运行病毒检查。明明是程序的错误，这么搞形式能查得出什么？另外，代码复查，用的是JTest，检查的是代码格式，包括注释应该在什么位置。这样的做法，绝对是符合程序的，但是，对于提高开发质量有什么帮助呢？一切都是上面的家伙拍拍后脑勺想出来的。这些人大多是销售出身，偶尔有一两个以前是搞技术的，现在也早都忘光了。

困惑中。

今天又讨论了一个下午，问题又回到了去年讨论软件工程的话题上去了。

Manager希望得到的是一个通用的软件开发流程，特别强调每一个步骤的具体实现，比方需求分析阶段，开会讨论，如何讨论，谁负责？该得到什么结果，是产生需求报告，需求建议方案，还是其它什么的；

程序设计阶段，又该具体实现什么？

这些在软件开发中变数极大，能通过几次讨论得出一个以不变应万变的解决方案出来吗？



我的观点是具体的项目得具体对待，按照软件开发流程的几个阶段是没有错误的，但有些项目可能不需要需求分析，概要设计，很可能拿到手的就是详细设计了，这种情况，那制订出来的解决方案就有很大的缺陷，换句话说就是缺乏弹性，真是。。。

最近总在考虑这些问题，欢迎大家多提宝贵经验。什么样的工作模式，才比较适合国内这种小作坊式的开发（目前这是事实）.

Dennis

很好办啊。
一切由他负责，一切由他组织，一切由他主抓，一切由他完成。最后让一切都叫他滚蛋。：）

我也想那么说来着，可不敢，那是老总开会来着！
也许我总想反驳，我认为目前还没有到那种能够建立完整体系的时候！

我们现在的团队还无法做到通过几篇文档就能达到默契的水平，我想在这个公司永远也实现不了,必要的交流是必须的，尽管开销有时会很大！