演算子のオーバーロード：その２

演算子のオーバーロードを調べると、複素数の例が出てくることがよくあります。

これは一体実際にはどういった場面で使用するのだろうと考えているとよくわからないと思います。

私がC#で一番活用できて、身近な例としては、DataTime型の足し算・引き算がいいのではないかと思います。

C#の場合に、DataTime型の足し算引き算は出来ません。

例）
DataTime fromdate, todate;
todate - fromdate
ビルドが通りません。

コレをするためには、
TimeSpan ts = todate - fromDate;
と記述しなくてはならなくて結構面倒です。

そういったときに、演算子のオーバーロードを使用するといいと思います。

演算子のオーバーロード

最近、C#を使用しての開発がメインになっていて、Delphiを使用しているときにはなかった、演算子のオーバーロードってちょっと便利だなと思います。

最近はDelphiもDelphi7以降では、できるみたいですが、それ以前では出来ません。
演算子のオーバーロードは、独自のクラスに対する拡張するものなので、比較したりするのに、本当に便利です。

あくまでも静的コンストラクタなので、インターフェースでは使用できないので、インターフェースからアクセスするときには面倒だなと思う点はあります。

人に感動や感謝されること

今日、テレビを見ていると、おもいっきりテレビで司会をされていた高橋佳代さんが旅番組に出演していました。
そのときに、旅館の仲居さんから「いつも見ている人がいないと、なんとなく寂しい気持ちになります。」と言われて涙を流していました。

この涙には、約20年間、おもいっきりテレビの司会の為だけに人生を費やしてきたことによる自分の人生が間違っていなかった・あるいは人の役にたつことができたという思いがあるからこその涙だと思います。

私もいつかこんな風に色々な人から思われるような人になりたいと思いました。

仕様書を読むとわかる

最近、仕様分析をしていると、仕様書からバグりそうなニオイがすることがわかるようになってきました。

バグりそうなニオイがする箇所
1.仕様書に記載されている説明が曖昧。
2.本来、境界条件を持たなくてはならない箇所が制限事項が記載されていない。
3.ごちゃごちゃと仕様書に書かれている。
4.読んでいても意味がよくわからない。
5.この仕様はどうなっているのだろうと疑問に感じる。

1、3、4、5に関しては、言葉では表現しづらい部分があるのかもしれませんが、たぶん開発者もよくわからなくなってとりあえず、条件を記述しているのだと思います。
2に関しては、たぶん、制御するのを忘れてしまっている。

自分の中では大体これくらいで、なんとなく最近ニオイを感じ取れるようになってきたかなと思います。

プログラムでも不吉なニオイと呼ばれる箇所と同じ箇所ではないかと思います。

ソフトウェア開発の見積もりはあてにならない

最近は、かなり集中してプログラミングをしているので、私の中ではかなり楽しんでいます。

どちらかというと今までは、プログラミングをしていても、読みやすいコードを意識しないでいたかなと思います。
しかし、今はこうすると読みにくいとか、ここはこうしたほうが構造的には疎結合になるなとかをかなり意識してプログラミングをしています。

今日もある部分のアーキテクチャが破綻して、見直しを行いました。
作業的には昨日と変化はありませんが、それでも少しは前に進んだと思います。

やはり、ソフトウェア開発というのは、だから面白いし、工場の製品を作成したり、土木や建築の建物のようにはいかないものであると思います。
ファンクションポイントなどの見積もりの仕方などありますが、当たるときには偶然当たるし、当たらないときは本当に当たらないものです。

そういったことを勉強するよりは、良いアーキテクチャや使いやすいソフトウェアがどういったものかを考えたほうが時間の無駄は少ないと思います。

スキルが低いなと感じるとき

最近、プログラムをしていて思うことですが、私のスキルは低いなと思います。

例えば、アーキテクチャを考えて、試しに実装をしてみたときに、ああこれではダメだとか、このアルゴリズムをどうしようかと考えているときに、中々思いつかなかったりして、うまくいかないと思いました。

