今住んでいるところは建物全体がケーブルテレビの設備を持っているため、ケーブルテレビ業者の設備チェックが入る。僕はテレビを持っていないのだけれど、設備のチェックは必要だということで、業者のチェックに立合う。
バージョン管理システムにおけるチェックイン(コミット)のタイミングについて。
最後に、CVS を使った開発の話についてもちょっとだけ触れたい。 CVS を使った開発と言っても話題はいろいろあるけけども、ここで話すのはその中でもチェックインの粒度についての話だ。
(中略)
まあそんな筆者の特殊事情は参考にならないので置いておこう。ずばり読者にはどれがお勧めかというと、「それができるならば、」可能な限り細かくチェックインするのが一番よい。ついでにそのタイミングでユニットテストを動かすともっといい。「そんなの時間の無駄」と思われるかもしれないが、よくよく自分のやってることを観察すれば、その程度の時間は絶対余っているはずである。それに、慣れればチェックインしまくるのが一種の快感になってくる。 XP の気持ちよさと少し似ているかもしれない。
なるほど。
少し前まで、職場で書いたコードをよくチェックインし忘れることがあって、複数の変更を含んでいるものだから、あとで変更の意図が分からなくなったりして困ったことがあった。「可能な限り細かく」というのがどこまで細かいのかは分からないけれど、僕の場合は、最近は以下のようなことを心掛けている。
たとえば、
といった感じだ。
その日、コードに対してやりたいことが4つあったとしよう。コメント文を日本語ではなく英語にする、インデントの整理、機能Aの削除、機能Bの追加、の4つだ。そうしたら、まずはコメント文を日本語ではなく英語にする。そうしたらチェックインする。次にインデントの整理をする。機能Bの追加のことは考えない。またチェックインする。機能Aを削除する。ここでも機能Bの追加のことは考えない。またチェックインする。そして、機能Bを追加する場合は、頭にかすかに浮かんでいる機能Cのことは考えない。
チェックインないしコミットの際は、必ずパッチをレビューする。パッチをレビューして、分かりにくいようでは困る。
では、たとえば、機能Bの追加作業に時間がかかってしまう場合はどうするのか?
それは、書くべきコードが分かってない、つまり、機能Bの追加作業がまだできる状況ではない、ということだ。ちゃんとやるべきことを定義できているか。ちゃんとモデルコードを書いたり、テストコードを書いたりしているか。どこかがおろそかになっているということだ。
だから、一旦ロールバックする。必要なら、書きかけのコードをバックアップしておく。ただし、そのバックアップはあくまでメモと同じようなものに過ぎない。
バージョン管理システムをうまく使うことで、開発プロセスそのものも整えられるんじゃないか、と思うのだ。そして、それが少しずつ身につきはじめている。
こうして文にしてみれば、基本的なことなのだけれど…。
shinoさんの日記より。
へぇー。思い浮かべるだけで気持ちがいい。
そして、だからこそ「なぜ?」と思ってしまう。すると、…:
「風になりたい」を1,000人で唄おう! と考えたのは、思いつきです^^:
なるほどお。:-)
第一回目は横浜であるらしい。
個人的には「ユニットテストで通るコードをチェックイン」で良いと思ってます。nightly build を成功させることを前提に考えれば、これが比較的自然なタイミングです。
可能な限り細かくコミットして、ユニットテストで通ったときにtagを付ける、という方法もあります。