色んな所に意味と意図がなければなりません。。。当たり前か。･･･(･∀･i)ﾀﾗｰ･･･

黙々とソフトウェア対応！　(*´∀`)ﾉ

こんばんは。
キテレツです。

今日は黙々とソフトウェア対応な一日でした。

エラー処理の部分をもうすこし・・・(=ﾟωﾟ)ﾉ

という希望要望（指摘事項）を頂きました。
アレコレと想定を思案しながら作ったものなのですが、まだまだ抜けがあったようです。

レビューしていただいた方に感謝！！

主には例外のキャッチ方法や例外の処理のやり方です。
例外をキャッチした時に完全に処理を止めてしまうのか止めずに進むのか。

もともとは例外で処理を止めるような作りだった部分も、実際に運用してみたら止めないほうが良かったなって判断など臨機応変に対応です。

例外のデバッグを・・・

可能な限り、現実に起こりうる例外を発生させてテストするのが望ましいのですが、現実的に非常に難しい場合もあります。

そんな時は、ソースコードに例外発生コードを埋めてテストするしかないですね。
テスト仕様書にもそのように記載してテストを実施です。

これ、想定が的を得ていなければ無意味なテストになってしまうので危険です。(^_^;)
例外の種類もアレコレ想定しなければならないのですが、これも漏れないように注意です。

プログラムは起動している。でも正しく動いていない。

という症状をどのように検出するか。
そもそもの設計しそうなのですが、これを意図的に発生させることが難しく。。
どうやったらいいかわからず、話し合いの結果、結局

このへんで例外が発生するはず！！(=ﾟωﾟ)ﾉ

という所に例外コードを書いて実施となりました。
マイコンの場合は良くあることなのですが

(´・ω・)ﾉ　「メインループが動いているのに、割り込み処理動いてない」

という症状ですね。
Windowは画面上に表示されているんですが、定期的な処理が止まってしまっているって症状。
擬似的に作るしかないので、何処で止まりそうなのかを予測して擬似的に再現です。

そもそも、、Windowsアプリケーションでそんな事が起こるのか？？？･･･(･∀･i)ﾀﾗｰ･･･

という話も出たのですが、何事も想定の範囲外に対応するべきだろうとなりました。
ログさえしっかりと残すようにしていれば、「もしも」が発生しても追っかけることが可能ですし。

さぁ、レビューだ！

ひと通り対応はできた様子なので、明日、明後日とレビューに出します。(*´∀`)ﾉ
何事も無く無事に通ればいいのですが、、、、残念ながら実際の動作環境でテストすることができないので、想定される環境での実施レビューですね。

コードレビューとかでも指摘事項があったので、それも対応しました。

コードに意味を持たせること

これ大切なんだなと改めて実感。(´д｀ι)
コメントが大量になると、コードが読みにくくなっちゃいますね。

まれに、１行づつにかなりの量のコメントが書かれているコードと遭遇しますが、、、そうではなくて

コメントは処理毎にまとめて書いておく！(*´∀`)ﾉ

と言うのが良さそうです。
さらに、コード見て分かるような感じであればコメントも無理には書かない
んが、

コードに意味をもたせる書き方とそれを読み取る力

は、その人のセンスと経験によるので、、、、少ないコメントでコードから意味を読み解く人に遭遇すると尊敬の眼差しで見てしまうキテレツです。