4

今日、私はクライアントのために何かに取り組んでいたときに、プログラムの一部の機能を壊す方法を見つけました。

(コードは実際にはレガシー コードです。約 10 年間開発されており、私はここで約 1 年しか働いていません。)

エラーが発生したり、プログラムがクラッシュしたりすることはありませんでしたが、ユーザーがプログラムを使用して動作を複製した場合、彼らは「WTF?」を保持していると確信しています。国旗。

私たちのプログラムでは、フィールド (テキストボックス) とテキストボックスにリンクできる静的テキスト (ラベル) に名前を付けました。テキストボックスが埋められていない場合、それらにリンクされていたラベルは消えます。

私が壊れた機能は、既に 1 つ以上のラベルがリンクされているテキスト ボックスの名前を変更し、テキスト ボックスに関連付けられている 1 つ以上のラベルを再関連付けせずにファイルを保存すると、以前に関連付けられていたラベルテキストボックスが空白の場合に表示されます。

この問題に関する私の考えでは、最初は単純なオブザーバー パターンでこの問題を解決できたはずですが、コードを書いていませんでした。

このような状況を店の人たちともっと掘り下げることができれば、ユニットテスト、デカップリング、必要なパターンの適用などを検討するように彼らに相談できるのではないかと考えていました.

このため、あらゆる種類のアプリ (Web ベース、デスクトップなど) で壊れた (ただしエラーの原因ではない) 機能を見つけるためのヒントが誰かにあるのではないかと考えていました。

4

10 に答える 10

7

アプリがユーザビリティに失敗するには、期待される動作のセットが定義されている必要があります。

「このテキストボックスは、Enterキーが押されても何もしないようになっていますか？」多分そうです、多分そうではありません。テスター/レビュアーが、別の方法で動作するはずだと想定していることを報告するアプリを見たことがありますが、実際には、クライアントは、リターンキーを押してフォームを送信したくないが、送信ボタンをクリックするだけでフォームを送信するように要求しました。

したがって、基本的には、誤った動作を判別する前に、適切な動作を定義する必要があります。

于 2009-12-18T22:16:50.507 に答える
3

テスターを雇う。

于 2009-12-18T22:12:10.770 に答える
2

コード検査、つまりソースコードの読み取り：ソースコードの読み取り/検査に時間をかけたり、「におい」を探したり、動作がすぐには理解できず同意できないコードを探したりした場合は、あなたの「WTF？」フラグも。

于 2009-12-18T22:25:39.813 に答える
2

インターフェースがある場合、私のお気に入りの型破りなテストの1つは、5〜10歳の子供をその前に置くことです。彼らが思いつくことができるもの（特に若いもの）に驚かれることでしょう。これは冗談のように聞こえるかもしれませんが、そうではありません。子供たちは「考え方」の道をたどるだけの考え方を持っていないため、実際に機能します。

そして、ええ、子供たちは「物事を壊す」xPの専門家です。

于 2009-12-18T22:17:57.653 に答える
1

データベース接続/セッションが次の方法で解放されていないことがわかります。

  • 何かをするために必要な接続の最小数を計算する
  • リソース制限をその最小数に設定する
  • 正確にその数を使用する必要があるシナリオの1つの「実行」を保証します（そして後でそれを解放します）
  • その後、もう一度実行します...接続が不足していませんか？

私は、プログラマーがデータベース接続の割り当てを解除するのを忘れていた会社で働いていました。標準的な答えは、リソースを最小限に抑えてリークがあるかどうかを確認し、システムを再起動してさまざまなシナリオを繰り返し実行することで、リークがどこにあるかを突き止めることでした。

于 2009-12-18T22:30:17.257 に答える
1

最初のレビュアーによるコード レビューの最初の 1 時間は、品質の問題を見つけるのに最も役立ちます。しかし、問題は次のとおりです。品質の問題を人々に納得させる必要はありません。バグを修正することの価値と、現在の品質が完全に正当化される場合にのみ書き直すことの価値を彼らに納得させる必要があります。

私は私の時代にいくつかの深刻な悪いコードを扱ってきました。しかし、ただ書き直すことはできません。書き直しが改善であるかどうかを判断する前に、仕様が必要です。

場合によっては、コードから仕様を推測し、それをどこかで人間と照合する必要があります。しかし、それが完了する頃には、コードが書かれたとおりに理解されており、ほとんどの場合、書き直すよりも修正する準備が整っています。

修復は、コード内の仕様をより明確にする、動作を維持する小さな変更のプロセスによって進められます。そして、見た目がおかしいと感じたら、ただ変更するだけではありません。その決定の責任者が見つかるまで周りを尋ね、仕様のどこで動作 X が正しいと述べているかを彼らに教えてもらいます。(この会話にはさまざまな形があります。) 運が良ければ、行動 X が実際には正しくないことを伝えられ、報酬を得ることができます。

于 2010-08-15T15:13:43.957 に答える
1

テスト、テスト、テスト。

予想外のことをする。1 つのタスクを開始し、別のタスクに切り替えて、問題が発生するかどうかを確認します。不要な場合は戻るボタンを使用してください。2 つのウィンドウで開きます。タイムアウトさせます。

すべてのブラウザー、特に IE でテストします。

于 2009-12-18T22:16:37.243 に答える
0

コードレビューには、常に単体テストコードのレビューも含める必要があります。

問題は、アドホックテストでは、開発者がコードをどれだけ、またはどれだけうまくテストしたかを知ることができないことです。ですから、あなたは「完了」という言葉のさまざまな開発者の定義に翻弄されています。

単体テストコードのレビューを同時に本番コードのレビューに含める場合は、コードが本当に完全であるかどうかをよく理解する必要があります。その「完了」には「テスト済み」が含まれます。「ねえ、壁を越えてテスターに​​投げるぞ！ 」だけではありません。

于 2009-12-31T01:11:11.237 に答える
0

これは Visual Studio IDE に固有のものですが、おそらく他のものにも当てはまります。

テスト中は常に、ある時点で「例外がスローされたときに中断する」をオンにしてデバッガーで実行します。

これは、誤ってサイレントにキャッチされ、バグを表す例外を明らかにするのに役立つことがよくありますが、それ以外の場合は明らかではない場合があります。

于 2009-12-31T01:06:59.390 に答える
0

assert() カバレッジ分析による単体テストも。

于 2009-12-18T22:09:06.963 に答える