処理性能向上のために

今日、一日ある部分の処理がどうしても重たくなってしまうということで、パフォーマンスチューニングを行っていました。

元々は、ループの回数が非常に多く発生していたので、抑制しましたが、データによっては、逆に遅くなってしまうという修正になってしました。

そもそもボトルネックの箇所は、どこだろうと調べていくと、抑制したなかのメソッドの処理が非常に遅いことがわかりました。

結局は、抑制した処理は必要なく、ボトルネックの箇所を修正すればすべて解決となりました。

パフォーマンスチューニングのコツは、まずはループの回数を減らすことであるなということです。

それでもダメな場合には、ハードウェアを増強したりする必要があります。

ソフトウェア開発でもプログラムでもボトルネック（制約条件）を発見して、解決することが速度を向上させるのだと思います。

根本は同じ考え

現場の仕事がバリバリ進む ソフトウェアテスト手法 高橋 寿一,湯本 剛 技術評論社 このアイテムの詳細を見る

かなり前に、出版された本で、私も持っていましたが、しばらく人に貸していたので、すっかり内容を忘れていましたので、朝出社すると、始業開始時刻の前に読んでいます。

読み返していると、普段、テストエンジニアやマネージャとして行っていることは間違っていなかったなということがわかりました。また、広く色々なことが書かれているので、非常にためになります。

ただし、テストケース作成のところで、状態遷移テストの自動化など一部どのようにするのかが詳しく書かれているわけではないので、疑問に思うことはあります。

私の勝手な考えですが、高橋 寿一さんの考えは非常に私は好きな考えで、根本にあるのは高橋さんには失礼かもしれませんが、同じであると思いました。

テストケースをテストコードに登録

テストコードにできる部分は可能な限り、自動化できるようにしています。

新たな試みとして、本来のテスト駆動開発とは異なりますが、テストエンジニアが作成したテストケースをテストコードにすべて登録しています。

これによるメリットは、手作業でテストケースを実行しなくなるので、テスト実施時間が短縮される。何度も繰り替えて実行することができるので、デグレが起きていることがわかるなどがあります。

そんなメリットばかりだけではなく、実際に行ってみると、テストコードが正常に書かれているのかが疑問を持つことがあります。これは、大きな課題です。
コレを解決するために、実装の部分を一度、コメントアウトして、赤くなることを確認してから実行するようにしています。

まだまだ、始めたばかりの試みですが、ある程度成果がでてくるのではないかと考えています。画面周りは手で確認したほうが確実なので効果は薄いと思いますが、計算処理やメソッドを確認するものであれば効果はあるなというのは実感しています。

コードレビューをしなくては：大いに反省しました

先日、ある実装部分にサンプルのコードを作成しようとして、たまたま開いたコードがあり、なんだこれはというソースコードを発見しました。case文が非常に多く書かれていて、それもディスプレイで開いたときに表示しきれないほどでした。

正直、自分がレビューを怠っていたせいもあり、自分自身を反省するのはもちろんのこと・そもそもなぜそのようなコードを書いたのかを確認したところ、実装したプログラマ自身もその当時はあまりよくわかっていなかったということでした。

これは、ペアプロでもコミット時に確認をするなり、コードレビューをするべきだったと非常に反省しました。

その後もすこしずつ確認したら、メソッドのパラメータが非常に多かったり(まとめることができました)、していたので、その場で注意をしました。

やはり、コードレビューは必要だなということを強く感じました。

Windows7を動作させてみた

今日、初めて、Windows7を動作させて見ました。

率直な感想は、WindowsVistaユーザーにとっては、ユーザーインターフェースがXPからVistaのときのように大幅な変更が無いので、スムーズに移行できるのではないかなというものでした。

また、実際にペイントがリボンになっているものを見て、本当になっていると思いました。

正直、ファイルのコピー&ペーストやネットワーク間のファイルのコピーをして動作がどのように変更されているのか・改善されているのかはわかりません。

少しずつ動作させてみて、色々と試していきたいなと思います。

不可思議な現象：GCの続き