これが、スキルがある人なら、すぐに思いついたり、簡単にできてしまうのだろうと思います。

まだまだ、勉強や経験を積んでいなければならないと思いました。

使いやすいソフトウェア開発を目指して

Excelを用いて、表に文字や数値を入力してそれらを利用して、合計の数値を表示することをしなくてはなり、数値や文字列を入力しましたが、計算結果が表示されない。

なぜかと調べてみると、本来数式が入っている箇所に数式が削除されていることがわかりました。また、これはセルにIF分を入力したり、COUNTIFを使用すれば簡単に集計することができるのに元々のテンプレートに入っていなかったりと表示に面倒な作業をしました。

セルの編集をロックをかければ、使用するユーザーがオペレーションミスをして数式を削除したり、直接入力しても編集できないようになります。

数式を入力しておくことも非常に簡単なことなのに、入っていないなどすごく使いづらいものでした。

私達がソフトウェアを開発するときにも同様のことがいえると思います。ちょっとしたことですが、編集できない箇所は、ロックをかけておいたり等をしておくと、そこまでチェックしてくれているのだなと好印象を持ち、それだけでクレームだったり、他に使いづらい部分があっても、まあしょうがないかと納得することが出来ます。

本当にちょっとしたことで、使いやすいソフトウェアにもなるし、使えない・使いづらいソフトウェアになるのだなということを実感しました。

センター試験の日はいつも寒い

今朝、朝起きると、今シーズンで一番寒いな感じました。

雪国の人からすると、なんてことないと思うかもしれない温度ですが、事実、車に朝乗ったときにも、車の温度計は-1度を記録していました。

ニュースを見ていると、そういえば今日はセンター試験の日だったということを知りました。
毎年、センター試験の日はいつも寒く、毎年のように今日はセンター試験なんだということを思い出します。
私がセンター試験を受けた日も確かものすごく寒かったと思います。（何年も前の話なので、かなり曖昧）

これから受験生にとっては、試験が本格的に始まります。頑張って下さい。

テスト駆動開発(TDD)の仕方

今日、ある技術者の方と話をする機会があり、今度、「テスト駆動開発についての研修をします。」と話したところ、その人が以前、テスト駆動開発の勉強会をしたときに、テストコードを先に書くか、まず先に、インターフェースである程度のメソッドを記述してから、空の実装コードを書いてから、テストコードを書くかが議論になったそうです。

私は、テストコードを書いてからクラスを作成して、ビルドが通るようになってから、実装を書く派だったので、正直ビックリしました。

話を聞いてみると、クラスを利用する側視点にたったときに、クラスAとBがあり、それらを利用してクラスCを利用する場合に、クラスCのテストはするけど、クラスAとBを利用するコードを書かなくてはならないので、ある程度インターフェースを作成してから実装を書いていくといった理由だそうです。

たしかにあるなと思いました。正直、どちらが正しいということはないと思います。要は、バグが入り込まないようにするやデグレードをすぐに確認できればいいという目的を忘れなければいいのではないかと思います。

テスト駆動開発とテスト技術者

テスト駆動開発(TDD)で開発をしていると、本当に便利だなと思うことが良くあります。

例えば、あるメソッドを作成したときに、このクラスよりもこのクラスで持たせたほうがいいなとか、クラス構造を見直すときにも非常に約に立ちます。

テストコードがあるおかげで、メソッドを修正したり、クラス構造を見直したときに、デグレを引き起こしていないかをすぐに確認できるので、非常に便利です。

テスト駆動開発とテスト技術者が密接に関わってくると、機能テスト以降の工数はかなり削減されるのではないかと思います。
なぜかというと、テストコードがそれで足りているか、あるいは別のケースがないかをテストを専門にしている人が作成することができれば、効率よく単体テストを実施できるので、それ以降のバグが少なくなります。

私も実際に自分で、頭の中でロールを切り替えて行ってみたところ、別のケースを追加したときにダメだったパターンというものがありました。

単体テストのところに、テスト技術者が参加できるように、テスト技術者もプログラミング言語を最低一つは知っておくべきだと思いました。