Mozilla开发组的开发策略(中文)

请大家对文中出现的错误多多包涵。

正文

1）优先提高排除重要的错误。

　　每个人都爱用Check In命令（对应CVS代码版本管理中一种操作，在多人共同修改文件，将最近期的文件上传到服务器并允许其他人修改，将文件取回本地修改的动作称为Check Out并同时禁止其他人在Check In 前改动文件），但是请注意它更适合于在修正一些重要错误时使用。（由于

2）多花时间在第一次提交代码前保证其正确性。

　　提交真正可靠的，经过测试，具有注释的，简介的并且是易于维护的代码，而不是在提供代码后又很快的对其进行修补。当你第一次编写代码时提高正确性要比你在修正它时更容易，并且好的注释更利于别人理解你的代码和思路，比不能读懂别人代码更糟糕的事情就是连自己都无法读懂自己编写的代码。（强调代码的的可维护性和正确性）

3）测试你自己的代码。

　　QA（质量保证）的任务是保证软件产品的质量而不是提高质量。你对自己的代码同样具有这个责任，你有义务保证在Check In代码前查找并修正错误。当你提交代码后，QA的将会有责任保证代码的正确性。

　　你应该感激那些在你的代码中发现错误的人，他们让你能够在你的错误代码影响用户他们。错误。

4）减小因为回归给你带来的影响。（回归是指当程序出现问题时将错误所影响到的所有部分进行修正。这一段可能翻译有误，因为我自己不了解他们内部的工作模式）

　　建立代码依赖树目录，并且每天更新他们，直到所有问题被修正。
　　为你的工作建立多各树目录，针对不同的的错误建立目录，在代码更新后修正自己的目录树，日常的更新工作可以减少最后CVS系统中出现的代码冲突。

5）在工作过程中，并行的开展对多个错误的修正

　　重要的错误应该先得到修正。但是重要的错误往往可能是比较难于修正的错误，例如程序崩溃，性能的提高等，修正这些错误将花费很多的时间，并且需要得到其他人的评价。在错误修正的过程中你可以找出一些在主要工作之外的并且不会花费你太多时间去修正的错误，并且修正他们。
　　当你无法找到一些比较易于解决的错误时，你可以在一些让程序崩溃的重要错误上入手，也许引起这些错误只是因为一个assert语句。
　　此外在邮件中可以查找到一些用户反映的关于界面的错误。你可以发现很多错误都可以通过很小的修改进行修正。此外对于代码中的错误可以通过查看代码中一些ToDo列表来进行，因为有的未实现的功能可能潜在的影响到已有的代码的工作。对于现有代码的审核也可以帮助你找到错误并修正它们。

6）对小的补丁的审核只需要花更少的的时间。

　　在你花大量的时间去检查和评价代码时，你应该有一个原则那就是：代码的数量和审核的时间并不应该是线性比例。20行的代码并不应该花两倍于10代码的审核时间，20行代码将应该花两倍甚至更多的事情去评价和审核。如果你可以将代码分为不同的小的部分去审核你可以提高你的工作效率。不是所有的代码都可以分为很小的部分去审核，而且并不是小的补丁和修改就一定优于长的代码。（提醒代码审核者正确的工作方法）
在你的代码等待审核时你也可以进行其他的工作。（要求编码者利用时间并行的进行工作）

7）在开始修正错误和为软件提供新功能的工作前听取其他人的意见和建议。

　　在你的递交的代码被否决时你应该及时和尽快的与你的小组负责人沟通，他们可能将安排给你一个即将开展的任务又或者能够帮助你脱离困境。此外由于他们将会在以后的工作中评价你的代码，所以告诉他们你的计划和打算是必要的。即使你的计划别拒绝，也好过在将来为你的代码提供大量的补丁。

　　Mozilla是在互联网上组织开发的，所以强调多人协作很重要）

8）如果你的代码被否决，而你又觉得一些代码是有价值的，你可以使用#ifdef宏来包含你的代码或者文件。

9）在你提交代码去进行评审时请保证你已经修正了所有的已知错误。

　　必须在第一次提交代码时保证代码的正确性，不要假设自己可以在审核后再修正错误，也不要因此而浪费审核者和你自己的时间。

10）不要拖延审核者的时间。

　　在审核过程中不要向审核者做过多的说明或争辩，在出现异议时通过简短的对话（使用IRC，AIM或其他即时消息软件）来解决问题，因为5分钟谈话就可以解决的问题如果使用Email将花上一个小时。

11）对代码进行全面的审核

　　但审核其他人代码时，请对代码进行全面的检查。如果某位负责人在以后的工作中检查出代码中的已知的错误或需要采用回归对程序重新编写，你将不得不对代码进行修正。所以做好代码得审核工作可以节省你和其他人的时间。

12）在提交代码进行审核前先自己审核自己的代码。

13）当你提交的代码比较多时在版本管理系统中创建自己的分支。