SourceMonitorでASP.NETのVB部分の複雑度を図った
前
結果
たぶん全部できた:+1:
課題
- 「たぶん」全ファイル計測できた
- めぼしいヤバいファイルは計測できてた、というだけ(この前アタリをつけて計測できなかったもの)
- よく考えたら
*.vb
をコピーするときにファイル数計測しておけばよいのでは?
- 実行に5分くらいかかった
- 遅すぎ
- こういうのは遅いとダルくなるのでもっと早くする必要アリ
- まずは計測から。その後直す。
- 関数呼び出しの方法が悪いのもある
- ゲートチェックイン的に使いたい
- (用語あってるかわかんない……)
- チェックインごとに結果を流す
- 流す先も用意しないと……。
- グラフィカルに見たい
- やばい変更を察知したい
- そこを念入りにテストしたりね
明日1日で処理を軽くするところまで。
これまでとこれから
目標
- きれいなコードにしたい
- バグを減らしたい
- テストが足りない?
- テストが不足しているのかどうかもわからない
- テストコードを書きたい
- 自分の安心のために
- 読みやすくしたい
- 拡張性を高くしたい
- 変更に強くしたい
- バグを減らしたい
ざっくり計画
- なにはともあれ計測
- 「におい」の計測
- メトリクス
- バグ件数とか
- 画面別/機能別に
- 他にもありそう
- 「におい」の計測
- テストをcontinuousに実行できる土台作り
- リファクタリングによるリグレがないことを保証しやすくする
- サーバサイド + クライアントサイド
- リファクタリング
- 「におい」のきついところ ← メトリクス
- バグの多いところ ← バグ件数
これまで
- メトリクス計測
- サーバーサイド(VB.NET)
- OK
- クライアントサイド(javascript)
- 未
- Platoとか気になる
- サーバーサイド(VB.NET)
次回
javascript側のメトリクス測定してみる
読んだ
- レガシーコードとの付き合い方とテストでの話
- 「レガシーコード対応を支えるツールやプラクティスはすでに様々なものが普及している 活かさないのは、今や罪」
- 僕「んぐぅ……」
- 人のところは特に念入りに実践したい
気になる
.NETではhttpのGETパラメータ → Objectのマッパーってないんだろか
型付きで扱いたいんだけど……。
自作するか迷い中。