テストコードは本当に約に立つ

このブログ上で、テスト駆動開発(TDD)について色々と書いてきました。

しかし、最近ある計算のロジックを変更する必要性がでてきて、修正をしていました。
そのときにかなり約に立ったのが、テストコードです。
ほぼ計算ロジックを作り直しに近い状態でした。
テストコードを確認すると、自分が新しく作成したテストコード以外は真っ赤になりました。

これがテストコードがまったくない状態で修正をしたら、ほぼ間違いなくデグレードを引き起こしています。

ようやく今日、すべてのテストコードをパスすることができて、Viewに組み込むところを行いました。

今回は、今までで一番テストコードが約にたったなと思います。

また自分のテストコードの質といった観点で、様々なパターンが用意されていて、効率がいいコードができたと思います。

ソフトウェアも医療も同じ行為

2週間ほど前から、ものもらいができてしまい、通院しています。

治療方法は、点眼と軟膏を塗って治療していましたが、一向によくならず悪化してしまい、いつも通っている眼科に本日いってきました。

そしたら、切開手術をするということでしたが、諸事情により、もう少し経ってから手術をしてもらう予定です。

ここ何週間か病院に通ってみて、人それぞれ相性というものや好き嫌いがあるので、なんともいえないところはありますが、私がいつも通っているところのほうがなぜそうなったのかや、どういった治療をするかを詳しく説明してくれます。

そういったところから安心感・信頼感などがうまれてきます。

私もソフトウェア開発にかかわっているので、デバッグをする際に、なぜこうなっているのか根本のバグの原因はなぜかを常に考えています。そうせずに表面上を取り繕ってしまうと、結局は破綻してしまいます。

医療もソフトウェアも同様で、ある程度の根本原因をつかんでそれに対して治療する行為をします。
詳しくアーキテクチャやロジックを説明できないということは、深くまで理解していないということになります。

医療も詳しく説明できないということは深くまで理解していないのかなと自分の仕事に置き換えて考えされる一件でした。

自分の限界は自分自身が決めている

最近思うことですが、自分の限界はいつも自分が決めているのだと思います。

なぜかというと、後少し頑張ればいいのにと思っていても、様々な誘惑があったり、甘いほうへ人というのは流れていきます。私もそうですが、楽なほうへどうしても行ってしまいます。

しかし、そこで自己を抑制して、楽なほうへ流れるのではなく、自分を追い込むわけではないのですが、技術者というのはストイックでなければなりません。

常に自身のスキルを磨いて、自分への投資をしていかなければ、すぐにサビついてしまいます。

そういった覚悟がなければ、誰かがなんとかしてくれるや誰かが教えてくれないとできないといったことになってしまいます。

つまりは、自分でなんとかしようという気持ちがなくては、まったく意味がないと最近特に思います。

自分もいつも楽なほうへ逃げてしまうので、自分でなんとかするんだという気持ちをもち続けなければならないと思います。

STAThreadについて

C#においてClipboardにデータを貼り付ける場合には、SetDataObjectをコールすると、Clipboardにデータを貼り付けることができます。

ただし、メインメソッドに、STAThreadAttribute属性をマークしなくては、ビルドでエラーになってしまいます。

[STAThread]
static void Main()

と宣言しなくてはなりません。

MSDNより抜粋すると、Clipboard クラスは、シングル スレッド アパートメント (STA: Single Thread Apartment) モードに設定されているスレッドでだけ使用できるようになっているからだそうです。

これは、COMを利用するために、付加する属性だそうです。まだ詳しいことはわかっていないので、なぜ、シングル スレッド アパートメントでしか動作できないのかはわかっていませんので、以下は間違いかもしれません。

アパートメントはCOMのスレッドモデルから来ているようです。

COMを利用する際に必要なので、このようにコードに付加されているみたいです。

内部でCOMを利用しているものがあるのでClipboardクラスで、使用する際には、[STAThread]を明示する必要があるようです。

苦労して初めて覚える

SubVersionで、トランクからブランチへマージを行いました。最初、マージをするのに、3種類あり、どれを選択したらうまくいくのかがわからず、色々と試してみたところ、あっさりと行うことができました。

間違った方向で試していたので、時間はかなりかかりましたが、実際にマージが動く仕組みは理解することができました。

何でもそうだと思いますが、自分で苦労してみて理解することができます。

例えば、パソコンが動く仕組みなどは、トラブルがあり、自分で解決策を見つけて、だんだんと詳しくなっていきます。つまり、色々なトラブルを経験したからこそ身についているものです。オブジェクト指向もしかりです。

様々なことを覚えようと思ったら、自分で苦労して見ることが必要です。

今日はソフトボールの練習

今日、久しぶりにソフトボールを行いました。
フリーバッティングをしているときに、ソフトボールの球というのは当たり前ですが、軟式のボールに比べてあんなに重いものなんだということを実感しました。

最近は、軟式野球しかしていないので、ボールが重たいということを感じることはありません。

ただ、今日のソフトボールの球は本当に重いなと思いました。
ソフトボールをするには、腕力というものが重要であることがよくわかりました。

ちょっと今から腕力を増やすことは並大抵ではないので、ソフトボールはやめておこうと思いました。

画面を作る楽しさ

最近、画面を作成することが本当になくなってきました。どちらかというとデータモデル担当になっています。

昨日と今日かなり久しぶりに画面を作成しました。それもWizard画面を作成しました。2日あればかなり進むもので、ほぼ画面が完成しました。
途中仕様を検討しているときに、ある設定の時には、この画面を飛ばして次の画面ということもありましたが、それも簡単にクリアすることができました。
結局は採用されることはありませんでした。別の方法で対応することになりました。

それにしても画面を作成するのって久しぶりに行うと、作業が進んでいることがわかるので楽しい、反面・文言を考えたり、画面構成を考えるという非常に手間がかかると思いました。

やっぱ自分は画面作成よりもデータモデルをテスト駆動開発で作成するほうが好きです。