| S | M | T | W | T | F | S |
| |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | 15 | 16 | 17 | 18 | 19 | 20 | 21 | | 22 | 23 | 24 | 25 | 26 | 27 | 28 | | 29 | 30 | 31 | | | | |
|
|
这是一封 2003 年 10 月 CnPack 开发组项目管理顾问 曹晓刚 兄在 CnPack 新闻组中写的邮件：
作者：Xiaogang Chao
很高兴看到好客同学的热情发言。如果我还没有猜错的话，好客同学还是一位学生吧？
首先，我从技术上面来回答你的一些问题。
如你所知，无论是Windows平台，还是Access,sql server，都是要付费的，而且你也知
道CnVcl项目是一个开放源代码并且免费的项目，所以是无法承担Windows平台的费用
的。这是系统使用LAMP平台的主要原因。其次，LAMP在灵活性、性能、特别是安全性
上，至少不比Windows+IIS的解决方案差。
第二，关于管理问题。CnPack作为国内Open Source开发的先行者，在项目管理上也进
行了非常好的尝试。关于CVS管理，我可以给大家描述一下国际上比较著名的一些小组
的管理实例：Apache的各个项目，代码捐献者之多可能超乎想象，但是他们具有CVS写
入权限的人却非常少。大家可以checkout APACHE的CVSROOT目录，里面有一个文件叫做
avail.（大家可以通过这个叶面访问：
http://cvs.apache.org/viewcvs.cg ... /vnd.viewcvs-markup）
可以看到，人数并不是很多。比如著名的Tomcat项目，代码有数十万行，开发者捐献的
代码不计其数，但是其CVS写权限者不过14人。那么他们是怎么管理的呢？
这样的小组都有一个核心团队core team. 只有这个核心团队才会具有写权限。这里要
澄清一个误解。并不是说这个core team就是水平比较高的人，其他人水平就比较低。
举个例子，著名的O/R mapping工具Hibernate,其核心团队不足10人，另一个更著名项
目Struts的核心人物之一Ted Husted 为Hibernate写了一个Struts的例子，但是却没有
得到Hibernate核心团队的资格。为什么呢？是因为Ted Husted水平不够吗？不是的，
而是因为他编写的是Hibernate外围例子，所以Hibernate团队觉得不应该作为发行包的
一部分。所以根本就没有放进主CVS库！
这里我们可以看到，Open Source开发完全是一项公益性的劳动，可能有荣誉的回报，
但是core team承担着非常重要的责任，就是保证代码的质量，这是任何项目的根本出
发点。
目前CnPack的一个主要问题不是CVS的权限问题，而是文档质量问题。在我上面举出的
Tomcat和Hibernate core team中，至少有30%的人数是用来编写文档的。文档的重要性
在于，这是项目能否被实际接受的最重要条件。（国人有懒于看文档的“光荣”传统，
我们在delphibbs上可以看到多少人根本不看文档，就把问题傻乎乎的提出来讨论。）
同时，文档在开发过程的质量管理中也有非常重要的作用。
说到这个，话就多了。
今年第二期/第三期《Dr.Dobb's Journal 软件研发》杂志上有一篇非常好的文章，叫
做“精益软件开发”。其中引用Lean Production的10 条原则：
1. Eliminate waste. 消除浪费。
2. Minimize inventory. 最大程度地降低库存。
3. Maximize flow. 优化生产流程。
4. Pull from demand. 需求拉动。
5. Meet customer requirements.满足客户需求。
6. Do it right the first time. 第一次就做好。
7. Empower workers. 释放工人的活力。
8. Ban local optimization. 禁止局部优化。
9. Partner with suppliers. 与供应商结为伙伴。
10. Create a culture of continuous improvement. 创造持续改进的文化。
请注意其中的第6条：第一次就做好。
这其实是一切软件测试/质量保证活动的根本原则。这句话的意思不是说，一步到位，
做好了以后就不用改了。这句话的含义是：你每一次做事情，都要经过测试和核对，确
保每一次做出来的都是正确的、良好的甚至是完美的。这句话看起来很简单，但应用到
生产过程中，完全就是血的教训，大家相信不相信这句话使得美国汽车工业几乎崩溃？
丰田汽车在1960~70年并不具有世界级的质量优势，完全是一个小型汽车厂。那时通行
的质量管理理论是出厂检验理论，没有通过质检的产品被返工。丰田开创性的执行严酷
的质量管理。每一条生产线上，每一道工序都在生产线直接集成测试步骤。假若任何一
道工序有一个零件没有通过测试，导致的是整条生产线全部自动停工！通过这样的生产
线，保证只要生产线在运转，那么生产出来的发动机就是良好的，车门车窗也是良好
的，那么整辆汽车也是良好的。汽车设计也在不断的变化升级，但是每一次改变，生产
线重新布置，仍然要保证“第一次出厂就做好”这样的原则。凭借这样的良好质量，丰
田汽车得以横扫全美。
这句话应用到软件开发实践上来，有两条实践经验：
1，保证自动集成，自动测试。只要一个测试失败，整个测试就失败。
2，增加测试步骤，扩大任何错误的影响。
第一条不必多说，有JUnit/DUnit来进行，关于这一点本身就足以写一本书。
第二条，就是要尽量增加错误成本。这句话是我自己总结的，可能比较难以理解。举个
例子，XP开发方法有个建议说要结对编程。为什么要结对编程,理论界有很多理解和解
释。我的解释很简单：这样在一个人犯错误的时候，可以立刻将错误扩大，提高这个人
的错误成本。本来，假若你一个人写程序，写了一个错误，你发现了，改正了就完了，
别人谁也不知道。现在好了，有另外一个人，可能是你的好朋友，好战友在旁边看在眼
里，你犯了这个错误就会觉得很不好意思，至少有点没面子吧？这样你的犯错误成本就
提高了，你会努力避免犯错误。这样的代码质量就会很高。
那么CnPack项目现在没有办法结对编程，代码质量怎么提高呢？还是要从提高错误成本
来想办法。在商业项目中，有一个重要的手段是Review和Bug track。我所在的工程，
假若你犯过一个错误，不幸被客户发现了，被记入bug单，那么你就惨了。至少有5次会
议会提到这个bug.你可能不足10行的代码会遭到大约5次的review。你会觉得难过吗？
我会觉得特别的受折磨，特别难以忍受。这就是提高错误成本的方法。这不是惩罚，所
有的会议都是在平等的气氛下进行的，所有的参与者都知道我们的最终目的是为了得到
一个健壮可用的代码。假如这样的review会议有客户参加，错误的成本就更加高。
国人写程序有一种倾向，就是喜欢采用新技术，特别是纷繁复杂，看上去很漂亮的技
术。但为什么国人的程序很少能有在国际上成功的呢？因为越是纷繁复杂的技术，就越
容易出问题。国人现在还喜欢言必Design Pattern,就好像如果不用两个
Facade,Factory模式, 程序看上去就没这么漂亮一样。但是要知道Design Pattern一样
会增加复杂度，而复杂度是软件质量的大敌。记住 Keep it simple and stupid。（关
于这个问题，可以参见这篇短文：
http://chinese.joelonsoftware.com/Articles/FireAndMotion.html ，这是一篇绝对值得一读的文章）。越是复杂的技术，对人的要求就越高，编写代码就越要绞尽脑
汁的保持谨慎。所以软件技术的进步，就是减少编写软件的人员复杂度的进步。
对于Cnpack项目，现在bug track有了，但是要发挥bug track的作用，就要不断的进行
bug review。bug track只是工具，而大师不限于器。就算没有bug trace工具，我们的
日本客户之一使用Excel,记录了超过2000行的bug,并且整份文档到处用各种颜色详细标
注每次review会议的纪录，令人叹为观止。在认真细致这一点上，我们要从日本人身上
学习，并且要做的比他们更好，才能师夷长技以制夷。假若我们用了bug trace，还不
如人家用Excel做得好，不是一个笑话吗？
除了Bug track,文档就是最好的办法之一。一个糊里糊涂，简简单单不到10行的程序，
如果让你在文档中加以描述，你的劳动量可能远远超过代码本身。假若代码无法自圆其
说，通过文档是最容易发现的。编写代码者必须自己编写文档，更新代码者必须自己更
新文档（贡献代码者例外，必须由check in进cvs的人更新文档）。这样的话，就可以
令错误成本提高到一个合理的水平。假若一个程序员只会写程序，不能解释它，为它写
出漂亮的文档，那么这个程序员是一个不合格的程序员。
管理员的职责之一是总管文档，进行高屋建瓴的总体规划。可能一个决定就足以令一个
模块消失，这样可能令这个模块的开发者很痛心且难过，但是为了整体质量，这也是管
理者的职责之一。管理者并非简单的负责正确性，还要负责结构的优美，完善。对于
Open source软件开发来说，正确的杀掉一个模块的决定比正确的建立一个模块更加令
人尊敬。Hibernate小组在1.2.4之后，开发2.0之前，毅然把50%的外围代码从主CVS库
中清除，这是一个非常令人钦佩且难忘的决定。
洋洋洒洒说了这么多，也算是我自己在Open source与软件开发方面的一些思考吧。望
与CnPack的各位共勉。
----------------------------------
曹晓钢
"好客（Hospitality）" wrote in message
news:bngm2o$fj9$1@cnvcl.org...
> 除了我外，好像没人访问新闻组？？？
> 不会把，如此冷清呵呵
>
> 我现在学会使用CVS，并查看了网站源代码。发现：好像数据库没怎么排上用场似
的。
> 我觉得还是SQL调用Access比较好，而且还安全。
> 我只知道ASP调用SQL方法。如果PHP的话我就无能为力了，在ASP中，SQL就好像编写
英
> 语句型似的。
> |
每个成功的项目，背后肯定有一个比较好的管理方法。
藏镜人
 |
2006-10-20 21:09 | |
|
This blog was closed or you do not have permission to post comment.
|
|
