diaryこの広告は、90日以上更新していないブログに表示しています。2011-01-16ユニークなID付け技術バグIDが30の状況はどうなっている?とか、SVNリビジョン100のせいでテストが失敗するようになったとか、現在はテストケースIDが200のテストを試験しているとか、のように事象にユニークなIDを付けて管理することによりコミュニケーションコストを下げるということはソフトウエア開発において一般的に行われているだろう。ないと、「〜のバグはどうなっている?」→「〜のバグって何ですか?」→「〜のとき〜すると〜なるヤツだよ!」のようにいちいち説明しないとコミュニケーションできなくなってしまう。-注文(Order)機能だからOdr001Action.javaみたいな画面ID(6桁)+Action形式もある。これに関しては反対意見も多いと思うが、採用理由としては画面ID見れば何の機能だかわかるということとなんらかの一貫した命名規約が無いと大量生産できないということだろう。良くも悪くもこれが大規模(に限らないか)受託開発(製品開発でもそうかも)の実態じゃないでしょうか。注文明細画面ならOrderDetailAction.javaでいいじゃんというのはそれはその通りなのですが、一貫した命名規約が無い場合は開発担当者が名前付けをいちいち考えないといけなくなります。大規模開発だとExcelからソース自動生成して開発担当者はそれに対して開発する(クラスを作ることは無い)という流れになりがちなので、一貫した命名規約が良かったりするわけです。ま、画面IDと機能一覧のマッピング表を別Excelで作ってたりするわけですが。他のユニークなIDとしてはバージョン番号、ビルド番号なんかもそう。Candidate)1を出すとする。この場合はv02-00-rc1みたいなタグを打ってリリースするだろう。Tracを使っている場合はバージョンはv02-00にしてマイルストーンがv02-00-rc1になる感じ。RC2を出すならv02-00-rc2というタグを打ってリリースする。1つのバージョンに複数のタグ、マイルストーンがひもづくイメージ。こまかいモジュールのバージョン付け(例:hoge-1.0.jar)はやったことない。サードパーティのモジュールで既にバージョン番号が付いているモジュール(例:log4j-1.2.16.jar)はそのまま使うけど、自作モジュールに関してのバージョン番号付けはやったことないな。