スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「お約束の添付忘れ」を防ぐ

過失は恥じるべきだが、過失を改めるのは恥じるべきではない。
ルソー
「ファイルが添付されてませんが。。」
メールの添付忘れは嫌なものです。私も時々しでかしていましたが、最近特に連続したので、今更ながら対策を考え始めました (^^;)。

添付ファイル忘れ・・・を防ぐために身につけたい習慣 | POP * POP」の記事にあるように忘れないような手順を習慣化するというのもあるでしょうが、やっぱりミスはあるのでそこはツールで防ぎたい。ということで、まず簡単に思いつくのは、メールの内容に「添付」等の文字列があるのに、添付ファイルがない場合、送信時に警告する方法。単純な話ですし、誰かが作ってそうです。

ということでちょこっとググると、やっぱりありました。方式もまさに前述の通り。考えることはみんな一緒ですね (^^)。
いろんなメーラ毎に用意されているようですので紹介しておきます。

4774127280 私は使ったことはないのですが、JustSystemのShuriken Pro 4なんかは、もともとついているみたいですね。何だかんだで最もメジャーなメーラであろうOutlook Express/Outlookについては情報がひっかかりませんでしたが、こちらもビルトインで何かあるのでしょうか。ニーズはありそうですし。

ちなみに、たまたま調べていてあたったのがSOURCE NEXTの「スンドメール」。添付忘れは、送信ボタンを押した瞬間に気づくことが多いということで、実際のメール送付を遅延させ、しばらくの間キャンセルをきかそうというもの。面白い発送ですね。確かに、送信した瞬間に気づくことは多いのでこれで結構防げるのかも。

何にしても、エンジニアとして同じことを繰り返すのは再発防止ができてないとうことなので、とっても恥ずかしいです。何よりこういうところこそ、プログラマが力を発揮するポイントですしね。

ちなみに、私のメインメーラはMew + emacs on linux。ちょっとググった限りでは目的のものは見つかりませんでしたが、ちょっとelispを書けば済みそうです。私の場合なんちゃってemacserなので、あまり自分でelispを書きませんが、mew-sendに本文チェックするようなhookを入れれば済むだけでいいのかな。ちょっとやってみようと思います。

【関連記事】
gdbを電卓として使う

【関連書籍】
はじめてのBecky!Internet Mail2 勝田 有一朗
入門 GNU Emacs 第3版 Debra Cameron James Elliott Marc Loy
入門Meadow/Emacs 小関 吉則
やさしいEmacs‐Lisp講座 広瀬 雄二

【関連リンク】
添付ファイル忘れ・・・を防ぐために身につけたい習慣 | POP * POP

スポンサーサイト

このバグ直しますか? - 原因療法と対症療法

急なれば標を治し、緩なれば本を治す
実に久々の記事です (^^;)。今回はバグ修正のリスクについて書いてみます。

医療用語には「対症療法」と「原因療法」という言葉があります。表面的な症状の消失あるいは緩和を主目的とするのが「対症療法」、症状の原因となる疾患そのものを制御する治療が「原因療法」です。 完全回復や再発防止のためには原因療法が必要になりますが、事情によりそれがとれない時に対症療法がとられます。

対症療法を選択する理由はいくつかパターンがあります。そのひとつは、症状の原因が不明な場合。この場合、分かっているのは症状のみですから、対症療法以外すべがありません。原因はわかっていても有効な対策がわからない場合も同じです。風邪薬なんていうのはそうですね。
もうひとつのパターンは、原因療法に伴うコストやリスクが大きいた場合。手術をするにもお金がかかりすぎるとか、体力がもたないとかいう場合がそうです。その他、原因療法を施す前の応急処置として対症療法がとられることもあります。原因療法と対症療法は、排他的なものではなく相互に補完し合う関係にあります。

475614599X さて、この話は、ソフトウェア開発におけるバグ修正にも当てはまります。ソフトウェア開発における実装フェーズでは、バグの検出とその修正というサイクルが繰り返されます。このバグつぶし、デバッグという作業は病気の治療に似ています。そして、それは基本的には、根本原因をさぐってそれを直す原因治療として行われます。

