当前页面位置: » 丰搜网 » 文档中心 » 详细内容
mozilla开发组的开发策略(英文)
mozilla开发组的开发策略(英文)
关键字： 开发策略
原作者姓名： seth spitzer & alec flett
文章原始出处： http://www.mozilla.org/hacking/development-strategies.html
1) work on the most important bugs first.
everyone likes to check in. but keep in mind, checkin rate isn't everything. it's better to fix one dataloss bug, crasher, or performance bug that really affects the user than edge case bugs that are rarely seen or minor bugs.
2) take extra time to do it right the first time
it's also better to come up with one really solid, well tested, well commented, clean, easy to maintain piece of code than a bunch of quick fixes. you (or someone else) will be back in that code someday. it's easier to do it right once, when your mind is in the problem, then to do it once quickly and once again when you have to fix it the only thing worse that not understanding someone else's code is not understanding your own.
3) test your code
qa's job is to assure quality, not to add quality. that's your job. it's your responsibility to find the problems in your code before checking in, and to fix them. when you land your bug free code, it's qa's job to assure others that it's really bug free.
make sure you appreciate anyone who finds a bug in your code. appreciate it even more if they find it before you ship. they're giving you a second chance to get it right before it becomes a bug that affects users.
4) minimize how you are affected by regressions
unless you are the type to go out and tackle daily regressions, you need to find a way to not let them affect you. you don't want to have one tree, update it every morning, and then be stuck waiting for blockers to clear.
have multiple trees. at least one of them should be updated every day. you'll need this one for regressions that require your immediate attention (a new crasher, a blocker or regression that is in your area, etc.) use this same tree for small, quick bugs or recent regressions or crashers. for your other tree, don't update as often. update when you know that the tree is in good shape. do your primary development in this tree. you'll need to update, rebuild, re-test and make a diff against the current trunk once you feel your fix is done. but, daily regressions won't block your primary development.
as far as keeping trees up to date - the longer you go without updating your tree, the more likely you are to have cvs conflicts. if you update every day for a week, you might not have any conflicts, but if you update once a week and you've changed a lot of code, you'll most likely have conflicts.
see mozilla\config\fast-update.pl for a fast way to update your tree - you can update your main mozilla tree (minus nsprpub, etc) in 1-2 minutes.
