壊れたウィンドウを修正しないことはいつ受け入れられますか？

壊れたウィンドウを参照して、将来のアクティビティのためにリファクタリングを残すのが最適な場合はありますか？

たとえば、既存の内部システムにいくつかの新機能を追加するプロジェクトが、これまでシステムで動作していなかったチームに割り当てられ、動作するための短いタイムラインが与えられた場合、それを正当化することができますか？このシナリオで期限を設定するために、主要なリファクタリングを既存のコードに延期しますか？

リファクタリングは継続的なプロセスであり、そうあるべきです。まだ少し不完全な作業済みでテスト済みの実装で要件を満たすだけでは不十分です。

「動作させてから、動作を改善する」。

私はその引用をどこで読んだか思い出せませんが、これはリファクタリングをうまく適用するための鍵であり、そうでない場合は専門家ではないと見なします。

継続的なリファクタリングは、料理中にこぼれたものを拭き取り、食事を食べた後に皿を掃除するようなものです。ターゲットを絞ったリファクタリングは、汚れたキッチンを見つけるようなものですが、汚れたガラスを1つか2つ洗う時間しかありません。常に汚れたキッチンと一緒に暮らしたいですか、それとも物事を清潔に保ちたいですか？

コードを機能させてから、コードをリファクタリングして、使用可能な最高の実装を確保します。おなじみのことをしている場合は、最初に最適なコードを実装することもできますが、作業を確認するために少し時間がかかります。コードを改善できるかのように見える場合は、リファクタリングして、コードができる限り無駄のないクリーンなものであることを確認してください。これは、残した技術的負債の量を減らし、コードを次に処理する必要があるときに読みやすく、リファクタリングしやすくすることを意味します。これはTDDマントラ「Red-Green-Refactor」の背後にある中心的な価値です。ただし、TDDで主に重複を除去するためにリファクタリングする場合、リファクタリングできる他のアイテム（大規模なクラス、長いメソッド、

大幅な再設計に直面している場合、特にスケジュールが非常に遅れている場合は、しばらく延期することができます。ただし、これは、コードの機能が損なわれないこと、および実装が要件を満たし続けることを条件に提供されます。この種の状況はまれにしか発生しないはずであり、進行中に継続的にリファクタリングしている場合は、さらにまれであることを確認するのに役立ちます。ただし、さらに重要なのは、大きな変更をあまりにも長く残さないようにすることです。プロジェクトの失敗。

多くの人がリファクタリングとリエンジニアリングの定義を混同する傾向があるという印象を受けます。2つの用語は、非常に異なる状況を管理する戦略を説明しています。再設計する場合は、システムの動作を変更する大幅な変更を行うことにコミットしています。これにより一部のテストが無効になり、新しいテストも必要になります。リファクタリングすると、システムが正確に動作し続けることが保証されます。変更前と同じですが、コードの寿命が長くなり、長期にわたる保守が容易になることも保証されます。あなたはコードを地獄のように「ポン引き」しているのではなく、失敗のリスクを軽減し、あなたのコードが仕事をする喜びとプロの標準のままであることを保証するクリーンなコードのプロの標準にコミットしています。

壊れたウィンドウの類推に戻って、ウィンドウを壊した場合、すぐに修復する必要があります。ウィンドウが壊れていることに気付いていない場合は、ウィンドウが壊れたままにした場合のコストを決定する必要があります。ここで、前の2つの文を繰り返しますが、ウィンドウをバグに置き換えます。最終的に別の戦略が必要になります。コーディング中にバグを作成した場合は、すぐに修正するか、変更にリエンジニアリングの努力が必要かどうかを確認し、問題をいつ解決するのが最適かを商業的に決定します。したがって、問題を修正するためにリファクタリングするのではなく、問題を見つけて修正しやすくするためにリファクタリングします。コードがどれほど素晴らしいと思うかは気にしませんが、複雑なシステムには常に問題があり、時間の経過とともに対処する必要があります。これが技術的な負債のすべてであり、コードを実装するときにリファクタリングを継続的なプロセスにする必要があり、将来の任意の時間に残さない理由です。