しかし、これが製品リリース直前、あるいは、既にシステムの運用開始後、パッケージや組込みソフトウェアであれば製品発売してしまった後だったらどうでしょう。この場合は、不具合の原因がわかっていても、原因療法ではなく対症療法がとられることがあります。これは、修正のリスクを考慮してのことです。
このような運用直前あるいは運用中のケースでは、システムの品質は、一度は確認されているはずです。そして、バグの修正というのはそのシステムに変更を入れるわけですから、その部分の再確認が必要になってしまいます。しかし、大規模なシステムの検証コストは莫大です。全ての検証をやり直すなんてことはもちろんできません。よって、修正の影響範囲をしぼり、検証の範囲もしぼるということが必要になってきます。そこで、広い範囲に影響が及ぶような原因療法ではなく、見つかったバグの発生条件の場合のみに影響するような対症療法を選択するようなケースが出てくるのです。

別の医療用語に「トリアージ」という言葉があります。災害医療において、多数の傷病者を重症度と緊急性によって分別し、その対応方法を決める手順を指す用語です。このような緊急の場面では、重篤であっても救命不可能な患者は切り捨てられます。非常につらい選択ですが、できるだけ多くの命を救うためには必要な選択です。
運用直前や運用中のバグ修正も同じです。修正の時間は限られています。複数のバグがあったとしても、全てを修正して検証する時間はないかもしれません。つまり、バグの取捨選択が必要になります。先に書いたように対症療法でしのぐことによって検証時間を節約するというだけでなく、そもそも直さずにそのままにするという選択も時には必要です。検証コストを削減する一番の方法は、修正しないことですから。

分かっているバグを直さない、あるいは、原因がわかっていて根本修正もできるのに、表面的な回避しかしないというのは、プログラマにとっては非常に嫌な選択です。バグが見つかったら直したいというのが大半の意見でしょう。しかし、ソフトウェアの修正には、常にリスクが伴うということを忘れてはいけません。例え修正が正規のものであっても、隠れたバグをエンバグさせる可能性だってあります。マイナス×マイナスでプラスになっていたものが、マイナスになるかもしれないのです。修正したい気持ちは非常に非常に良く分かりますし、つらいのですが、ここはぐっと我慢が必要です。エレガントさよりも品質確保が重要なのです。

4873112990 ソフトウェア開発の現場では、「動いているコードはさわるな」ということがよく言われます。これは上のような話が背景にあります。しかし、これも絶対ではありません。時と場合によります。運用直前や運用中は、上のような対症療法が有効な場合が多いですが、開発に余裕がある場合は、原因療法でしっかり直しておくべき場合がほとんどです。
所詮、対症療法は一時凌ぎにすぎません。安易な解熱剤や鎮痛剤の服用と同じで、中途半端な回避コードは、不具合を潜伏させ、自体をより悪化させることすらあります。ですので、対症療法をとった箇所はきちんと管理し、適切なフォローをすることを忘れてはいけません。

不具合のない品質の高い成果物を作ることがプログラマ・エンジニアの役目です。この時、理想論に走るのではなく、限られたリソースの中でいかにそれを最大化するかを意識することが、プロのエンジニアとしては必要です。

# もちろん理想を追うのもわすれちゃいけません ^^)

【関連記事】
バグを潜伏させない工夫
デバッグと不確定性原理
デバッグ指向のススメ

【関連書籍】
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 F. ブッシュマン他
ソフトウェア開発の持つべき文化 IT Architects' Archive ソフトウェア開発の課題1
開発の現場 vol.007 - 運用・保守
ソフトウェアパターン再考―ソフトウェア品質学 各論 パターン発祥から今後の展望まで
達人プログラマー―システム開発の職人から名匠への道 Andrew Hunt
リファクタリング―プログラムの体質改善テクニック
人気エントリ
最近の記事
本のおすすめ

4274065979

4844337858

482228493X

4904807057

4873114799


最近のコメント
Links
プロフィール
  • Author:proger
  • 組み込み関係で仕事してます
ブログ内検索
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。