「静的プログラム解析ツールの実力は？」記事へのコメント

出てくる警告にどう対処するのかが問題

[okky (2487)]

警告を無視したり、出てくる指摘に「逃げる」ようなコードで対処するプログラマばかりの世界では、まったく品質は向上しない。そして困ったことにそういう所こそ、品質を向上させなくてはいけない元凶だったりする。

# しかも、周りがヤイのヤイの言っても、今まで一度も直らなかったぐらい
# 上から下まで、ものを判っていない。

というわけで、このようなツールを使ったからどう、という事ではありません。
このようなツールの出力にどう対処するかが問題。また、このようなツールが
出してくる警告の量から、プログラム改善にかかる時間を正確に見積もる、などの
マネージメント能力も大事でしょう。

--
fjの教祖様

Re:

[Anonymous Coward]

とあるデーモンがcoreを吐くと顧客から指摘されて、「では、ディレクトリの書き込み権を削除します」と対応した自称スーパーハッカーがいたなぁ・・・
今、そのシステムはインフラの一部としてまだ稼動しているようです。

# さすがにAC。

Re:出てくる警告にどう対処するのかが問題

[Anonymous Coward]

仕事としてシステムを開発する場合は、プログラムの「美しさ」だけでなく「コスト」も意識すべきです。
少なくとも「美しくない」=「間違い」ではありません。

顧客の「デーモンがcoreを吐く」という要望に対しては
- 美しいが高コストな方法： デバッグ、ソースコードの修正を行い、coreを吐かないようにする
- 美しくないが低コストな方法: coreを吐いても、coreファイルを保存しないようにする
という感じで、複数の選択肢があります。

ここで後者の低コストな方法で顧客が満足してくれるのなら、何も問題はないと思います。

# 本来は、ちゃんと顧客に複数の選択肢があることを説明した上で、どちらか一方を提案するべきですが。

Re:出てくる警告にどう対処するのかが問題

[okky (2487)]

同じ事を逆向きに言っているだけではあるのですが。

少なくとも「美しくない」=「間違い」ではありません。

これはあちらこちらで何度も聞くが、じゃぁ「間違っていないコード」を見るとたいてい「美しい」。

醜いコードが醜くなるのは、例外の固まりになるから。そして例外だらけのロジックは大抵煩雑で(複雑ではなく煩雑で)、人間の誤りを誘発する。しかも例外ケースは滅多に走らないため、『動いているシステム』であってもバグを内包したままである確率はきわめて高い。

もちろん、そのようなコードが「あとどれぐらい使われるのか」によっては、直すコストより放置して問題が起こったときに対処するコストの方が安い(期待値として)と判断されるかもしれない。しかし、それは「障害対策コスト」と「障害発生確率」から算出されるべきであって、

『醜くても動いているんだからいいじゃん。直すのにコストかかるし』

は、さすがによくない。

--
fjの教祖様

Re:

[Anonymous Coward]

仕事としてシステムを開発する場合は、プログラムの「美しさ」だけでなく「コスト」も意識すべきです。

だからといって、coreを吐くほどのレベルの問題を放置して平気でいられるほどの厚顔無恥さを誇られても。 バケツでウランを運んでれば確かにコストは抑えられますとも。