プログラムのコメントとチケット駆動開発

コメントのいらないプログラムの書き方 - NZ MoyaSystemはてなブックマークに、こんなコメントがあった。

NG。コメントは処理の意味でなく仕様の意図を書く。

まさにその通りだと思った。

それと同時に、 Redmine のチケットや Backlog の課題にも理由を書いて欲しいことを、思い出した。
作業内容をチケットに起こしてくださいと言うと、何をするのかだけ書かれるケースが、わたしの周りでは目に付くんだよ。
それでは何故そうするのかが分からない。何をするかも大事だけれど、何故そうするのかも大事なはず。後から問題が発生した場合に、何故その実装が必要だったのかが不明だと「わざわざ変えたのだから理由があるはずで、理由があるなら只 revert しちゃいけないはずなんだが、その理由が分からないから困る……」という話になる。なるんだって。わたしの経験上。うぅ。
だからチケットには何故この作業が必要になったか、そしてこの作業は何をどうするのか。それが残るようにして欲しい。

ちなみにわたしは、もう何年も前のことだけど、テストクラスをコメントつきで充実させたはいいが、テスト対象のクラスに一切コメントを入れなかったことがあって、上司に笑いながら「確かにテスト読めば分かるんだけどさぁ、コメント入れて欲しい」と突っ込まれたことがある。その節はたいへん申し訳なかった。当時のわたしは、単体テストで機能を網羅したぞとご満悦でした。

ところで、なんとなくチケット駆動開発をググって Wikipedia を眺めたら。

大阪中央公会堂で行われたTiDD関西勉強会にて、「TDDと同じ略称だと紛らわしいので、TiDDにしよう」で決まった。iが小文字なのは、おしゃれだからである。

おしゃれだからであるに、くすっと笑ってしまった。