2009-03-23

svn upする前にそのdiffを全部読む

開発

最近のこだわりは、他の人がコミットした部分の差分をすべて読むこと。

モジュール単位でまとめてコードレビューとかじゃなくて、毎日最新の差分を追っかけている方が落ち着く。もちろん前提としてそれなりの規模の小ささがあると思うけど。

ほとんどのメンバは他人のコミットログは読んでいても、そのコミット内容まではいちいち読んでいない。また、直接コードを書いていないプロジェクトリーダーの人とかは、最新の設計や実装の状況を把握するためにコミットメールを重宝しているはず。だからもし、差分とコミットログの間に不整合があると、間違った情報でチームが混乱してしまう。誰かがいつも整合性を確認していれば、混乱が防げる。

また差分を見るだけで、うっかりミスや、仕様の勘違い、性能・品質に影響する設計・実装のまずさ、などの多くを発見できる。

さらに必ず、受け入れる（svn update -rNNN）よりも前にその差分を読むようにしている。svn updateコマンドの -r オプションを省略するのは不用心だと思う。こうすることで、受け入れたリビジョンの内容について把握した状態を保てるし、自分が変更する部分の影響や正しさについていつでも高い確信を持てる。少なくとも不安材料を減らすことができる。

「他の人を信用していない」と言われると、そうかもしれない。でも例えば、車の助手席のひとが「信号が青だよ」と言っても、運転手が自分の目で信号を確認しないで良いということはない。でも助手席のひとが地図を見て「次の信号を右」とか言ってくれるのは、とても助かる。結局、程度の問題だけど、自分の行動に確信を持つためには、ある程度「自分で確認する」ことが必要だと思う。

理屈ばかり書いたけど、たぶん一番重要な効用は、「ぼくはこうすることで落ち着いて開発ができる」ってことだと思う。「地に足の着いた開発」っていうのかな？

2009-01-31

メンバ変数の強調表示をしよう。

開発 C++

半年くらい前に、ふとテキストエディタの強調機能を使って、C++のメンバ変数に色を付けてみたら、これがとても良かったのでおすすめする。

数10行あるメンバ関数のコードを表示したときでも、その中で扱っているメンバ変数が、ぱっと一瞬で把握できる。

それが行頭にあって = 記号が付いていれば書き換えているわけで、リードアクセスか、ライトアクセスか、という違いも視覚的にぱっと飛び込んでくる。

コードを見て、ぱぱっと1秒もかからない時間で、リードライトの特性が把握できてしまう。

そうすると、「このメンバ変数はこのパスでは変化しない」だとか、「ここで書き換えると、影響する箇所がどことどこ」といったことを把握するのがすごく速くなる。

ちなみに、ぼくの使っている秀丸エディタはC++の構文までは解釈してくれないので、正規表現でメンバ変数を指定した。

ところで、よくクラス名の頭に C や T を付けるとか、メンバ関数の名前の最初の文字は大文字か小文字かとか、統一すると見栄えが整ったり読みやすかったりするのは分かるけど、いままではあまりメリットを感じたことがなかった。

でも今は、メンバ変数に関しては色分けの効能がすごいことを知ってしまったので、他の変数と機械的に区別できるように、「m_」とか付けるようにしている。

せっかくなのでメンバ変数の正規表現を紹介。前方不一致の機能を使って「.」や「->」が頭につくものは除くのがポイント。

(?<!(\.|->|[a-zA-Z0-9_]))([a-z][a-zA-Z0-9_]*_|mp*(_|[A-Z])[a-zA-Z0-9_]*)(?![a-zA-Z0-9_])

そして「.」とか「->」が付いているのはこっち。これは this ではなく他のインスタンスや他の構造体の変数に触っている箇所。意味合いが異なるので別の色を付けた方がよい。

(?<=\.|->)([a-z][a-zA-Z0-9_]*_|mp*(_|[A-Z])[a-zA-Z0-9_]*)(?![a-zA-Z0-9_])

メンバ変数の流儀にもいろいろあるので、いろいろ対応するように工夫してみた。上に書いた正規表現で下のようなスタイルを全部強調表示できる。

  int m_size;
  int *mp_buffer;
  int **mpp_table;
  int mData;
  int mpData;
  int data_;

2008-11-11

先を見据えないものづくり

どうも最近、自分の中で、趣味のものづくりが盛り上がらない。

「何か、こういうものを作りたい」「こういうものを作らないといけない」という風に考えてしまう。具体的なところでは機能とか性能とか。抽象的なところでは作品の意義とか役割とか。あるいは人や社会に与える影響とか。

会社でものづくりをしていると、とくにそうなる気がする。

もっと、小さな思い付きとか衝動に任せたものづくりがしたい。

転がっているおもちゃとか、目の前にある部品を、ちょっと組み合わせてみる。ちょっとしたアイデアを、わざわざ手を動かして形にしてみる。

現実には、結果がだいたい予想できると思っちゃうと、手を動かす気にならない。そこをあえて手を動かすことで、何か得られるんじゃないかな。あまり何も得られないかも知れないけど。

サークルの後輩が、マイコンでテトリスやぷよぷよを作っているのを見ると、すごいと思う。

そうやって、先を見据えないものづくりを、ぼくも学生の頃はたくさんやっていた。いまは忘れかけている。

いや、後輩たちは先を見据えてるかも。

2008-10-18

フックって大変

開発

Win32のフック機能（SetWindowsHookEx()とか）を試してたのだけど、ちょっと失敗すると簡単に、PCの再起動が必要になって大変。

WM_WINDOWPOSCHANGED とかをすべてのウィンドウについてフックする実験をしていたときに、うっかりメインプログラムが例外を起こしてデバッガ（BCBのデバッガ）につかまってしまった。その瞬間、デバッガ自体のウィンドウが手前に来ようとするメッセージをフックしているメインプログラムが止まっているというデッドロック。これはひどい設計（→自分）。

OSはしっかり動いてるけど、ウィンドウはどれもほとんどハングアップ。

リモートデバッグしろってことかなぁ。