Mozilla Development Strategies

いくつかの方針が開発者の生産性を維持するために役立ちます。

最も重要なバグに最初に取りかかる

（書いたコードをリポジトリに）チェックインする事は、みんな大好きです。しかしチェックイン率の高さだけが全てでないことに留意してください。目立たなくて再現性の低い些細なバグを直す事よりも、本当にユーザに影響する、データが失われるバグや、クラッシュバグ、パフォーマンスの改善などを直す方が、望ましいです。

より良いものにしておくために、最初の時点で多くの時間を割く

また、大量のその場しのぎの修正よりも、本当にしっかりしていて、よくテストされていて、適切なコメントが付けられていて、綺麗で、メンテナンスが容易なコード片の方が望ましいです。あなた（あるいは他の誰か）はある日そのコードに戻ってくるかも知れません。短時間でとりあえず片付けて、後になって正しい物にするためにもう一度戻ってくるという時よりも、あなたの関心がその問題に向けられている時の方が、より良いものにしやすいでしょう。他人のコードを読んで分からないのならまだしも、自分のコードを読んで分からないのでは話になりません。

コードをテストする

QAの仕事は品質を保証する事であって、品質を高める事ではありません。それは（コードを書く）あなたの仕事です。チェックインする前にコードの中の問題点を探し出して修復する事は、あなたがしなくてはならない事です。あなたがバグのないコードを提供してくれれば、QAの仕事は、それが本当にバグのないコードかどうかを確かめるだけになります。

あなたのコードの中にあるバグを見つけてくれた人に感謝する事を忘れないでください。あなたがコードをチェックインする前に彼らがバグを見つけてくれたのなら、それに対しても感謝しましょう。彼らはあなたに、バグがユーザに影響を与える前にそれを修正するための、第二の機会を与えてくれているのです。

退行バグの問題を最小限にする

あなたが日々の退行バグ【訳注: あるバグの修正によって、今まで正常に動いていた別の箇所が正常に動かなくなったという種類のバグ。エンバグ。】に積極的に取り組むタイプの人でないのなら、あなたは退行バグに悩まされないための方法を探す必要があります。あなたは、一つだけのツリーを持って、毎朝それにCVSアップデートをかけて、ブロッカーバグが取り除かれるのを待たされる、という状況を望まないでしょう。

複数のツリーを持つようにしてください。そのうちせめて一つは毎日アップデートされるべきです。あなたは退行バグ（例えば新しいクラッシュバグ、ブロッカーバグ、またはあなたの分野での問題など）に対する応急手当のために、これを必要とするでしょう。この同じツリーを、小さくてすぐに片付くバグや、最近の退行バグやクラッシュバグのために使ってください。それ以外のツリーは、頻繁にはCVSアップデートを行ってはいけません。ツリーの状態が良好だと分かっている時だけアップデートしてください。一旦あなたの修正作業が完了したと思うには、アップデートして、ツリーを再構築して、再びテストして、現在のtrunkに対するdiffを作成する必要があるでしょう。しかし、日々の退行バグはあなたが主に取り組んでいる開発を妨げることはありません

ツリーが日々更新され続けている限り、あなたがツリーをアップデート無しで作業する時間が長くなれば長くなるほど、あなたがCVSコンフリクトに遭遇する可能性は高まります。あなたが一週間毎日アップデートを行っていたなら、あなたはコンフリクトに遭遇することはなくなります。しかし、あなたが週に1回しかアップデートを実行せず、多くのコードを変更していたなら、あなたはおそらくコンフリクトに遭遇するでしょう。

あなたのツリーをアップデートするための高速な方法として、 mozilla\config\fast-update.pl を見てください。あなたは主なMozillaのツリーを（nsprpubなどを除いて）1～2分でアップデートすることができます。

複数のバグに平行して取り組む

あなたは最も重要なバグから先に取り組むべきです。しかしそれらは、クラッシュの再現が難しかったり、パフォーマンスのために大幅な書き直しが必要だったりするなど、完了するのに数日から数週間を要するような修正が難しいバグかも知れませんし、また、レビューのためにも時間を要するでしょう。その間は、あなたの他のツリーで、より小さく簡単なバグに取り組むとよいでしょう。あなたが主に取り組んでいるツリーの作業とコンフリクトしないようなバグを選んでください。また、修正には数時間から数日程度しか要しないようなバグを選ぶべきです。理屈通りなら、それらのバグの修正はレビューも早く終わるでしょう。

もし、作業に取り組むのに適当な小さくて簡単なバグを見つけられない場合は、クラッシュバグを探してください。その問題はもしかしたら、原因をよりはっきりさせたり、完全に修正したりできるかもしれません。あなたはクラッシュバグを探すために、トークバックによって送られてきた問い合わせか、Bugzillaへの問い合わせを使うことができます。

既存のコードの問題を探してください。文字列の扱いの問題を探して修正してください。XPCOMマクロのよくない使い方を探して修正してください。いくつかのコードをnsCOMPtrに置換してください。「XXX」や「TODO」をコードの中で探して、そのコードがまだ修正が必要であるかどうかを確かめ、修正してください。