要するに、デッドラインを作るためにコードの大きな変更を延期することはまれに受け入れられるかもしれないという答えですが、リファクタリングを毎日の実装作業とは独立した演習として扱うことは通常の慣行とは見なされませんコードベースに不慣れなチームが、状況に応じて可能な限り無駄のないクリーンな実装を保証することを避けるためのオプションとして、チームが言い訳として使用することはありません。

一部の開発者は、実際に「タイタニック号のデッキチェアを再配置している」とき、「壊れた窓を修正する」と言います。動作するが、嗅覚を害するコードのリファクタリングは比較的簡単です。ユーザーに新しい機能を追加したり、アプリを使いやすくしたりする代わりに、この種のタスクに戻ってくることがわかった場合（最適化とは、アプリの実行を高速化することを意味しますが、最適化とはコードを読みやすくすることです）異なる）その後、おそらくあなたが片付けすぎています。片付けが悪いからではなく、会社が何かを開発するために開発にお金を払っているからです。彼らは、もろくて読みにくく、よく設計されていないソリューションを望んでいませんが、洗練された美しいハーフソリューションも望んでいません。

「何かを始める」ために簡単なことをする必要があるとき、または問題が実際に彼らのせいであるかどうかを他のチームに知らせるのを待っているとき、または決定を待っているときに整理します。たくさんの機会があります。アプリ全体を前進させる機会がある場合は、全体がもろくなっていると感じ始めていない限り、それを利用してください。おそらくないでしょう。リファクタリングする機会が得られます-それについて心配する必要はありません。

短いタイムラインに直面している機能を追加するためのスプリントである質問の後半に戻ると、「リファクタリングを行わないので、時間がない」と言うのは誤りです。「6週間が経ち、ユーザーにとってはまったく同じように見えますが、これらの壊れたウィンドウは本当に修正する必要がありました」と言うのも間違っています。プロジェクトで発生するギャップにリファクタリングを適合させます。プロジェクトの目標を達成することを犠牲にして片付けに避難しないでください。

ビジネスの観点から見ると、リファクタリングは投機的な投資であり、将来の時間と労力（お金）をさらに節約することを期待して、現在時間と労力（お金）を投資しています。

リファクタリングの労力が将来的にどれだけ節約するかについて議論することなく（これはあまりにも多くの変数に依存するので、ここでの卑劣な議論にはなりません）、リファクタリングの時期は「ネット現在価値」残された費用は、現在の費用を上回ります。

それは簡単です。ただし、家具の価格がわからない場合を除きます。また、投資収益率、リスク管理（ブランドの価値、法的責任、保険可能リスクと非保険リスク）、運用コストなど、通常のすべての財務計画のアイデアを考慮する必要があります。

ほとんどの場合、リファクタリングのタイミングを決定するのは、ビジネスを運営する人に任せるのが最善です。このフォーラムでは多くのポスターが表明していますが、マネージャーは通常、プログラマーよりもビジネスを運営することについてより多くのことを知っています。彼らは、株主への利益を最大化することを含む、より大きなイメージを念頭に置いています。壊れていないものを修正することがこれに寄与することはまれであり、コードも例外ではありません。

編集：重要なインフラストラクチャの保守スケジュールに関する興味深い記事を読みました。要点は、必要なときに修復するために、定期的なメンテナンス（リファクタリング）から移動する（バグを修正する）ことです。主な違いは監視レベルです。たとえば、原子力発電所は非常に詳細に監視し、「壊れた」が故障のかなり前に修正されます。見つかったのは、maintainceスケジュールを修正すると、コストが高くなるだけでなく、maintainceプログラムによる停止のために信頼性が低下することです。ソフトウェアにも同様のアイデアが必要です-破壊しようとしているビットをリファクタリングします-これは測定によってのみ知ることができます。

それらを修正することによるビジネスへの損害がそれらを修正しないことよりも大きい場合、それは許容できます。

これが発生する状況は次のとおりです。

• 修正に必要な時間のために、期限またはビジネスチャンスを逃す可能性がある場所
• コードが（実際に）非常に短い時間スケールで廃止される予定であるため、リファクタリングするメリットはほとんどありません。

そして、これらの状況は起こります-商業的な状況は、交渉の機会が過ぎた場合に満たされなければならない人為的な期限と、時間の要素を持つ要件-たとえば、施行される法律または税規則の変更をしばしば考案します特定の日付-存在します。

