这篇《七十五条》原本是我写在自己的一个另一个Blog上的（http://www.blogcn.com/blog/cool/main.asp?uid=mvm&id=775872），但完全是纯技术的，所以在这里重新贴一下。的确也希望我在这里面表达的想法能够被更多人借鉴和讨论。
这七十五条，是我这些年来，尤其是在微软工作两年来的体会的总结，关于如何用正确的方法来写出质量好的软件的体会的总结。或许看似平淡无奇，但大音希声，这七十五条的效用，未必及不上那几十页几百页的体系，却远远比那好用：
1. 你们的项目组使用源代码管理工具了么？
2. 你们的项目组使用缺陷管理系统了么？
3. 你们的测试组还在用Word写测试用例么？
4. 你们的项目组有没有建立一个门户网站？
5. 你们的项目组用了你能买到最好的工具么？
6. 你们的程序员工作在安静的环境里么？
7. 你们的员工每个人都有一部电话么？
8. 你们每个人都知道出了问题应该找谁么？
9. 你遇到过有人说“我以为…”么？
10. 你们的项目组中所有的人都坐在一起么？
11. 你们的进度表是否反映最新开发进展情况？
12. 你们的工作量是先由每个人自己估算的么？
13. 你们的开发人员从项目一开始就加班么？
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
15. 值得再多花一些时间，从95%做到100%好
16. 登记新缺陷时，是否写清了重现步骤？
17. 写新代码前会把已知缺陷解决么？
18. 你们对缺陷的轻重缓急有事先的约定么？
19. 你们对意见不一的缺陷有三国会议么？
20. 所有的缺陷都是由登记的人最后关闭的么？
21. 你们的程序员厌恶修改老的代码么？
22. 你们项目组有Team Morale Activity么？
23. 你们项目组有自己的Logo么？
24. 你们的员工有印有公司Logo的T-Shirt么？
25. 总经理至少每月参加一次项目组会议
26. 你们是给每个Dev开一个分支么？
27. 有人长期不Check-In代码么？
28. 在Check-In代码时都填写注释了么？
29. 有没有设定每天Check-In的最后期限？
30. 你们能把所有源码一下子编译成安装文件吗？
31. 你们的项目组做每日编译么？
32. 你们公司有没有积累一个项目风险列表？
33. 设计越简单越好
34. 尽量利用现有的产品、技术、代码
35. 你们会隔一段时间就停下来夯实代码么？
36. 你们的项目组每个人都写Daily Report么？
37. 你们的项目经理会发出Weekly Report么？
38. 你们项目组是否至少每周全体开会一次？
39. 你们项目组的会议、讨论都有记录么？
40. 其他部门知道你们项目组在干什么么？
41. 通过Email进行所有正式沟通
42. 为项目组建立多个Mailing Group
43. 每个人都知道哪里可以找到全部的文档么？
44. 你做决定、做变化时，告诉大家原因了么？
45. Stay agile and expect change
46. 你们有没有专职的软件测试人员？
47. 你们的测试有一份总的计划来规定做什么和怎么做么？
48. 你是先写Test Case然后再测试的么？
49. 你是否会为各种输入组合创建测试用例？
50. 你们的程序员能看到测试用例么？
51. 你们是否随便抓一些人来做易用性测试？
52. 你对自动测试的期望正确么？
53. 你们的性能测试是等所有功能都开发完才做的么？
54. 你注意到测试中的杀虫剂效应了么？
55. 你们项目组中有人能说出产品的当前整体质量情况么？
56. 你们有单元测试么？
57. 你们的程序员是写完代码就扔过墙的么？
58. 你们的程序中所有的函数都有输入检查么？
59. 产品有统一的错误处理机制和报错界面么？
60. 你们有统一的代码书写规范么？
61. 你们的每个人都了解项目的商业意义么？
62. 产品各部分的界面和操作习惯一致么？
63. 有可以作为宣传亮点的Cool Feature么？
64. 尽可能缩短产品的启动时间
65. 不要过于注重内在品质而忽视了第一眼的外在印象
66. 你们根据详细产品功能说明书做开发么？
67. 开始开发和测试之前每个人都仔细审阅功能设计么？
68. 所有人都始终想着The Whole Image么？
69. Dev工作的划分是单纯纵向或横向的么？
70. 你们的程序员写程序设计说明文档么？
71. 你在招人面试时让他写一段程序么？
72. 你们有没有技术交流讲座？
73. 你们的程序员都能专注于一件事情么？
74. 你们的程序员会夸大完成某项工作所需要的时间么？
75. 尽量不要用Virtual Heads
打印 | 张贴于 2004-05-19 18:32:00 | Tag:Software Engineering
留言反馈
不过我觉得能减少开发人员是质量好的最好保证。
就像mvm举的例子（对不起，我没有看到罗亭的帖子，或许罗也贴过的，要事看到，我就两个一起贴出来）：例子1，航空订票系统
今天上午去公司的Travel Desk订星期五回上海的飞机票，结果很让我高兴：买到了5折的。要知道，前两个月，7折都是很罕见的。订票的时候，我仔细观察了一下那个终端：是在Windows上开了一个绿色的字符终端，直接敲命令查询航班，返回结果也是一行行的字符输出。返回的结果我是看不懂的，但Travel Desk的人就能看懂：他一眼就能看出有多少折扣，还有没有位子。而我只看到一串不知道什么意义的英文字符。
从纯粹的技术人员的角度来看，这种Client端显然是应该被淘汰的：操作不是GUI的而是Cmd Line的，查询是通过命令字符串而不是一个友好的Query Builder界面，返回结果也很不friendly。但我觉得这样的界面是很好的，因为它的用户已经习惯了用这样的界面，而且根据我的观察，Travel Desk的人操作起来很快，他们也能毫无困难的理解那些我无法理解的返回结果。所以，如果我是技术主管，我一定会反对任何把这种界面升级到GUI的提议。我的信条是：没有充足的理由，不要改动正用得好好的东西；没有充足的理由，不要引入新东西。
从客户的角度来看，即使你的代码质量再高，客户不需要的东西，本身就是一个致命的错误，质量已经没有存在的意义。所以客户需求是第一个要素。
那么，是不是流程就可以保证质量了呢？流程再完美，也需要人去执行，那么好了，如果你觉得流程的某些地方需要评审，那么评审本身是否需要评审呢，这样就会进入一个死循环，所以，不能过分倾向于流程。在一个公司了解了客户需求之后，就会和企业目标一起考虑，设计自己的战略发展方向，配备合适的人员，其中的领导者、员工都具有相当的执行能力，尤其是细节的执行能力。
上面其实说的过于简单化了，但是我想在bbs上，也只好说这么多，否则我的任务就不能完成了，厚厚。
预想的答案应该是“yes”吧。
这边有个小问题，75点里，有些问题的正确答案应该是yes（第1，2点），但有些的正确答案应该是no(第27点），未免让人有些困惑。高手当然无所谓，但是低手也不会在少数吧。
也许会被说，所有的问题答案都是显然，但其实并非这样。比如第10点，究竟是yes还是no呢？传统的想法也许是yes，但是实际上应该是no啊。
所以为了避免大家瞎猜，还是由MVM公布一个标准答案吧。
我倒是觉得mvm一直在摆事实讲道理，你却“很遗憾”或是“不想说”，道理越辩越明，别人一反驳就这样还不如当初不要辩，要么就是真的说不出什么了
别的我就不想说了。
75条太多了，其中有轻有重，能不能归纳一下将最重要的和最通用的总结在30条以内岂不是更实用
交流,当别人同你说,"你可以这样这样的时候",你会怎么样反映呢?
1.完全听不进去
2.说"你的这个办法不错,我们可以试试看,不过我这里也有其他的想法...."
我想mvm提供了一种想法,我们每一个人都有想法. 但是如果不能听取其他人想法的话,这个交流就没有意义了. 万事并无绝对.
2. 这些经验不杂乱。不“杂乱”的是教条，“杂乱”的才是经验。
3. 你敢说你理解质量的精髓？
4. 我用Code Review的说法更多。
Google搜索结果：
约有 20,700 项符合"code inspection"的查询结果
约有 124,000 项符合"code review"的查询结果
哪个术语更通用，一目了然。
5. CSDN上有很多这样的板砖。文人相轻。
6. 山外有山，我相信一定有高手。真正的高手看到后辈，不会说“你还差得很远”
7. 本来就是一种知识分享，为什么一定要把别人分享出来的东西说的一钱不值？
请注意，CI与代码规范是两码事。
这么说吧：当您邀请别人做CI时，作者有义务首先确保它的代码已经符合代码规范。否则，CI会被取消，直到您已经首先确保这一点为止。这就好象，一个人拿了一段代码去做CI，但这段代码竟然还没有被编译过一样。
这么做的原因只有一个：已经成文的规范，不会有人对你说第二遍。而且，这浪费别人的时间。（请注意：这些应该被定义在CI的流程中）。
我感到遗憾的原因是：您已经有了如此多的经验（这些经验都不错，只是太杂乱），却仍没有理解质量的精髓，让人遗憾。
随便举几个例子：
“9. 你遇到过有人说“我以为…”么？”——如果遇到，这就是spec review的流程出问题了。
“12. 你们的工作量是先由每个人自己估算的么？”——自下而上，还是自上而下，经验法还是专家法还是三分法，这就是plan的流程。
“18. 你们对缺陷的轻重缓急有事先的约定么？”——这是缺陷管理的流程。
“40. 其他部门知道你们项目组在干什么么？”——cross team communication的流程
“44. 你做决定、做变化时，告诉大家原因了么？”——变更管理流程
“57. 你们的程序员是写完代码就扔过墙的么？”——关于Test Release Document的流程
Btw，“63. 有可以作为宣传亮点的Cool Feature么？”看似和质量无关。不过按照我的经验，cool feature的作用是“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。你想想，很多人经常说“微软的系统不安全，不过很好用”，其实这就是一例。
难道这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。在看懂别人的意思之前，千万不要轻易的轻蔑的说“你不懂”。
你提出的源自德国生产流程的两条经验也很不错，但同样也不能说明只要遵循这两条就可以了。那美国、日本、欧洲其它国家的企业数百年来也积累了属于他们的很棒的经验呀。他们看了你的评论后可能会很不服气呢。
个人看法，仅供参考：）
而且，竟然也没有包括文档的审查？文档的规范？竟然也没有包括设计的规范，没有指出做事（任何事，比如包括你去端一杯水）的流程？
我认为，上述75条应该全部抹去，因为它们杂乱无章却没有主题，一个质量好的软件与什么 "有可以作为宣传亮点的Cool Feature么？" 我想是应该完全没有关系的。
如果你想做一个好的软件，你只需要遵循以下2条简单原则即可
1、你为什么要这么做？你的依据是什么？ ----指流程
如：你为什么要写这函数？你为什么要改这文档？
2、你做的对吗？质量好吗？
如：性能高吗？完全满足需求与规范吗？ ---指审查
以上2条完全适应于所有的人员，包括设计，编码，测试人员，所有的人均要遵循上述原则。
它们可以用一句话来解释：做事要有流程，做完后有人检查，OK。
如果按照以上2条进行，我保证（100%保证），你的软件的质量绝对是好的，因为这种保证来自于德国数百年的生产流程（ 不信我，但你一定要相信德国货）。
我反对上述的75条是因为75条本身并不知道它想要说明什么，而是即兴发挥。以致第75条: 尽量不要用Virtual Heads 与上下文不符而没有检查。它没有说明质量的核心就是流程！也就是说，你完全做到了上述的75条，你的项目的质量也可能是不好的。
因此，放弃75条，回到家中，制定流程（如果没有），按流程工作，然后审查是否遵守了流程。
很多人可能会觉得我的回答比较可笑或不可以理解，我只能感到遗憾。