グランパス好きでソフト開発しながら子育てするカズキの雑記ブログ

kiki-blog(カズキの雑記ブログ)です。名古屋グランパスを中心としたサッカーネタ、組み込みソフト開発ネタを中心に記事にしていきます。



【スポンサーリンク】




ソースコード以外もリビジョン管理してみてはどうでしょうか

スポンサーリンク

ソースコード以外もリビジョン管理はやりましょう!

学卒後、組み込み開発をしております。

その中で、構成管理ツールの導入から運用、更に国際標準規格対応(A-SPICE,機能安全)まで行いました。

 

今回は、その中でも構成管理についてご紹介致します。


日々の開発業務で作成した成果物、きちんとリビジョン管理していますでしょうか。

 

きっと、ソースコードだけはGitHubやSubversion等できちんとリビジョン管理しているのかと思います。

 

ソースコードをきちんと管理できているのなら、開発中に作成した仕様書、設計書、テスト仕様もぜひリビジョン管理してみてはいかがでしょうか。

 

 

どのファイルが最新版かわからないから

日々の開発の中で、こんな状況に遭遇したことはないでしょうか。

  • あるファイルについて、最新版がどこにあるかわからない
  • 同一名のファイルが複数存在する

例1:社内サーバからベース機種の設計書を探し、それを参照していたが、よく見るとそれは昔の設計書であり、現在のソースコードと作りが全く異なっており、解析した時間が無駄になった。

 

例2:探したいファイルで検索かけたが、「修正版_〇〇資料.xlsx」「レビュー後_〇〇資料.xlsx」のようなファイル名のように、どれが最新かわからない。また、同じ名前のファイル名が乱立するのは見た目が美しくないうえに、必要なファイルを見つけにくい。

 

このような場合、予めフォルダ階層テンプレートを、リビジョン管理ツール上に適用したうえで、作成した成果物をそこにぼんぼん放り込んでいくだけで問題解決しますね。

 

以前の内容に戻れて楽だから

日々の開発業務の中で、こんな場面に出くわしたことはないでしょうか。

  • コーディングして機能実装したけど、機能自体が取りやめになった
  • 設計書に新たな設計を追記したが、内容NGにより別の手法を模索することとなった

例1:せっかくある機能について、複数のソースファイルに変更を加えることで機能実現したのに、その機能自体が実装取りやめとなり、コーディングした内容をいちいち削除する手間が発生した。また、その削除の仕方も一部ミスし、ごみコードが残ったり、デグレート(変更による既存コードへの悪影響)が発生してしまっていた。

 

例2:ある機能の実現方法について、既存のExcelやUML図に追記したが、設計手法がショボいためレビューNGとなり、再度手法の再検討が必要となったが、ExcelやUML図に追記した内容を削除するのがめんどくさい。

 

このような場合についても、リビジョン管理をしておけば、前の状態に戻す、即ち変更前のファイルを再度適用するだけで解決できます。

手動でリビジョン管理はめんどくさいから

リビジョン管理をしない場合、ソースコード以外の成果物で、修正前のファイルを残す場合、おそらくファイル名の先頭に日付をつけることで、過去ファイルの管理をしているかと思いますが、そもそもこの作業自体めんどくさくないですか?

 

ツールを使うことでこのような煩わしさもなくなると思います。

 

とはいえ、ぜんぶが全部やるのはめんどくさい

 ソースコード以外の成果物もリビジョン管理しようというと、なんでもかんでも管理ツール内にファイルをぶっこむ人もいます。

 

このファイルはリビジョン管理やる、やらないと選別がめんどくさいから、いっそのこと全部やるのももちろんありですが、下記のような成果物は、まあローカルPCや共通サーバ保存でもいいのかなと思います。

  • 会議用資料
  • テストで測定した波形データ
  • 上位者への説明用資料

まとめ

ということで、ソースコード以外の成果物もリビジョン管理をお勧めする理由をご紹介致しました。

 

リビジョン管理対象を増やすことで、ファイルを探すとか、管理するとか、そういうのを全部ツールに任せることで、開発そのものに専念できるのが最大の利点だと思います。

 

なので、成果物のリビジョン管理はぜひやってみてください。

 

 

 

【スポンサーリンク】