秘Theは、これらの状況を特定し、適切に評価することです。廃止される予定のコードは、しばしば何年も使用され続けます。人工的な締め切りに間に合わせる必要があるかもしれませんが、多くの場合、さまざまな方法で満たすことができます（たとえば、最終リリースバージョンが後日までに完了することなく、特定の日にソフトウェアを提示、デモ、および「起動」できます）。

この種のものが提示されたとき、あなたはオープンマインドでそれにアプローチする必要がありますが、常にそれが何であるか尋ねます 関係する仮定は現実的ですか？標準以下のコードを出荷せずに目標を達成する別の方法はありますか？使用可能な時間を最大限に活用するにはどうすればよいですか？

そして、常に良い代替手段がない場合、これをいつ修正しますか？

それはほとんど、ほとんど、ほとんど常にする必要がありますのでとき、ない場合。

マネージャーが技術的な負債を積み上げたいと決めたなら。これは、例えば、初期のフィードバックを得るために初期の顧客に初期のプロトタイプを提供したい場合に行う公正な決定です。

あなたは信用を求めるのと同じ方法でそれを考えることができます。短期的にXに投資するためにお金を借りて、長期的に支払いますか？決定的な答えはありません。組織の最善の利益になる場合があります（たとえば、現在のクライアントの期待に応えるため）、または無責任に行われた場合は災害になります。

それはすべて優先順位に帰着し、管理者は最も重要なことは「コードを動作させる」こと、新しい機能を実装すること、顧客の期待に応えることであることに注意する必要があります。 、より難しく、より多くのリソース投資が必要です。また、99％の時間、新しい機能の開発を停止し、「コードベースの修正」に全力を注ぐことは不可能です。

結論として、はい、時々ローンを要求するのが許容できるのと同じように、時々壊れた窓を残すことは許容されます...あなたが本当に、本当に本当にそれのために将来支払わなければならないことを思い出してください。そして将来的には、それを行う時間は現在の時間よりもそれほど長くはないでしょう。

通常、できる場合は修正する必要があります。これにより、メンテナンスに費やす可能性のある時間を防ぐことができます。ただし、一部の野barな非アジャイルプラクティスでは、機能している限り現状を維持する傾向があります。一部のマネージャーは、変更の「予期しない影響」を恐れています。

私が取るのは、それが正常に機能している場合（最適化によってのみ破損し、機能は破損していない場合）にそれを残すことです。リファクタリングを行う場合は、テストする時間がありません。ただし、できるだけ早く修正する必要があることに注意してください。

機能によって破損し、新しい機能がそれに依存している場合は、できるだけ早く修正することをお勧めします。

ほとんどのプログラマーは、雇用主のためにお金を稼ぐ仕事をしています。だから、いつリファクタリングが起こるべきか：それがあなたの会社のお金を稼ぐとき。リファクタリングは、他のプロジェクトに費やされない時間であり、このプロジェクトで将来節約される時間です。

価値があるかどうかは、主にマネージャー次第です。

プログラマは、情報に基づいた決定を下せるように、ビジネス側に技術的負債の範囲を知らせる必要があります。より早く市場に参入する必要性がコードのリスクを上回る場合、多くの選択肢はありません。キャッシュフローの欠如は、多くの技術的な決定に勝ります。

問題の一部を非技術的な観点に入れるには、バグを修正し、新しい機能を追加するための延長時間を指摘します。経営陣が販売およびマーケティングのバックグラウンドを持っている場合、彼らはこれを理解するかもしれません。彼らはこれらの事柄に時間がかかることを顧客に伝える必要がないことを嫌います。

チームの拡大を考えているのであれば、今がジュニア開発者を雇う良い機会かもしれません。この場合、テストカバレッジは大きな救世主になります。彼らは、ドキュメントを読むよりも行うことによって多くを学びます。

このシナリオの期限を守るために、既存のコードに主要なリファクタリングを延期することは正当化できるでしょうか？

• 何かが壊れている場合、おそらくそうではありません。部分的に作動するブレーキで車を運転することはありませんか？（時間通りに到着しないリスクが、ブレーキの故障によるクラッシュのリスクよりも大きい場合を除きます。）理想的な解決策とはほど遠いですが、残念ながらそれは起こります。

