デシジョンテーブルについて

ソフトウェアテストの書籍を読んだり、情報処理試験でも必ず出てくるデシジョンテーブルで初心者のような疑問があります。

デシジョンテーブルを活用すると、テスト項目の漏れなどをなくすため活用するとあります。

確かに、コンピュータはデジタル（ON/OFF）で動作するので、条件部に、YまたはNを記述するのはわかります。

デシジョンテーブル自身が大きくなったら分割することもわかります。

ただ、これをテストする立場になったときに、これだけを見て果たしてわかるでしょうか？

私だったら、この表を見たらちょっとテストする気にはならないなと思います。

非常に基本的で、合理的なものなのはわかりますが、現場でこれが果たして使用できるのでしょうか？

多分、組み込みソフト意外は、NOではないかと思います。

いきなりブレークポイントは使用しない

自分で作成したソースコードが正しく動作しているかどうかを検証するときに、現在の私はまずは、ソースコードを1行ずつ確認して、正常に動作しそうだなと思ったら、テストコードを通すようにしています。

それで、テストコードが通らなかったら、まず自分のソースコードがどのように動作しているかを、裏紙などに手書きで、パラメータがどうなっていて、このときはこのように動作すると、確認しながら進めます。

それでもわからなければ、ブレークポイントをつけて、トレースしていくことを最近はしています。

いきなりブレークポイントをつけると、確かにデバッグの速度は早いと思います。
しかしそれでは、自分で考えることをしなくなってしまうので、まずは遅くても自分で考えてから、どうしてもわからない場合は、使用するように最近はしています。

このようにすることで、自分で考えて、どこがいけなかったのか・その原因はなんであるかを考えると同じような失敗をしなくなってきました。

人それぞれスタンスはあると思いますが、私にとってはこれが一番効果があるなと思います。

自分も気をつけなくては

今日、ある部分でバグが発生して調査してみると、本来は、設定をみて、+1するのか、-1するのかを分けなくてはならない処理に誤りがあることがわかりました。

本来は、それを利用する側はそのことを意識しなくてはいいように、内部構造を考えておかなければならない個所を利用する側で、+1したり、-1したりしなくてはならないと、なんとも非常にメンテナンスがしづらいコードになっておりました。

今回は、その対応をすれば、修正は完了となります。

テストコードがないので、急ぎだったのでその場の対応になってしまったことが後悔です。

しかし、しっかりとテストコードを書いて、リファクタリングをする必要があるなと思いました。

久しぶりに、そんなコードを見たので、自分もそういうコードを書かないように気をつけなくてはなりません。

memberwiseCloneについて

今日、後輩のコードレビューをしていると、MemberwiseCloneを使用して、コピーをしている部分がありました。

return this.MemberwiseClone()と書いてあるので、参照型の場合に正しい結果が得られないといいました。

しかし、テストコード上では正しく動作しています。

ヘルプを調べるとわかりますが、以下MSDNの抜粋。

MemberwiseClone メソッドは、新しいオブジェクトを作成し、現在のオブジェクトの非静的フィールドをその新しいオブジェクトにコピーすることによって、簡易コピーを作成します。フィールドが値型の場合、そのフィールドはビット単位でコピーされます。フィールドが参照型の場合、参照はコピーされますが、参照先オブジェクトはコピーされないため、元のオブジェクトとその複製は同じオブジェクトを参照します。

テストコードを書いても、オブジェクトを参照するので、テストコード上では正しく動作します。

こういったものはコードレビューをしないと見つからないと思いました。

MemberwiseCloneを使用するときには注意をしなくてはならないと思いました。

ロボット：プログラミング

最近、興味がある分野にロボット開発ってどうなっているのか・どうやったらプログラミングができるのかなと調べていたら、Microsoft Robotics Studioという開発ツールがあり、なんとC#で作成することができることがわかりました。

ハードウェアの作成は無理ですが、ソフトウェアの作成をDirectXを用いてシュミレーションすることができるようです。

商用は有償になりますが、そうでなければ、無償で開発することができます。

