正在阅读：Mozilla开发组的开发策略(英文)Mozilla开发组的开发策略(英文)

2004-02-14 09:34 出处：PConline原创作者：Seth Spitzer & Alec Flett 责任编辑：zwg

手机流氓软件有哪些去看看

在本页浏览全文

8) if you are blocked, but have something worth checking in, check in using #ifdef, prefs, or "alternative" files Sometimes you'll work on something, but you can't land it because something else is blocking you. You can still land (assuming you get reviews) if the code isn't on by default. This also makes it easier to get help on the problem. It's easier to tell someone set a pref, or apply a small patch, or set a #define then to apply a monster patch. For C++, use #define, #ifdef, #else and #endif For XUL / JS, and you're doing something major, add your new files to the tree and then have it be a simple jar.mn patch to enable it. You can also have code that checked in, but controlled with a pref and off by default. 9) make sure you have the right fix (not a "I'll fix it later hack") when you go for reviews When tempted to do a first pass fix and fix the fallout later, do it right the first time - don't assume you'll be able to file a "fix it" bug and fix stuff you know about later - chances are the reviewer will make you do the work anyway. If it takes you five extra minutes to do something the "right" way rather than twenty minutes debating it with the reviewer - you've just saved yourself and the reviewer valuable time. Obviously, when doing it the "right" way means re-engineering large amounts of code, then incremental work is better - it's a fine line. 10) don't drag out reviews by fighting the reviewer in bugzilla (or email) When getting a review, try not to belabor a point that a reviewer is debating you on. If the debate is involved, solve it in person, on IRC or over AIM. A five minute discussion is worth an hour of e-mails. 11) do thorough code reviews When you review someone else's code, review thoroughly. If another engineer checks in code that causes regressions or introduces bugs, you might be the one who has to fix it later. Save yourself (and others) time later by doing a solid code review. 12) review your own code before you ask for reviews Pratice your reviewing skills on your own patch before you seek reviews and a super review. Better that you catch something, than the reviewers or super reviewers. You might find a problem, or find that you left in some dump() or printf() statements, or have messed up the whitespace. 13) if you're working on something massive, start a branch If you are working on something big, and you want to be able to check in incrementally without getting reviews, create a branch. But having a branch means dealing with conflicts when you land, and waiting a long time for reviews. Here's how to create a branch: from your linux box: # start from your trunk tree on your local disk cd mozilla find . -type d \! -name CVS | xargs -l -P10 cvs tag -l MY_BASE_TAG > & ../taglog1.txt find . -type d \! -name CVS | xargs -l -P10 cvs tag -b -l MY_BRANCH_TAG > & ../taglog2.txt from your win32 box: cvs co -r MY_BRANCH_TAG mozilla/client.mak cd mozilla edit client.mak, putting MY_BRANCH_TAG in the right places. cvs commit client.mak nmake -f client.mak