あるサンプルプログラムで、GCを2回コールしないと、GetTotalMemory内のメモリが破棄されないところですが、どうもGC.Collectをコールしてもすぐに、ガベージコレクションが発生するわけではないという結論になりました。

私もこれは、非常に自信があるわけでなく、先輩に相談してもやはり同様のことが得られたので、たぶんそうではないかということになりました。

メモリ管理からは開放されて非常に楽ではありますが、ブラックボックスになっている部分が多々あるので、自分で管理してもいいのかなと少しだけ思いました。

今、メモリ管理のブログラムを作成したら、まちがいなくメモリリークはするだろうなと思います。

成長している？

最近、なぜかよくわからないことですが、色々な人に技術的な相談などを受けることがあります。それも同一のプロジェクトならわかりますが、別のプロジェクトの人たちからです。

基本は同じフレームワークを利用しているので、それなりの知識も経験もありますが、基本的なクラス構成をどのようにするかや実現方法をどうするかなどを私に聞いてくる場合があります。

今まではあまりなかったことですが、もしかしたら少し成長？（笑）しているのかなと勝手に思います。

技術的なことを相談されれば、わかる範囲内であれば即答できるし、わからなければ調べたりすることを欠かさずしてきたからなのかと思います。後は、フレームワークである程度、読みやすいコードがあったので、なるほどなと思いながら実装してきた成果が少しずつでてきたのかなと思います。

継続的に学習し続けて、さらに読みやすいコードを書くように努力し続けなくてはなりません。

不可思議な現象：GC

今日、List<参照型>にデータを追加して、GCを強制的に発生させた時に、GCを一度コールしただけでは、ガーベジコレクション対象のオブジェクトが破棄されないという現象がありました。(GC.GetTotalMemoryの値が0でない)

以下にサンプルを示します。非常に不思議なのが、stringも参照型なのに、List<string>は正常に動作するのに、独自で作成したクラスの場合には破棄されません。GCのところはサンプルのようにするとGC.GetTotalMemoryの値が0になります。

最初に、GCが別スレッドになっていて、遅延発生かなとおもい、しばらく待っていてもだめでした。

internal class 参照
{
public 参照(int 値)
{
m_数値[0] = 値.ToString();
}

~参照()
{
}
private string[] m_数値 = new string[1000];
}

public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private const int カウント = 100000;

private void button1_Click(object sender, EventArgs e)
{
List<string> List = new List<string>();
for (int i = 0; i < カウント; i++)
List.Add(i.ToString());
}

private void button2_Click(object sender, EventArgs e)
{
List<参照> List = new List<参照>();
for (int i = 0; i < カウント; i++)
List.Add(new 参照(i));
}

private void button3_Click(object sender, EventArgs e)
{
long メモリ = GC.GetTotalMemory(false) / 1024 / 1024;
MessageBox.Show(メモリ.ToString());
GC.Collect();
Thread.Sleep(1000);
GC.Collect();
メモリ = GC.GetTotalMemory(false) / 1024 / 1024;
MessageBox.Show(メモリ.ToString());
}
}

ボトムアップ開発？

製品を開発する上で非常に重要なことは、成果物がどのようになっているか・実際にデータがあるのなら、どのようなデータが必要かということをアウトプットから開発を行います。

ボトムアップ開発とも言うそうです。

中々これができない人がいます。エンドユーザーの業務内容から入らずに、機能ありきで考えてしまうためにできないのだと考えます。

ソフトウェアのテストをするときも、データがどのように流れていき、成果物はどのようになるかを考えるので、できるとは思います。

そのように考えていけば、操作性の問題はあるにせよ、使われないようなシステムはできないような気がします

Androidでカメラを起動がうまくいかない

Androidアプリで、ドラゴンボールのスカウターを作成しようと思い、カメラを起動して、撮った写真を基に、戦闘力を測定しようとするものを作成しています。

ただ、問題なのが、どうもカメラを起動することが正常にできていないようで、エラーになってしまいます。

SDKを見ながら、Camera.Open()でできるのかなと思いましたが上手く行きませんでした。

サンプルコードを確認しようと、ネットで検索してもあまり有効な情報を現段階では得ることができていません。

なんとか、明日にはカメラを起動できるところまでできるといいなと思います。