プログラミングにおいて、あるエラーに引っかかっている際にこうすればうまくいくかもしれないという曖昧な方法でそのエラーを対処することに成功した場合、そのうまくいった理由を考察するべきでしょうか。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答11件
0
「あるエラー」は解消されたかもしれませんが、あなたが気が付いていないだけで、「別の問題」が発生しているかもしれません。
リスクを軽減するには、考察を進める必要があると考えます。
視点を変えると、たとえエラーが起きていなくても動作原理の分かっていないコードを使うべきではありません。
今回、エラーがあることが調査する契機になっていますが、エラーがなくてうまく動作しているように見えても同じです。
「あなたが知らないコード」は、「あなたが予想できない動作を発生させる可能性があるコード」です。
「予想できない動作」をバグといいます。
バグをなくす為には、あなたが書いたコードを、あなた自身が良く理解している必要があります。
Re: Alberta_Fagni さん
投稿2017/12/09 15:07
編集2017/12/10 02:55総合スコア18156
0
こんにちは。
あるエラーに引っかかっている際にこうすればうまくいくかもしれないという曖昧な方法でそのエラーを対処することに成功した場合、
これってよくありますよね。仮説を立てて「実証」できたということですね。まずはほっとする瞬間です。
そのうまくいった理由を考察するべきでしょうか。
忙しい時、ついついサボりたくなりますようね。まじさぼっちゃうことも...でも、結構高い確率でしっぺ返しがきます。早めに顕在化してくれれば良いのですが、客先で顕在化するとなかなか嫌なものです。
私自身はできるだけ、その対処が正しいことの確信が持てる程度まで確認するよう心がけてます。
必要部分を十分に把握できていないケースでは頭痛いです。可能な範囲で努力して、それでもダメならその状況を上司へ報告したり同僚と共有したりしておいた方が良いと思います。自分一人で抱えていると誰もフォローできませんから。
投稿2017/12/09 15:23
総合スコア23272
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
理解できてないまま、コピペのツギハギや、
場当たり的なデバッグや修正をガチャガチャやってても、
運良く動いてしまうことも、現実にはあるでしょう。
しかし、正しく理解して、正しく動かすのが、プログラミングの正攻法です。
目の前の面倒ごとを早く片付けたいという気持ちは分かります。
teratailでも、エラーメッセージを読まないような質問者は多いですし。
しかし、理解することで次回以降のデバッグが早くなっていって、
結果的に早く作れるようになるんです。
デバッグや不具合対応が一番時間かかるから。
一方、「たまたま動いたからいいや」とか表面的な解決だと、
いつまで経っても同じミスを繰り返してしまうわけです。
もう少し深く掘り下げます。
たんなるタイポ(タイピングミス)とかではなく、
難度の高いバグ、レアケースのバグに遭遇した場合は、
バグが容易に理解できない、動いても理解できないかもしれません。
理解するのが正攻法ですが、時間が取れず、完成を優先させたい場合もあるでしょう。
そういうとき、コメントに「なぜか動いた」とか書いて済ますのではなく、
全体のコードを保存しておいて(そもそもバージョン管理で履歴を取るのが良い)、
バグレポート(バグ票、不具合票とか、いろいろな呼び方がある)を書きます。
そこには、バグの発生条件、または再現方法と、本来の仕様、想定した動作を書きます。
バグレポートが溜まっていくと、バグ発生の条件を絞り込めます。
また、時間が取れたときには、そのレアなバグを再現させる
テストを書いたりして、原因追求を進めていきます。
非常に面倒ですが、こうしてバグの原因を特定していくと、
システム全体が安定してきます。やらないと不安定なまま。
開発規模が大きくなるほど、そういう地味なバグ管理が重要です。
そういう技術的資産と負債の差が、何年か経つと大差になるわけです。
ここら辺の話は、以前にも回答したので、リンクを貼っておきます。
投稿2017/12/10 06:11
総合スコア5592
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
ベストアンサー
そのうまくいった理由を考察するべきでしょうか。
考察するのはうまくいった理由ではなくなぜエラーになるのか
ではないでしょうか。
原因がわかっていないのにうまくいった理由だけ考えても意味がないです。
例えばある計算処理の結果がなぜか1多いから、とりあえず1引きました、って言ってるようなもんです。
なぜ1多いかを解明しないといけません。
まあ、うまくいった理由を考察すれば自ずとエラーの原因も見えると思いますが、スタート地点を改めた方が良いと思いますと言う回答です。
投稿2017/12/13 05:48
総合スコア16996
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/12/19 10:45
0
根拠のないブラックボックスを経由する形での結果的な成功は危険です。いつどこで、結果が変わるかわかりません。
以下、参考
ちなみに、ブラックボックスの過信はクラッカーの格好の的となります。便利ツールに見せかけた(便利機能自体も搭載している)ウイルスというのはいくらでもありえます。手口も進歩しており、現存の正規ソフトに不正処理を加えるようなウイルス作成ツールも実在します。
ソフトウェアに限らず例えばキーボードにロガーが仕込まれていたり、偽サイトを作って正規サイトとデータ通信を中継ぎながら入力パスワードを盗み取るというような事例もよくあります。
投稿2017/12/09 15:18
総合スコア4830
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
あるエラーに引っかかっている際にこうすればうまくいくかもしれないという曖昧な方法でそのエラーを対処することに成功した場合
ユーザーが最も恐怖を感じることのひとつは、作り手が理解できていないものを使わされていた事実を知ったとき
・・・と、私は思います
「わからないですけど、うまくいってるし、何か問題ありますか?」なんて言われたら二度と発注しません
何らかの緊急性をともなう事態に直面している(人命にかかわる、大きな損失を出してしまう、etc)のであれば一時的にそれで走らせることがあるかもしれませんが、「後で何もしない」というのは考えられません
たとえ自分で利用するツールレベルの話しだとしても、隠れている真の問題にまたぶつかることもあるでしょうから、放っておいてよいことはなさそうです
投稿2017/12/12 08:27
総合スコア3111
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
説明できないコードは一行たりとも書いてはならない。
困るのはコードを読む/メンテする誰かであり、それは多くの場合自分自身である。
投稿2017/12/10 03:38
編集2017/12/13 06:21総合スコア16614
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
こうすればうまくいくかもしれないという曖昧な方法
程度によるんじゃないですかね。
曖昧だった方法論が実証によって検証されたのであれば、それは放置で良いと思います。プログラミングなんて、突き詰めれば突き詰めるほど、ブラックボックスの存在に気が付かされるわけで^^;
ただ、その場合、安心できるまで検証することが必要かと。
漏れのないテストを実施することで、安心したいです!w
投稿2017/12/10 06:20
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。