他の作業中に既存の欠陥を修正する必要がありますか？

難問：新機能の作業中または欠陥の修正中に、コードに古い問題が見つかります。あなたは何をするべきか？それを修正し、コードの動作を変更する危険を冒してください。それは、これまでに何らかの欠陥によってうまく機能しているか、あるいは欠陥が検出されていないか、報告する時間がないかのどちらかです。そのままにして、問題が原因でコードを後で操作しにくくする必要がありますか？問題を修正すると、元のタスクの時間が増えるだけで、強制的に回帰テストが行​​われます。仕事に感謝する人はほとんどいません。しかし、それを修正することは、どういうわけか正しいようです。問題の少ないコードは、リファクタリングやビルドが簡単です。

Webアプリケーションの近代化に取り組んでいるとき、私はこの状況に何度も気づきました。これらの古いバグに取り組んでいるとき、自分が強迫観念を持っているのか、それとも名誉あるのかはわかりません。これらの状況をどのように処理しますか？

ありがとう、コーリー

私は非常に小さなチームで働いているので、変更内容に依存します。

その小さな、明らかなバグ修正であれば、私は間違いなくそれに行きます。また、他の誰かのコードや、「ボーイスカウトのルール」に該当するその他の小さな改善に取り組む必要がある場合は、余分なコメントを入れます。

コードが非常に絡み合っているため、「これを変更すると何かが壊れてテストが必要になる」と尋ねる必要がある場合は、変更しないでください。心配な場合は、バグ追跡システムに表示してください。

これは、偶然にも、より明確な型シグネチャを使用して小さなメソッドをコーディングしようとする理由です。副作用がないことがわかっていて、インとアウトを一致させることができる場合は、リスクなしでインテリアコードを修正、再配置、または調整できます。

しかし、感謝の欠如が、見つけたバグを修正したり、何らかの理由でコードベースを改善したりするわけではないと感じないでください。他に何もないとしても、あなたはきっと他の何かを修正するためにそこに戻ってくるであろう未来に親切です。

編集：プロジェクトの時間を監視する必要もあります。明らかに厳しい締め切りの下では、主な作業を完了することに集中する必要がありますが、「通常の負荷」がかかっている場合は、ここを少し整理することで長期的に誰もが幸せになると思います。

いつものように、それは依存します。

• 些細なことで、修正できると確信している場合は、修正してください。
• ユニットテストがたくさんあるので、何も壊していないことをかなり確信で​​きるなら、それを修正してください。
• それ以外の場合は、// TODOを追加し、バグ追跡に追加します

基本的に、リスク評価を行っています：変化するリスクと変化しないリスクは何ですか。（一般的なプログラミング、または特にシステムに関する）十分な経験があると思わない場合は、チームの他の誰かに尋ねてください。

実用的なプログラマーはこれらを「壊れたウィンドウ」と呼びます。

壊れたウィンドウを修正しなければ、コード品質の低下スパイラルを作成する傾向があります。そして、それらが多ければ多いほど、それらを修正する仕事が大きくなるため、修正される可能性は低くなります。

今すぐ修正するか、後で修正するかは、判断次第です。簡単な修正ですか？コードはあなたが思っていることをしていると確信していますか？現在のタスクから気をそらす可能性はありますか？時間の制約はありますか？バグが増える可能性はありますか？

少なくとも、追跡システムでアイテムをマークし、後で修正されることを確認してください。今すぐ修正することを決めた場合でも、追跡システムにマークを付け、同様にテストされていることを確認し、変更を文書化することが重要です。

セキュリティに違反したり、データを破損したり、ユーザーに表示される例外を発生させたりするような明らかなバグの場合は、修正します。それ以外の場合は、あなたよりもコードベースをよく知っている人に尋ねてください。

修正の影響が少ないと確信できる小さなバグであれば、個人的には他の作業の一部として修正してからPMに知らせます。

それが持っている場合は任意のクライアントへのリスクを、ユーザーや企業がプロジェクトマネージャでそれを持参し、前方のコースを議論します。リスクを評価するのが彼らの仕事なので、彼らの注意とそれを修正するためのケースにそれを持ち込んでください。その後、彼らの決定を尊重します。

テスターはこれを嫌います。非常に些細なことでない限り、バグデータベースに記録し、リリースに割り当てて回帰テストを作成します。開発者が予定通りではない変更を加えようとしている場合、どうすれば期限を守ることができますか？

私は、重大ではない欠陥または標準違反が「弱いコード」欠陥として提出されるチームに参加しました。重大な欠陥を見つけた人には、何らかの旗を投げる責任があると思います

それはバグに依存します。主な懸念は、新しいバグの導入です。未知の問題よりも既知の問題に対処した方が良い。その単純な、テキストの変更、または単純な論理エラーの場合、修正します。それ以外の場合はそのままにします。

注意すべきことは、トー、私たちは4人の開発者とインターンの小さな店であり、私が修正するバグはおそらく私が作成したバグでしょう。

コードが明らかに間違っている場合、修正は非常に簡単であり、ユーザーに影響を与えるリスクは低いと考えているので、先に進みます。それは専門的な判断にかかっています。

ただし、それを見つけた場合、おそらくユーザーはそれを見つけていないか、そうでなければ報告していたことを覚えておく必要があります。ユーザーが遭遇することのない問題の修正に時間を費やすのではなく、ユーザーの問題を引き起こしている問題の修正にその時間を費やす方がよい場合があります。

まず観察結果を文書化し、後で修正するかどうかを決定します。

同僚との正式な議論（例：定例会議）や非公式な議論（例：昼食時）を行い、修正しようとしているコードの動作に自信が持てたら変更を加えます。

あなたにはバグ/欠陥のように見えますが、今回は実際には「機能」かもしれません。以前のリリースの最後の最後のいくつかのコーナーケースを回避するための実装が不十分なソリューションである可能性があり、「クリーンフィックス」により、以前に解決された問題が復活する場合があります。

ここでトレンドに逆らいます。開発の非常に初期のプロトタイプフェーズにない限り、すぐに修正しないでください。バグレポートを提出する必要があります。これにはいくつかの利点があります。

• チームはそれを評価します。それは本当のバグですか、それを修正するリスクは何ですか？
• 管理者は、このリリースにスケジュールの影響を与えるのに十分な重要性があるかどうかを判断できます。
• それを検出するためのメソッドをテストスイートに追加することができます。同様のエラーを見つけるのに十分な方法でうまくいけばいいのです。
• 前のフェーズをすり抜けているバグの数に関する貴重な指標を提供します