kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

C#をいじった日

今日も昨日の続きでログパーサをせこせこと。やはりC#は楽しい。アルゴリズムはそう難しい物でもないけれど、物を作るときのポリシーとして、「必ず一つ新しいことに挑戦する」というのがあるので、あまりあきもこない。
今回の「新しいこと」はHashtable。が、これが思いっきりはまった。いや、たいしたはまりではなく、気付いてみればなーんだという感じ。しかし、世の中には同様に困っている人が数年前からいる事がわかってちょっとうれしい(^^;。この辺はウェブリブログで執筆中(ちょっとまとまってないので公開はまだ)。
それにしてもHashtableの使い方をぐぐってみたら、日本語ではKeyと数値を入れる物ばかり…ふつー値に入れるのはクラスでしょう(暴言)。本日の労働は8:30〜20:30ってところ。


隣の人が、なにやら(部内製)工程管理ツールの概要紹介を読んでいたので、ちょっと見せてもらう。うーん、なにやら自発的に使われなくなるツールのにおいがぷんぷんする。プロジェクトをお金とバグの結果しか見ないためのツールになっている。それも正しいけれど、一面の見方だと思う。上司が見る分にはいいのだけれど、実際に使う現場の開発者が使うツールではない。あ、上司だけのツールになるのかな?だったらいいけど。
この部署で失敗がはびこっていたり、ちゃんとした統計になっていない(結果のための統計をひねり出す事が半ば慣例になっている)理由はバグトラックができていないからだと思っている。まず成果物がちゃんとあって、そのツールに成果物を理由を添えてcheckinして、生成はそのcheckinしたソースリポジトリから定期的に自動生成される。リリース時にはそれ以外をさわってはならない。できればパッケージング(この場合setupプロジェクトの完了)まで自動でやる。
そういう風にやれば少なくとも、バグ件数が〜とか悩みながら後付でひねり出す事なんてないだろう。今時は手元で生成が当たり前になって、TDDをするならば、checkinしたタイミングではgreenの状態になっていて当たり前。なので、どうしても統計を取りたければ修正差分の規模とか、もう少し違う視点も必要になるんじゃないかな。