小さなパッチは速くレビューされる

もしあなたが、レビュー待ちのために長い時間を過ごさなくてはならないことに気がついたら、パッチの大きさとレビューにかかる時間は正比例の関係にないことを記憶にとどめておいてください。20行のパッチは10行のパッチのレビューの2倍の時間がかかるわけではなく、たいていの場合、それよりもっと多くの時間がかかります。もしあなたが作業の成果を分割してより小さいコード片にまとめることができるなら、あなたはより迅速なレビューを得ることができることに気付くでしょう。もちろん、全てのコードが小さく分割できるとは限りません。また、短い修正が必ずしも長い修正より優れているとも限りません。

平行したツリーを持っておいて、レビューを待っている間は、他の点の作業に取り組むべきです。

パッチを作る作業や開発を終えた後ではなく、作業に取りかかる前に、アドバイスを受ける

もしあなたが何かに取り組むにあたって、つまずいたり困ったことに出くわしたりしたら、後でではなく、なるべく早いうちに、より詳しい人に相談してください。おそらく、彼らはあなたに任せられるバグを持っているか、あるいはあなたのつまずきの原因を取り除く手助けをすることができるでしょう。彼らが後であなたのコードをレビューすることになるので、まず最初に彼らに、あなたの作業計画について相談してください。大きなパッチを書いた後に不採用になるよりは、アイデア段階で退けられた方がマシです。

未解決の問題があって、しかしチェックインする価値のある何かがある時は、#ifdef や設定、あるいは「代替」ファイルを使ってチェックインする

時々、あなたは何らかの作業に取り組んでいるのに、何かが妨げになってその変更をチェックインできないということがあるでしょう。その場合でも、（あなたがレビューを得たと仮定して、）そのコードが初期状態で有効にならないようにしてあれば、あなたはコードをチェックインすることができます。巨大なパッチを適用してもらうよりも、設定を変更したり、小さなパッチを適用したり、あるいは #define を使うようにと説明することの方が容易です。

C++では、#define 、#ifdef 、#else そして #endif を使用してください。

XULやJavaScriptで、あなたが何か大木な事に取り組んでいるなら、新しいファイルをツリーに追加して、それを有効にするためのシンプルな jar.mn パッチを作成してください。

あなたはまた、コードをチェックインする時に、それだけでなく、設定で制御できるようにしてその機能を初期状態では無効にしておくこともできます

レビューに進む前に、正しい修正をしたかどうかを確認する

副作用については後で修正することにしてでも、誰よりも最初にその修正をやり遂げたい、という誘惑にかられた時は、後回しにするのではなく最初の時点でその副作用を修正しておいてください。くれぐれも、あなたが「後で修正すればいい」と思ったバグについて、後からでも推敲して修正することができるとは考えないでください。――レビュアーはあなたに、とにかくその問題を先に片付けるように言うでしょう。

その問題についてレビュアーと20分間討論をすることよりもむしろ、5分の余分な作業をその問題の修正に費やすことで、あなたもレビュアーも有意義な時間を過ごせるでしょう。「正しい」やり方をしようとすると大量のコードを書き直さないといけないというのなら、それよりはどう考えても、漸進的に作業を進めることの方が望ましいです。それは紙一重です。

Bugzilla（またはメール）でレビュアーと言い争う事でレビューを長引かせない

レビューを受けているときには、レビュアーがあなたとの討論に長く拘束されないように努めてください。討論が長くなりそうなら、IRCかAIMを使って個人的に解決してください。5分の議論は1時間のE-mailをやりとりするのと同じぐらいの価値があります。

徹底的にコードをレビューする

あなたが他の人の書いたコードをレビューする時は、徹底的にレビューしてください。もし他の技術者が退行バグや何らかのバグを引き起こすコードをチェックインした場合、あなたがその問題の修正の面倒を見なくてはならない羽目になるでしょう。堅実なコードレビューを行うことで、あなた自身と、そして他の人達の後々の時間を節約してください。

他の人にレビューを頼む前に、自分でもレビューする

レビューとスーパーレビューを求める前に、あなた自身が作成したパッチを自分でレビューするための技能を身に付けてください。あなたが自分で何か問題に気付くことは、レビュアーやスーパーレビュアーから指摘されるよりもよいことです。あなたは問題を見つけたり、dump()やprintf()といった文をコードの中に残していたのを見つけたり、あるいは、ホワイトスペース文字の入れ方がめちゃくちゃだったことなどに気がつくかも知れません。

もし大きな変更に取り組むのなら、ブランチを切る

もしあなたが大きな変更に取り組んでいて、レビューを得ることなく少しずつ変更をチェックインできるようにしたいのなら、ブランチを切ってください。しかし、ブランチを切るということは、あなたがその成果を元のツリーに戻す時にコンフリクトに対処しなくてはならず、また、レビューのために長い時間を待たされることになるということを意味します。

以下はブランチの切り方です:

LinuxまたはMac OS Xの場合:

# あなたのローカルディスク上にあるtrunkのツリーから作業を行ってください
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

Windowsの場合:

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