Loading...

個人開発でも、メトリクスするススメ

自分の生産性はどれぐらいなものだろうと思うとやはり計測してないとそれには答えられないなと。

お仕事だと、準備のできてるプロジェクトにいく場合、いろいろ決まり事ができてる状態で、 ベンダーがもつ過去のプロジェクトの資産があったりで、数値的な予測はたてられたりするけど、僕自身はどうなのだろうかと。

空いた時間でしか、いろいろ作れないので、ゴールを決めて、そこに到達するまで、どれぐらいのものを作らないといけいのか、どれぐらいの時間がかかるのか、知りたいなと思った次第。

まあ、経験で、《目標たてて、最後までいかないパターン》だなーと思うケースがしばしなのだけど、もしも実現するなら、どれぐらい《時間というコスト》がかかるのか予測をたてたい。

新しいことだと概念を学習する時間が必要だったり、調べものしたり、で時間がかかることはわかるが、不確定要素も見積もりできたらよい。

《メトリクスする》という言い回しが正しいかわからないけど、計測すること大事ということで、どう《自分の数値》ベースを知るか。

どこからはじめるかなというわけで、毎日書いたメモとか、ソースコードから、生産量をはかろうかなと。まあ、アイデアとしてFLOC(File Lines Of Code)を使い、毎日、記録をとる。ソースコードのコピペとか定型文とか、コメントとか考慮に入れず、ライン数のみで数える。

LOC(Lines Of Code)って手あかにまみれた指標だけど、比較する対象が、 《自分》だけなら、なにか見えてくるのではなないかなと期待。

LOCとバグ数って、まあ、とりあえず集めやすいし....

どのタイミングで数値を集めるかは、一日の作業終了時に記録をとるかんじかな。

ただのライン数だけど、前日の計測値とくらべて、《どれぐらい変化》があったかで、生産性みたいなものを計るための指標にできないかというのがいまのアイデアです。

削除されたラインでも《その前の状態(前日)》と比較すれば、そのダイナミズムみたいなものはわかる。

収集するのは、
ファイルパス、ファイルサイズ、タイムスタンプ、ファイルの内容のハッシュ値。

収集するときのロジックは、

a.前日(前回)収集されていないものであれば記録する。
b.ファイルのタイムスタンプとファイルサイズを前日のものとくらべて、変化があれば、そのライン数を記録する。
ただしタイムスタンプが変更されていて、ファイルサイズが同じ場合は、ファイルのハッシュ値をもとめて、違いがあれば記録する。
 
という感じになるのかな。

 収集対象外のファイルも指定できたらよいなー。

記録を格納するのは、db(javaならH2とか)に。












リアクション: 
メトリクス 6597484834056132519

コメントを投稿

ホーム item

このブログを検索

Random Posts

Popular Posts

Labels

ADS