作成されたすべてのダーティフィックスは同じですか？
私は私の時代にいくつかの汚いコードを見てきました。 「ダーティフィックス」についてもさまざまなフィードバックを聞いています。
a）汚れた「修正」は修正ではありません
b）一部の修正は他の修正よりも汚れていますが、汚れた修正は受け入れられません
c）一部の修正は他の修正よりも汚れており、一部の汚れの修正は他の修正よりも受け入れられます
d）ダーティな修正は、実際的な使用方法を示していますが、推奨されません。
e）ダーティフィックスは、実際的な使用法を示しており、落胆すべきではありません。
f）その他
上記のどれに同意しますか、そしてその理由は何ですか？ （e）のような態度が標準的な慣行になるのをどのように止めますか？
「汚い」修正は 技術的負債 の形式であり、それを買う余裕があるかどうかは、最終的には費用便益分析にかかっています。
（ ライトニングトーク（p3）ACCU会議 で）次のこととまったく同じではないことを言ったかもしれないOlve Maudelに謝罪し、比較してください：
- バグを適切に修正するための即時コスト+バグを時間内に修正しないための即時コスト
vs.
- ダーティフィックスの当面のコスト+ダーティフィックスの継続的な長期コスト
それを適切に修正する場合、段階的な支払いが必要な期限を逃したこと、または競合他社があなたの前に市場に参入することを意味する場合、そのコストは非常に高くなる可能性があり、代わりに技術的負債を負担する価値があった可能性があります。ただし、借金を返済しない期間が長ければ長いほど、コードのサポートと新機能の追加にかかるコストの観点から、より多くの利息が発生することを忘れないでください。 。状況によっては、ダーティフィックスが実用的な解決策になる場合があります。
ただし、怠惰の言い訳としてbeingpragmaticを使用し、技術的負債を積み上げ続ける場合は、リファクタリングによって以前の負債を返済しないように注意してください。借金が非常に高くなるため、破産だけが残っている実用的 -）オプション。 * 8 '）
確かにダーティな「修正」は修正ではありません（a）。製品に問題がある場合、クリーンな修正は、この問題を修正して次のことができるようにすることを目的としています。
- 製品の関連部分を再利用し、既知の問題がないことを確認してください。
- バグを解決するために、後でコードを変更するために戻る必要はありません。
汚い修正で、開発者は：
- 期待どおりに動作するかどうかわからないため、該当する部分を再利用できません。
- コードを正しく書き直すには、後で戻る必要があります。
したがって、何かを修正するためにより多くの時間を費やす代わりに、ダーティ修正はすぐに費やす時間を減らすために使用されますが、最近は戻ってクリーンな修正を強制し、その間にコードを再利用することを禁止することによってより多くの時間を費やします。
もちろん、これはすべてのダーティフィックスに当てはまるわけではなく、ダーティフィックスと呼ばれるものにも依存します。例：
ユーザーは、入力が39.5に等しい場合、プログラムが誤った結果を与えるというレポートを送信します。ばかげて汚いDailyWTF候補の修正は次のようになります。
if (input == 39.5)
{
// 14.7 is a correct result, calculated by hand.
output = 14.7;
}
else
{
// Keep the old and broken algorithm.
// ...
}
数日または数週間以内に、別の顧客からの別のレポートで、他の入力値に対しても出力が正しくないことが示される可能性があります。
汚れの少ない修正は、アルゴリズムをチェックし、どこで壊れているかを確認し、単体テストを修正せずに修正することです。それが再び壊れるのを見る可能性は小さいですが、それは起こる可能性があり、ユニットテストを追加したり、コメントを追加したり、スタイルガイドラインを適用したり、ドキュメントを書いたりするために後で戻る必要があります。
そうです、一部の修正は他の修正よりも汚れています（b、c）。 一部は他よりも受け入れられるが会社のガイドライン次第である場合。
ダーティフィックスは1の時間の実用的な使用を示しています（d、e）。正確な瞬間に。数分を費やすことが少なくなるため、最近は自分の時間を無駄にすることになります（または、同僚が後で修正のクリーニングに時間を費やすことになります）。そのため、ダーティフィックス推奨されません特にチームで。開発者が多くの汚い修正を行ってから会社を辞めた場合、チームの他の人々は修正をきれいにするのに苦労するでしょう。
「汚い修正は、実際的な使用法を示しており、落胆すべきではない」などの態度が標準的な慣行になるのをどのように止めるのでしょうか。
ベストプラクティスを実施するだけでなく、チーム/会社の開発者が自分たちが何であるかについて十分にコミュニケーションすることを保証することによってやっています。管理者からのプレッシャーとストレスが多すぎると、開発者はすぐに終了するためだけに、よりダーティな修正を使用する必要があります。これは、チームマネージャーが十分な経験を積んでいない場合や、コードの品質を気にしない場合に特に当てはまります。
一般に、ハッキング/ダーティフィックスは回避して拒否する必要があります。ただし、例外があります。
- フレームワーク/言語が制限されすぎて、プロジェクトを大規模に再構築せずに適切に実行できない場合。
- フレームワーク/言語に回避する必要のあるバグがある場合
- コアの問題を実際にきれいに修正するための予測可能な方法がない場合（＃1に関連）
＃3の場合：たとえば、ASP.Netの曲がったページのライフサイクルを回避するために非常に奇妙なことをいくつか行いました。すべてのイベントがどのように呼び出され、コードが機能しなかったのかを正確に理解しました。そのため、イベントが通常呼び出されるよりもページのライフサイクルの早い段階でForm配列を自分でチェックすることにより、__Click_メソッドを手動で呼び出すことになりました。
＃1の場合：SQLクエリを手動で作成していたので、最終的には次のようになりました。
_query="select * from table where";
if(Option1){
query+=" option1='"+Option1String+"' ";
}
if(Option2){
query+=" option2='"+Option2String+"' ";
}
if(Option3){
query+=" option3='"+Option3String+"' ";
}
_そのため、どのオプションも選択されていない場合、構文エラーが発生することになりました。私の他のオプションは、オプションが追加されたときのメンテナンスの悪夢であると私が考えたif(Option1 | Option2 | Option3)を絶えず構築することでした。だから私は1つの変更でそれを修正しました：
_query="select * from table where 1=1";
__1=1_がそこに置かれた理由がすぐにはわからないので、これは汚い/ハックだと思います。もちろん、私はそれを説明することから地獄をコメントしました。しかし、それはまだハックです。ただし、代替の「適切な」方法を維持するのは困難でした。
「ダーティ」修正は修正です。そうでなければ、それは休憩ではないでしょうか？
「ダーティ」フィックスが受け入れられないのか、それとも落胆するのかという問題は、「ダーティ」フィックスと「クリーン」フィックスの間に明確な違いがあることを前提としていると思いますが、そうではないと思います。 「クリーン」だと思った修正を適用しましたが、最終的には次の修正と比較して「ダーティ」であることが判明しました。 （あまり頻繁ではありませんが、最終的にはかなり「クリーン」であることが証明された「ダーティ」だと思った修正を適用しました）。 「ダーティ」フィックスと「ダーティ」フィックスを区別する方が価値があると思います。前者の方が望ましいですが、それ以外はすべて同じです。
「ダーティ」と「ダーティエ」の両方の修正で当面の問題は解決するはずですが、「ダーティ」の修正と比較すると、「ダーティ」の修正により将来のエラーの可能性が減り、エラーが発生した場合は必要な労力が減ります。そのエラーを解決します。次の開発者がエラーをより適切に診断して修正できるように、コードのリファクタリングと同じくらいの時間が必要な場合もあれば、コードの文書化とその実行のログ記録が必要な場合もあります。
開発者が「より汚い」修正を選択するのを思いとどまらせる方法については、やめてください 励まし 開発者は、より高速な修正を明示的に優先し、したがって暗黙的に「より汚い」修正を優先することによって、「より汚い」修正を選択しました。
コンテキストによって異なります。
私は確かに私の時代にいくつかの恐ろしい修正を加えましたが、私が取り組んでいたコードは償還を超えていました-PHPの完全な混乱はどこでも依存関係の大量をコピー/貼り付けしました（バリエーションあり） ）そして私が今まで見た中で最もランダムなデータベースの「デザイン」。もちろん、求人応募をサポートするためにそのコードを喜んで見せることは決してありません！
通常、私はa）を使用します。少なくとも、私が行うことは、理解可能で維持可能でなければなりません。同時に少し改善/リファクタリングできれば、はるかに良いです。
d）とe）は単純に怠惰です...今は30分節約できますが、6か月後に次の更新/修正が必要になるのはいつですか？それは誤った経済です。
質問は主に学術的です。ほとんどの場合、実稼働環境では、実稼働システムで問題が発生したときに「クリーン」なことを行う時間がありません。したがって、問題を解決するための最速のルートを使用して、ダウンタイムを可能な限り制限します。これは、コードの見栄えが良くないという点で「ダーティフィックス」かもしれませんが、ダウンタイムは収益の損失を意味し、見栄えの悪いコードはプログラマーにとってブラウニーポイントの損失を意味するため、はるかに重要な仕事を成し遂げます。エゴ。
それが本当のハックである場合は、おそらく最も早い機会にリファクタリングのためにタグを付けるでしょう（つまり、コードのその部分が次に変更される予定であるとき、それを取り除きたいという理由だけで次のリリースではありません）、しかし、物事をうまくやる時間がないので、今はうまくいくでしょう。
これが締め切りの世界であり、宿題ではなく実際の要件に対応しています。
私はd）とc）の適量でf）に傾いています。
コードの次のバージョンが活発に開発されている場合は、ダーティ（クイック）修正が本番ブランチでの適切なアクションである可能性があります。修正は可能な限りクリーンである必要があり、DailyWTF候補として適格であってはなりません。クリーンな修正で実際よりも多くの作業が必要になる場合は、本番ブランチを修正できる可能性があります。
ダーティフィックスを使用する場合は、開発ブランチにマージしないでください。いくつかの例外（機能の削除）を除いて、すべての本番修正を開発ストリームに適用する必要があります。クリーンな修正を適用できる場合は、それを開発ストリームにマージするのが適切です。そうでない場合は、修正を開発ストリームできれいにやり直す必要があります。
一般的に、「修正」または「ハック」は悪いことです。そして学校では、修正を行わない方法を学びます。しかし、実際には、時間が重要な場合、修正はコード内の一定のIDのように行われ、コードを十分に一般的にすることはできません。プロジェクトの全員が何をしているのかについて同意している限り、大丈夫だと思います。リスクは、コードが後で修正されるように変更されないことです。リスクは、修正が長く続くほど修正が難しくなる迷路のようなコードを構築していることです。また、修正を変更する時間は、ソリューションにとどまることができる時間が長くなるほど対数が増加します。
したがって、可能であればc）とd）に同意します。つまり、修正を行う必要がある場合は、コメントを付けて、修正を修正する次のプログラマーがコードを十分に単純化できるようにします。次に、現在の状況を最大限に活用しました。
私の見解では、決してダーティフィックスの正当な理由があり、より大きな問題を示唆する言い訳にすぎません。その問題は修正できないものである場合があります（たとえば、マネジメントバイインがない、使用しているフレームワーク/言語の問題）が、それでも他の何かを隠すための言い訳になります。
当然のことながら、私は可能な限り「汚い」方法で物事を行うことを避けようとします。私の経験では、それを適切に修正して技術的負債を「返済」することは決してできないからです。