75条的评论

我个人觉得楼上的误解了，mvm提出此75条作为经验总结，便绝非强调按此75条行事即可万事大吉。对我们每个人来说，如果能从中提取到三五条与自己实践相关的经验加以改进或应用，那么可能就会起到非常不错的效果。

你提出的源自德国生产流程的两条经验也很不错，但同样也不能说明只要遵循这两条就可以了。那美国、日本、欧洲其它国家的企业数百年来也积累了属于他们的很棒的经验呀。他们看了你的评论后可能会很不服气呢。

个人看法，仅供参考：）

CI是什么？CI=代码审查？“I" stands for what? 我印象中，code review倒是有的。

难道这75条里面没有code review么？
请看第35条：“你们会隔一段时间就停下来夯实代码么？”。所谓的“夯实代码”，就是指阶段性的code review以及在此基础上的code consolidation。
再请看第60条：“你们有统一的代码书写规范么？”。Code书写规范就是code review的一部分工作。能说没有code review么？


“上述75条应该全部抹去，因为它们杂乱无章却没有主题”——那是你没有看出主题来。这75条的主题是这样的：
1-5: 工具
6-10：沟通
11-15：计划和进度表
16-20：缺陷管理
21-25：士气
26-30：配置管理
31-35：风险控制
36-40：又是沟通
41-45：还是沟通
46-50：测试
51-55: 又是测试
56-60：编码，developer
61-65：规划，envision
66-70：设计
71-75：人力资源

“它没有说明质量的核心就是流程！”——说这话的人，对软件质量的认识还停留在一个比较低的水平。看一下上面1-75各条的主题就可以发现，决定质量的因素太多了，绝非简简单单的一句“流程”就能概括的。

同样，简单化并不代表认识的水平高。“如果你想做一个好的软件，你只需要遵循以下2条简单原则即可”——流程和审查，谁都知道。但是怎么做才能保证流程有效呢？怎么做才能保证审查有效呢？CMM告诉了我们流程和checkpoint，但没有告诉我们怎么做，所以大家还是都不知道怎么做软件流程。

魔鬼就在细节中，这75条全部都是关于细节。

“75条本身并不知道它想要说明什么，而是即兴发挥”——75条不是即兴发挥，而是有条理的在总结。从上面归纳的1-75条的主题就可以看出，总结这75条的时候是遵循着一种思路的。我们要善于接受75条这种表达方式。就好像著名的祖尔(Joel)法则12条一样，并非大而全，而是一些best practice的总结。

“尽量不要用Virtual Heads”是不是和质量有关？当然有。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。所以说，virtual heads绝对是对质量有害的。软件开发中的人不能简单的按照labor、按照人月来算。一个dedicated的人，要强过两个只能投入50%时间和精力的人。

况且，谁都不是傻瓜，谁都不会认为有了75条就可以不要任何其他的软件工程手段。RUP之类的流程、各种code review、spec review，都是非常必要的手段；瀑布模型、螺旋模型、V模型、X模型等，仍然是软件工程的基础。这个世界上没有silver bullet：RUP不是silver bullet，CMM不是silver bullet，XP不是，Test-Driven不是，当然75条也不是。

最后，我想说的是我们每个人都要show respect。在看懂别人的意思之前，千万不要轻易的轻蔑的说“你不懂”。

btw, "放弃75条，回到家中，制定流程（如果没有），按流程工作，然后审查是否遵守了流程"——这75条恰恰就是流程，是流程里面的肉，而不只是一个骨架。

随便举几个例子：
“9. 你遇到过有人说“我以为…”么？”——如果遇到，这就是spec review的流程出问题了。
“12. 你们的工作量是先由每个人自己估算的么？”——自下而上，还是自上而下，经验法还是专家法还是三分法，这就是plan的流程。
“18. 你们对缺陷的轻重缓急有事先的约定么？”——这是缺陷管理的流程。
“40. 其他部门知道你们项目组在干什么么？”——cross team communication的流程
“44. 你做决定、做变化时，告诉大家原因了么？”——变更管理流程
“57. 你们的程序员是写完代码就扔过墙的么？”——关于Test Release Document的流程

Btw，“63. 有可以作为宣传亮点的Cool Feature么？”看似和质量无关。不过按照我的经验，cool feature的作用是“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。你想想，很多人经常说“微软的系统不安全，不过很好用”，其实这就是一例。

很遗憾。

CI = Code Inspection.

请注意，CI与代码规范是两码事。
这么说吧：当您邀请别人做CI时，作者有义务首先确保它的代码已经符合代码规范。否则，CI会被取消，直到您已经首先确保这一点为止。这就好象，一个人拿了一段代码去做CI，但这段代码竟然还没有被编译过一样。

这么做的原因只有一个：已经成文的规范，不会有人对你说第二遍。而且，这浪费别人的时间。（请注意：这些应该被定义在CI的流程中）。

我感到遗憾的原因是：您已经有了如此多的经验（这些经验都不错，只是太杂乱），却仍没有理解质量的精髓，让人遗憾。

1. 我没有说CI与代码规范是一码事。
2. 这些经验不杂乱。不“杂乱”的是教条，“杂乱”的才是经验。
3. 你敢说你理解质量的精髓？
4. 我用Code Review的说法更多。

Google搜索结果：
约有 20,700 项符合"code inspection"的查询结果
约有 124,000 项符合"code review"的查询结果

哪个术语更通用，一目了然。

5. CSDN上有很多这样的板砖。文人相轻。
6. 山外有山，我相信一定有高手。真正的高手看到后辈，不会说“你还差得很远”
7. 本来就是一种知识分享，为什么一定要把别人分享出来的东西说的一钱不值？