読者です 読者をやめる 読者になる 読者になる

SourceMonitorでASP.NETのVB部分の複雑度を図った

結果

たぶん全部できた:+1:

課題

  • 「たぶん」全ファイル計測できた
    • めぼしいヤバいファイルは計測できてた、というだけ(この前アタリをつけて計測できなかったもの)
    • よく考えたら*.vbをコピーするときにファイル数計測しておけばよいのでは?
  • 実行に5分くらいかかった
    • 遅すぎ
    • こういうのは遅いとダルくなるのでもっと早くする必要アリ
    • まずは計測から。その後直す。
    • 関数呼び出しの方法が悪いのもある
  • ゲートチェックイン的に使いたい
    • (用語あってるかわかんない……)
    • チェックインごとに結果を流す
      • 流す先も用意しないと……。
    • グラフィカルに見たい
    • やばい変更を察知したい
      • そこを念入りにテストしたりね

明日1日で処理を軽くするところまで。

これまでとこれから

目標

  • きれいなコードにしたい
    • バグを減らしたい
      • テストが足りない?
      • テストが不足しているのかどうかもわからない
    • テストコードを書きたい
      • 自分の安心のために
    • 読みやすくしたい
    • 拡張性を高くしたい
    • 変更に強くしたい

ざっくり計画

  • なにはともあれ計測
    • 「におい」の計測
      • メトリクス
    • バグ件数とか
      • 画面別/機能別に
    • 他にもありそう
  • テストをcontinuousに実行できる土台作り
    • リファクタリングによるリグレがないことを保証しやすくする
    • サーバサイド + クライアントサイド
  • リファクタリング
    • 「におい」のきついところ ← メトリクス
    • バグの多いところ ← バグ件数

これまで

  • メトリクス計測
    • サーバーサイド(VB.NET)
      • OK
    • クライアントサイド(javascript)
      • Platoとか気になる

次回

javascript側のメトリクス測定してみる

読んだ

気になる

.NETではhttpのGETパラメータ → Objectのマッパーってないんだろか
型付きで扱いたいんだけど……。
自作するか迷い中。