3

言い換えれば、エラーを予測してこれらの潜在的な問題を回避するためにコードを書くことに時間を費やしますか?それとも、適切と思われるコードを記述してから、問題ごとにエラーを処理しますか?

私は最近これについてよく考えていて、私は非常に反応的な人です. 私は自分のコードを書き、それを試してみて、正しいエラーに戻り、アプリケーションが期待どおりに動作するまで繰り返します. しかし、私の友人は、各行がどのように解釈されるかを時間をかけて考え、エラーが発生する前に修正することを提案しました。

リアクティブは純粋なプリライブであることを指摘しなければなりません。アプリケーションが稼働する前に、アプリケーションが機能することを確実に確認します。

4

7 に答える 7

4

常にバランスが取れている必要があります。

エラー チェックが多すぎると処理が遅くなり、ガベージ コードが生成されます。エラーチェックが十分でないと、出荷後に発見するのにあまり適していないエッジケースでプログラムがクラッシュします。

したがって、コードの一部の信頼性を決定し、それに応じてエラー チェックを実装します。一部のテスト ユーティリティは信頼性が低く、エラー チェックが少ない場合があります。サード パーティの検索サービスが深いバックグラウンドで使用することを意図した COM サーバーは、非常に信頼性が高く、エラー チェックがはるかに多い必要があります。

于 2010-09-03T14:56:50.447 に答える
0

エラー処理を考えるとき、私は単純な原則に従います: ガベージ イン、ガベージ アウト。ガベージ (無効な入力など) がソフトウェアを台無しにしたくない場合は、ソフトウェア内でガベージが侵入して処理できるすべてのポイントを見つける必要があります。もちろん、ソフトウェアが複雑になればなるほど、すべてのエントリ ポイントを見つけるのが難しくなりますが、前もってやればやるほど、後で反応しなくても済むようになると思います。

于 2010-09-03T15:06:25.357 に答える
0

私は積極的なアプローチを提唱します。

  • 私はそのスタイルでコードを書こうとします。これにより、保守可能で信頼性の高いコードになります
  • 私は防御的プログラミング手法を使用して、注意力の喪失などによるコードの愚かなエラーを防ぎます
  • 要塞の原則に従ってデータベースモデルを設計し、各単一操作の後に結果をチェックするSQLコード
  • コードのその部分で起こりうる潜在的な問題を考え、それを説明します。すべての可能性ではありませんが、今思いつく主な可能性についてです。

これにより、通常、ソフトウェアはかなりスムーズに動作します。時には驚かされることもありますが、それが意図された目標だったので、ここにいます。

于 2010-09-03T15:16:27.297 に答える
0

IMHO、「エラー」という言葉(またはその同義語「バグ」)自体は、それが予見されなかったプログラムの動作であることを意味します。

私は通常、考えられるすべてのシナリオを念頭に置いて設計しようとします。もちろん、考えられるすべてのケースを考えることは通常不可能です。しかし、できるだけ早く何かを機能させるよりも、よく考えてできるだけ多くのシナリオを考慮に入れる方がよいでしょう。これにより、デバッグやコードの再設計にかかる時間と労力を大幅に節約できます。実際にエディターにコードを入力する前に、どんな小さなプログラミング タスクであっても、ペンと紙を持って座っていることがよくあります。

私が言ったように、これはすべてのエラーを排除するわけではありません。私にとっては、デバッグに費やす時間の点で何倍も報われます。もう 1 つの利点は、バグ修正のハックや後で追加される特別なケースが少なく、より堅牢で保守しやすい設計になることです。ただし、いずれにせよ、コードが完成した後、多くのデバッグを行う必要があります。

これは、モックアップやラピッド プロトタイプだけが必要な場合には当てはまりません。また、締め切りなどの実際的な制約により、完全な評価が困難または不可能になることがよくあります。

于 2010-09-03T15:27:39.170 に答える
0

これを単独で尋ねるのはちょっと奇妙で、非常に主観的だと思いますが、それぞれを行うためのテクニックがたくさんあることは明らかです。私はこれらの2つを使用する傾向があります:

  • テスト駆動型開発 (これはプロアクティブなようです)
  • 強力な静的型付け (リアクティブですが、タイトな反復開発サイクルの一部であり、ML コンパイラによって強制され、多くのコンパイルを行います)

ごくたまに、プログラムの正式な検証の世界に足を踏み入れることがあります。それは間違いなく「反応的」ですが、もう少し前向きに考えると、検証が容易になる傾向があります。

また、私はプログラミングにおいて多くの事前の考えを大切にしていると言わなければなりません。バグを回避する最も簡単な方法は、最初からバグを書かないことです。避けられない場合もありますが、多くの場合、問題について考えることにもう少し時間を費やすことで、より質の高い解決策につながる可能性があり、残りは上記で説明した種類の自動化された方法を使用して処理できます。

于 2010-09-03T14:58:36.767 に答える
0

私は通常、コーディングの際に、次のような一連の what-if を自問します。

  • ユーザーがボタンをクリックしたときに、日付を選択しなかった場合はどうなるでしょうか?
  • ユーザーが検索ボックスに入力しているときに、そこに html を入力しようとするとどうなるでしょうか?
  • ラベル テキストが共有ドライブの値に依存していますが、マップされていない場合はどうなりますか?

等々。これを行うことで、アプリケーションが実際に稼働したときに、エラーが大幅に減り、最初からあるべき状態を修正するのではなく、よりあいまいなバグの修正に集中できることがわかりました。

于 2010-09-03T15:02:14.723 に答える
0

どんなプログラミング?これについては、一般論でお答えすることはできません。(「遊ぶときにヘルメットを着用しますか?」と尋ねるようなものです-つまり、をしますか?)

職場では、データベースに裏打ちされた Web サイトに取り組んでいます。要件は厳しく、ユーザーがどのようにそれを台無しにするかを予想していない場合は、1 日の奇妙な時間帯に電話を受けて修正する予定です。

自宅でプログラムを作成していますが、それが何をするのかはまだわかりません。「エラー」に対処できないのは、このコンテキストで「エラー」が何であるかがわからないためです。正しい動作がどうなるかがわからないためです。プログラムの全体的な目的は、数分から数時間のタイムスケールで変化する可能性があり、頻繁に変化するため、エラーについて考えるのに数分を費やすだけでも、完全に時間の無駄になります。(エラー処理によってコード行が追加されるため、SO をブラウジングするよりもさらに悪いことです。)

唯一の一般的な答えは、「長期的に時間を節約するという点で理にかなっていることをする」ということだと思います.

于 2010-09-03T15:31:16.673 に答える