チケット駆動開発の展望part2

ソフトウェア構成管理とチケット駆動開発の関連についてメモ。

【1】Twitter / @akipii: この資料はかなり良い！昨今のGit/Mercurialがどんな問題を解決したのか、詳しく書かれている。　分散リポジトリ型時代のソフトウェア構成管理

分散リポジトリ型時代のソフトウェア構成管理

GitやMercurialなどの第3世代のバージョン管理ツールの特徴や利点が詳しく書かれていて参考になる。
最後のまとめにある「「構成管理が面倒」なのではなく、「面倒なツールで構成管理していた」ことが実感できて幸せ」に同感する。
ツールが我々の作業や思考そのものを規定しているだけでなく、制約をかけている。

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

【2】Twitter / @akipii: MercurialやGitを使う技術の方が単なるプログラミングよりも重要という指摘。人の足を踏まずに仕事をするということ：ある nakagami の日記：So-netブログ

人の足を踏まずに仕事をするということ：ある nakagami の日記：So-netブログ

チームでプログラミングする時、patch(diff)でのやり取りができるか、GitやMercurialの作業に慣れているか、マージ作業が出来るか、と言ったスキルの方がはるかに重要という指摘をしている。
この指摘は、日曜プログラミングと違い、オープンソースでもチームでプログラミングする場合、お互いの成果物を差分比較してマージして一つの成果物を作っていく連携作業に慣れているかどうかが重要ということにつながる。

TortoiseSVNでもpatchを出力したり、逆にpatchをソースに取り込んで反映できる仕組みがある。
どのリビジョンのソースを改変して、どんなソースを追加したのか、というパッチを見て、コミッタはコードレビューするし、検証もする。
パッチがあれば、マージ作業もやりやすくなる。

【3】Twitter / @akipii: RedmineのREST APIを使った良い例。Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ)

Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ)

Redmineの設定画面にはAPIキーを生成してWebサービスを実行できる仕組みがある。
上記の記事では、post-commit-hookをAPIキーを使ってWebサービス化する手法を提示しているだけでなく、PythonのフックスクリプトでチケットをCloseする機能も追加している。

post-commit-hookは、チケット駆動開発の運用ルールであるNo Ticket, No Commitの発端となった機能であるがゆえにとても重要な機能の一つ。
SCM連携の機能強化はもっと研究される余地があるだろう。

【4】Twitter / @akipii: 良い記事。No Ticket,No Commitを実践する時コミットの単位にとても気を使う。コミットにはプログラマの意思が込められている。クリアなコードの作り方: 意図が伝わるコミットのしかた - ククログhttp://www.clear-code.com/blog/2012/3/13.html #redmine

クリアなコードの作り方: 意図が伝わるコミットのしかた - ククログ(2012-03-13)

チケット駆動開発でソースをcommitするとき、commitする粒度にとても神経を使うようになる。
駄目なプログラマはコミットするソースの差分を見ても、何を変更したいのか、分かりにくい。
特に、機能追加やバグ修正を混ぜ込んで、Fatなcommitする時は特にそうだ。

上記の記事では、コミットする粒度についていくつかのアドバイスが書かれていてとても参考になる。
基本は、コミットする理由が分かるように細かく分ける方がいいだろうと思う。

僕も、コミットログの書き方はメンバーに口うるさく言うようにしている。
一度コミットログの書き方に慣れれば、自分の意思を持ってソースを修正するようになる。

SVNのコミットログの書き方: プログラマの思索

No Ticket, No Commitには教育的効果があると思う。

No Ticket, No Commitの効果: プログラマの思索

特に、ソースに書かれた障害管理番号や無駄な仕様の記述は、ソースではなくチケットやコミットログに書くべきだ。
そうしなければ度重なるソース修正で、すぐに古くなりガラクタのコメントになるからだ。

SCMコミットログはファイルのメタ情報: プログラマの思索

変更理由や仕様はソースのメタ情報であり、そのメタ情報はSCMコミットログやBTSチケットに記載して管理されていくべきだと思う。
SCMやBTSに貯められたメタ情報は、BTSの優れたレポート機能によって色んな観点でメトリクス出力でき、分析したり是正対策を取ることも可能になる。

色々考えてみる。