基本的には英語版なので、レファレンスなどももちろん英語です。

英語を読むのは非常に苦労しそうですが、わからないところは、ソースコードを見て、いけばたぶんわかるだろうと安易に考えています。

それにしてもMicrosoftってすごいなと思います。

技術の進歩

先日、右目にものもらいができてしまい、切開手術をしてもらいました。

その際に、当日から4日間は頭も顔も洗ってはダメということで、Ｔ字型の髭剃りを使用している私にとっては髭剃りをどうしようという問題がありました。

そこで、妻に相談して、電気の髭剃りを購入しました。購入したのは、Panasonicの4枚刃の髭剃りで値段は割りと高いものにしました。

そうしたら、Ｔ字型の髭剃りでそった後のようにきれいにそれてスゴクビックリしました。

数年前に、ある製品を購入したときには、肌が荒れてしまいそれ以来Ｔ字型を愛用していた私にとっては技術の進歩はすごいなと思いました。

Panasonicの4枚刃の髭剃りは個人的にはかなりお勧めの商品です。

興味を持つことが基本

何事もそうですが、興味を持つことが重要です。

仕事でもプライベート的なことでもそうです。

興味を持って、それに対してどのようになっているのだろうか？と考えて、調べることが自身を成長させるのだと思います。

例えば、Windowsが動く仕組みにしても、これを実現するためにはどうしているのだろうかと考えて、調べることで動く仕組みを理解することはできます。
また、仕事の流れにおいて、これはなぜ必要なのだろうか？どうしてしなくてはならないのか？と考えなくては成長はできません。

色々なことに興味を持って調べることが重要です。

ちなみに私の今の興味はロボットです。

基本は繰り返し

ある程度の経験を積んできて、知識なども増えた段階で、昔読んでいた本を読み返してみると、非常に重要だったり、基本的なことを理解していなかったなということがあります。

例えば、Windowsが動く仕組みやオブジェクト指向のことを書籍を読んでいると、本当にそう思います。

今までは、無意識の中で行っていたことが、意識したり、再度勉強になることがあります。

人から言わせると、いまさらそんな本を読んだところで意味がないよといわれます。

しかし、私は強く思うのが、ある程度経験をつんだ今だからこそ、基本が重要なんだと思います。

メジャーリーグにいったイチロー選手も基本を大事に、練習では基本的なことを常に意識して、練習をしているそうです。

私たちソフトウェア開発に携わるものも一度学んだからいいのではなく、基本的なことを繰り返し・繰り返し学習をしていかなければならないと思います。

仕様の整合性の確認

ソフトウェアのテストをしていて感じることは、仕様が本来の仕様と異なる場合のものを発見するのは非常に困難だなと思います。

仕様書などのドキュメントがあってもそれが間違っていたりしたら、いくらテストをしても間違った仕様でテストをしてしまうので無駄な作業になってしまいます。

本来であれば、その業務に非常に精通しているか、顧客に対してあるいは要求のオーナーに対して日々確認をすぐに取れる状態なら発見することができると思います。

しかしそれも中々困難を極めると思います。

本来の仕様との整合性を確認するのは非常に難しいと思います。

これは非常に重要な課題であると常々思います。

業務知識も必要

最近、特に思うことですが、プログラマという人種は、プログラムのことだけ分かればいいわけではありません。

作成するソフトウェアを使用するべき人の業務知識が必要になります。

業務知識がまったくないと、顧客とコミニケーションをとることもできませんし、提案することもできません。

業務知識をまったく知らないでいいのは入社して間もない人だけです。

優秀な人ほど、プログラミングの知識だけでなく業務知識も豊富にあるなと思います。

どうすれば業務知識が身につくかというと、興味を持つこと・疑問に思うことが必要です。

なぜ、その業務をしているのか、その背景にあるのはどういったことかを注意深く観察することです。

そういった気付きがないと、ユーザーのところで業務を見ていても何も気付きを得ることができません。

まずは、疑問に思うこと・わからないことを質問する為の最低限の知識というものが必要になります。