メモ

比較的、ボリュームの有るソフトを作ってるんですよね、最近(^_^;)
今は丁度、シュミレーターテスト中で、
デバッグ後半戦のゴールデンタイムって所でしょうか・・・

今回のソフトは三人で作っています。
コレは、私としても大変勉強になっているのですが、
人数が増える程、モジュール間のI/F に気を使う様になったり・・・
一人で書くと、意外とちゃんとしなくなっちゃう(^_^;)
各モジュールの責任分割とか・・・
まぁ、妥協しちゃうんですよね、きっと・・・

それはさて置き・・・
三人で書いていると言う事は、三人でデバッグもしてる訳です（笑）
そこで出て来るのが今回のテーマ。

勿論、誰でもバグ発見時には、まず原因を探し始めます。
探している最中に、先に対策が見つかっちゃう事が結構多いんですよね。
って言うか、対策は比較的早く発見出来る。
しかし、ソコが分岐点！！！
対策を選ぶか原因追求を選ぶか。
私が見て来た人は、対策を選ぶ人が多かったと思います。
もちろん、バグフィックスには時間の問題やユーザーの感情等、物凄いプレッシャーがかかります。
その中で、自分の世界に入り込んで原因追求を行うのは難しい事です。
でも、一箇所、原因不明な対策だけをとると、
必ず同じバグが形を変えて発生します。
オブジェクト指向のプログラムは特にソレで迷子になり易い傾向がありますね。
※再利用性が高いため？？？

このテーマは当たり前の事で、誰でも当然の事と理解してもらえると思のですが、
実は、ソレを実行出来ない事が多いんです。
心当たり有る方いらっしゃいますか？

ハイ！！
もちろん、私も心当たり大有りの有り太郎です(^_^;)

極力努力はしてマスが・・・
ま、コーディング中にかなり厳しく例外について考慮します。
外部モジュールとやり取りする引数は、基本的に信用しません。
自分で作るモジュール同志でも引数や戻り地を信用しません。
プログラム的には大変ロスが多いです。
また、処理も余分になります。
しかしこの無駄が、デバッグの原因追求時に効いて来ます。
コレで短縮出来るデバッグ工数を考えれば、
コレに必要なコーディングコストなんか屁でもないと(^_^;)
処理速度に関しては、今のハードではそこまで考える程のプログラムを書く人であれば気にするべきと思いますが、
殆どは気にする必要が無いと思います。
バグが発生せずに安定して動けばコメントアウトしちゃえば良いだけだし・・・

結局、何が言いたいか(^_^;)
バグは必ず原因を突き止めましょう。
その為に、原因追求し易いコーディングをしましょう！！
って事です。

Takamitsu Yagasaki Mobile Mail