ただし、作業コードのリファクタリングについて話している場合は、次のことを検討します。

• シニア開発者またはテクニカルディレクター次第であれば、ソフトウェアをリリースすることはありません。私たちは常にリファクタリングを行い、完璧主義を目指します。

• リファクタリングがビジネスの収益性に悪影響を及ぼす場合は、リファクタリングを再スケジュールする必要があります。

• 特定の機能を特定の日付までに提供することをビジネスが約束している場合は、後でリファクタリングします。レッドノーズデイの慈善団体について考えてください。毎年24時間または48時間の寄付を集めることができます。彼らがその時間のギャップで寄付をするのを止めるかもしれないと思ったならば、彼らがコードベースをリファクタリングする方法はありません。さらに、ウィンドウが壊れていても、寄付を受け取る能力に影響しない場合は、リファクタリングを選択しない可能性が高くなります。

• あなたは常に何かをするためのより良い方法を見つけるでしょう。それは自然なプロセスであり、線を引くことができることは非常に重要です。

リファクタリングに関するあなたの質問に答えて、私は「はい」と言います。上記の答えで他の誰かが指摘したように、リファクタリングは継続的なプロセスであり、時には動作しているコードを書き換える必要性に取って代わる戦術的およびビジネス上の決定があります（おそらくklugeyの方法ではありますが）。

「壊れたウィンドウ」について：私は、約10年前にソフトウェア開発のコンテキストでこの用語を初めて聞いた。しかし、当時は、壊れた単体テストを許可することを説明するために使用されていました。これは、破損したユニットテストを修正するのではなく、どのテストが「失敗してもよい」かを覚えておくほうが便利であるため、破損した単体テストを修正しない誘惑があるシナリオを説明していました。変更など）。

壊れたウィンドウのメタファーを壊れたユニットテストに適用することは、より適切であり、ソフトウェアネイバーフッドで「壊れたウィンドウ」を許可する危険性をより説明していると思います。私の意見では、壊れた単体テスト（壊れたウィンドウとして）について話していた場合、答えは決して大丈夫ではないでしょう。（私たちが決して決して言うことができない範囲で...）

本当に壊れている場合は、修正する必要があります。

しかし、本当に壊れていますか？あなたは単に「きれいではない」と壊れているとみなしていないのですか？

スタイルが気に入らない、または将来問題を引き起こすと思われるため、作業コードをリファクタリングする前に、「サンク値」計算を適用する必要があります。

先週書いたコードをリファクタリングするために、あなたは先週それをコーディングするのに費やした時間であり、コードが大幅に改善されるかどうかについて本当に悩む価値はありません。

単体テストを経たコードのリファクタリング。これで、書き直すだけでなく、これまでに行ったすべてのテストを再定義して再実行する必要があります。これは高価に見え始めています。

本番環境に移行したコードのリファクタリング。さらにテストを行う必要があり、さらにユーザーにロールアウトし、古いリリースと同様に機能しないものを提供するリスクがあります。あなたはこれを正当化し、先に進む前に大ボスとそれをクリアする必要があります。

しばらく運用されていて、いくつかのリリースとバグ修正を経たコードの再ファクタリング。ソフトウェアが動作を停止することがわかっている場合を除き、そこにも行かないでください！

締め切りがビジネスにとって最も重要なことであることが私の経験でした。それは本当にあなたのアプリケーションを誰が使用するかによります。私の場合、それは携帯電話のOSソフトウェアのためのものでした...期限を逃したということは、販売目標を逃し、株価のヒットを意味しました。

継承したコードを見て、明らかに変更が必要なWTFの瞬間に出くわしました。ただし、このコードは「ほぼ」機能していたため（非同期性はあまり理解されていません）、管理者が未解決のコミットメントが提供されている間にリファクタリングを実際に許可するインセンティブはありませんでした。バグが「荒野」で見られるようになると、あいまいなエッジケースを簡単に破ることができたとしても、何でも変更できるようになりました。私はかつて自分の時間で約1万行のコードをリファクタリングし、それを捨てなければならなくなりました。テストや他のレビューなどに必要な時間は正当化できませんでした。