チケット駆動開発でソースが綺麗になる

チケット駆動開発とプログラムの品質に関するメモ書き。

【1】チケット駆動開発でソースが綺麗になる

以前のプログラミングは、ソース1行とコメント1行をペアに書くのが普通だった。
実際は、プログラミング設計書の該当箇所をそのままソースにコメント化して、そのコメントに合わせて実装する開発スタイル。
又、障害修正が発生するたびに、修正日と障害管理No、パッチの範囲を示すコメントを入れていた。

たくさんの人のパッチが入るたびに、コメントが増えて、ガラクタがソース中にどんどん増えていく。
最終的に、本番稼働中のソースはたとえコメントであろうとも、コメントを削除するだけのリファクタリングすらできなくなる。

おそらくこの開発スタイルは、汎用機＋Cobol時代に作られたものだろう。

昨今のプログラミングスタイルでは、ソース中に処理説明や修正箇所のコメント化はしない。
仕様に関するコメントは全てチケットへ書く。
ソース中に処理とほぼ同値な無駄なコメント、修正履歴を書く必要なし。
それらは、チケットというソースの一つ上のメタレベルに保持すべき情報。

チケット駆動開発のおかげで、ソースは綺麗になる。

【2】チケット駆動開発がデグレードを防ぐ。

チケット駆動開発が提供する変更管理、構成管理がデグレードを防ぐ。

デグレという用語 - プロフェッショナルプログラミングの世界 - Yahoo!ブログ

デグレード － ＠IT情報マネジメント用語事典

デグレが起きやすい根本原因は、バージョン管理が徹底されていないこと。
どのバージョンにどのバグ修正が反映されているのか、という管理は、プロジェクト管理の中で最も基本的な作業の一つ。
バグは結合テスト以降で多発するため、数多くのバグ修正のパッチを副作用無しに反映させるのは非常に難しい。

XPの継続的インテグレーション(Continuous Integration)を実施しているならば、trunkをいつでもリリース可能な品質で保障してくれるので、即座にビルドしてリリースできる。

全ての障害について対処状況を追跡し、かつコード修正と対応付けるバグトラッキング機能は、まさに構成管理の重要な機能の一つ。
バグ管理システム(BTS)は、このバグトラッキング機能を提供してくれる。

チケット駆動開発は更に、チケットとソースのリビジョンを相互リンクするインフラを提供するため、構成アイテム(Configration Item)の状態を管理しやすくなる。
「要件→チケット←ソース」というトレーサビリティのおかげで、ソースの修正理由をいつでも誰でも追跡できる。
仕様がコロコロ変わる場合、その履歴をチケットに残せるため、本来の要件を探る手がかりになる。

チケット駆動開発は変更管理のインフラも提供してくれる。