大开眼界：Mozilla的开发观念和工具
原文链接：http://ms.mblogger.cn/dongxun/posts/3167.aspx
Remember, a code reviewer is not a friend.
FireFox是我迄今为止最喜欢的浏览器，出于对它的喜爱，我很想知道这个软件项目是如何运作的。今天歪打正着，阅读了Mozilla Hacking Guide这篇文章，收获颇丰。
这篇文章主要讲了三个问题。
Mozilla软件体系结构
Mozilla最主要的一个目标就是跨平台，出于性能考虑，编程语言以C/C++，而不是Java为主。因此在string, runtime library, multi-thread, exception handling, user interface上都实现自己采用的隔离层。
比较有趣的是由于各个平台对异常处理支持不通，Mozilla采用返回值而非典型OO的异常处理机制，其返回值为nsresult，类似于COM中 的IResult。同时，Mozilla又是一个大规模的项目（百万代码行），为了有效进行资源管理，Mozilla自己实现了一个类似于COM的机制， 叫做XPCOM，接口nsISupports（类似IUnknown）以及一个nsComPtr（类似IComPtr)。
由于不同的操作系统对于GUI的支持大不相同，因此Mozilla采用了类似于XAML和SVG的技术，即通过engine产生XUL文件，再由不 同平台下的layout manager动态产生GUI。这里的XUL文件就是完全基于XML的，理念之新，令人惊讶。另外，出于编程效率的考虑，Mozilla生成XUL的大部 分代码是有JavaScript调用C/C++ export的DOM对象产生的，这个接口叫做XPConnect，这也很有混合编程的味道。
Mozilla中间的Localization，Notification Mechanism也实现的很有意思，大体上倒是于windows类似。
Mozilla的项目管理
Mozilla作为一个大规模的“消费品”软件，采用了很严格的Review制度，超乎我的想像。
在日常开发的过程中，几乎所有Check-in的代码都必须经过两层Review。第一层是由被修改模块的Owner进行的，第二层是由随机抽出的Mozilla Guru进行的“Super-review”。只有两层的review都通过，代码才能进入主代码树。
在每个milestone之前几天里，甚至连修改也必须要通过mozilla.org "Driver"同意才能进行。这样严格的制度仿佛与Open Source中集市的观念不太相同，这是否意味着大规模软件开发必须是教堂模型呢？
- 关于patch，bug fixing以及review的描述，可以参看http://www.mozilla.org/hacking/life-cycle.html。
- 关于Code review checklist，查看http://www.mozilla.org/projects/seamonkey/rules/code_review.html。
- 关于milestone管理，查看http://www.mozilla.org/roadmap.html底部milestone schedule。
Mozilla中的软件工具
真正的工具必须有两个特点，第一是“管用”，第二是“好用”。太花哨就是不好用，跟项目结合不紧密就是不管用。 Mozilla为了项目运行的需要，配合上面所说的开发过程“量身定制”了一些工具。
BugZilla：这里记录所有issue，甚至包括帮助文件的修改。所有bug都有一个可用来跟踪的ticket，并且可以根据这个ticket number立刻查到详细的描述信息。所有讨论也都使用这个标示，不会产生二意性。Review也可以从这个系统中搜索到。
Tinderbox ：这是最令我惊讶和佩服的工具，其貌不扬但非常“管用”。一旦有任何代码被checkin，Mozilla基于不同平台的多个build machine就自动更新本地文件，编译并进行自动测试并且向Tinderbox汇报结果。结果都是用颜色标示出来，看一眼就可以知道整体情况。
Bonsai ： 这个工具能够列出每个代码文件的修改，更棒的是他还能查询修改。有了这个工具code review可就方便多了。