壊れたウィンドウを修正しないことはいつ受け入れられますか？
壊れたウィンドウ に関して、リファクタリングが将来の活動のために残されるのが最も良い時がありますか？
たとえば、既存の内部システムにいくつかの新機能を追加するプロジェクトが、これまでシステムで作業していないチームに割り当てられ、作業する短いタイムラインが与えられている場合、次のことを正当化できますか？このシナリオの期限を設けるために、主要なリファクタリングを既存のコードに任せますか？
リファクタリングは継続的なプロセスであり、そうでなければなりません。まだ少し不完全な、機能しテストされた実装で単に要件を満たすだけでは十分ではありません。
「それを機能させて、より良く機能させる」。
その引用をどこで読んだか思い出せませんが、これはリファクタリングを適切に適用するための鍵であり、そうでない場合は専門外と見なします。
継続的なリファクタリングは、調理中にこぼれたものをふき取り、食事を済ませたら皿を掃除するようなものです。ターゲットを絞ったリファクタリングは、汚れたキッチンを見つけるようなものですが、汚れたガラスを洗う時間しかありません。常に汚れたキッチンで暮らしたいですか、それとも、清潔に保ちたいですか？
コードが機能するようになったら、コードをリファクタリングして、使用できる最高の実装が確実に得られるようにします。なじみのあることをしている場合は、最初に最適なコードを実装することもできますが、作業を再確認して少し時間をかけて確認する必要があります。コードを改善できるように見える場合は、リファクタリングを行い、コードができる限り無駄のないクリーンな状態であることを確認してください。これは、あなたが残した技術的負債の量を減らしていることを意味し、次にコードを処理する必要があるときに、読みやすくリファクタリングしやすくします。これは、TDDマントラ「Red-Green-Refactor」の背後にある中心的な価値です。ただし、TDDで主に重複を削除するためにリファクタリングする場合、大きなクラス、長いメソッド、多くの場合、技術的負債に寄与する可能性がある他の「コードのにおい」。
大幅な再設計に直面している場合、特にスケジュールの時間どおりに実行されていない場合は、しばらくそれを延期することができます。ただし、これは、コードの機能が損なわれないこと、および実装が要件を引き続き満たすことを条件として提供されます。このような状況はまれにしか発生しないはずであり、進行中に継続的にリファクタリングを行っている場合は、それがさらにまれであることを確認するのに役立ちます。ただし、さらに重要なのは、大きな変更を長時間残しておくリスクがないことです。そうしないと、後でさらに大きなワークロードが作成され、修正にはるかにコストがかかるか、結果的にさらにコストがかかる可能性があります。プロジェクトの失敗。
多くの人がRefactoringとRe-engineeringの定義を混同する傾向があるという印象を受けます。 2つの用語は、非常に異なる状況を管理するための戦略を説明しています。リエンジニアリングしたい場合は、システムの動作を変更する大幅な変更を行うことを約束します。これにより、一部のテストが無効になり、新しいテストも必要になります。リファクタリングすると、システムが変更前と同じように正確に動作し続けることを確認できますが、コードの寿命が長くなること、および時間の経過とともに維持しやすくなります。あなたはコードの地獄のためにコードを「ピンプ」するのではなく、あなたは失敗のリスクを減らし、あなたのコードが仕事をする喜びであり続け、プロの標準であることを確実にするプロの標準のクリーンなコードにコミットしています。 。
壊れたウィンドウの例に戻ると、ウィンドウを壊した場合はすぐに修復する必要があります。ウィンドウが壊れていることに気付いていない場合は、ウィンドウが壊れたままの場合のコストを決める必要があります。ここで、前の2つの文を繰り返しますが、windowをBugに置き換えます。結局、別の戦略が必要になります。コードの作成中にバグを作成した場合は、すぐに修正するか、変更にリエンジニアリングの労力が必要かどうかを確認し、問題を解決するのに最適なタイミングを商業的に決定します。したがって、問題を修正するためにリファクタリングするのではなく、問題を見つけて修正するのが簡単になるようにリファクタリングします。あなたのコードがあなたのコードがどれほど素晴らしいと思うかは気にしません、複雑なシステムには常に時間の経過とともに対処する必要がある問題があります。これが技術的な負債のすべてであり、なぜリファクタリングを継続的なプロセスにする必要があるのかコードを実装するとき、そして任意の将来に残されない時間。
つまり、期限を設けるためにコードの大幅な変更を延期することはまれに許容できるという回答ですが、リファクタリングを日常の実装作業とは独立した演習として扱うことは、通常のプラクティスとは見なされません。コードベースに不慣れなチームが、状況に応じて実装を可能な限り無駄のないクリーンな状態にすることを回避するオプションとして、言い訳として使用されたことはありません。
一部の開発者は、実際に「タイタニック号でデッキチェアを再配置」しているときに「壊れた窓を修理している」と言っています。機能するが臭いを害するコードのリファクタリングは比較的簡単です。ユーザーに新しい機能を追加したり、アプリをユーザーにとって使いやすくしたりするのではなく、その種のタスクに繰り返しアクセスすることがわかった場合（最適化とは、アプリをより高速に実行することを意味し、最適化とはコードを読みやすくすることです）違う）それなら多分、片付けが多すぎる。片付けが悪いからではなく、何かを開発するために会社が開発にお金を払っているからです。彼らは、もろく、読みにくく、不十分に設計されたソリューションを望んでいませんが、洗練された美しいハーフソリューションも望んでいません。
「始める」ために何か簡単なことをする必要があるとき、または別のチームがあなたの問題が実際に彼らのせいなのかどうかを知らせるのを待っているとき、または決定を待っているときに片付けてください。たくさんの機会があります。アプリ全体を前に進める可能性がある場合は、全体がもろくなっていると感じ始めない限り、それを実行してください。おそらくそうではありません。あなたはリファクタリングする機会を得ます-あなたはそれについて心配する必要はありません。
質問の後半、短いタイムラインに直面している機能を追加するためのスプリントに戻るために、「そして我々はいかなるリファクタリングもしません、時間がない」と言うのは間違っているでしょう。また、「6週間が経過しており、ユーザーにはまったく同じように見えますが、これらの壊れたウィンドウは本当に修正する必要があった」と言っても間違いです。任意のプロジェクトで発生するギャップにリファクタリングを適合させます。プロジェクトの目標を達成することを犠牲にして片付けに逃げ場を作らないでください。
ビジネスの観点からは、リファクタリングは投機的な投資です。将来的にはより多くの時間と労力（お金）が節約されることを期待して、今は時間と労力（お金）を投資します。
リファクタリングの努力が将来にどれだけ節約できるかについての議論に参加することなく（これはあまりにも多くの変数に依存しているため、ここで意味のある議論をすることはできません）、「正味現在価値」がいつリファクタリングされるかは明らかですそれを残すコストの現在のコストを超えています。
簡単なことですが、将来のコストがどれくらいかはわかりません。また、投資収益率、リスク管理（ブランド価値、法的責任、保険リスクと非保険リスク）、運用コストなど、すべての通常の財務計画のアイデアを考慮に入れる必要があります。
ほとんどの場合、いつリファクタリングするかはビジネスを運営する人に任せるのが最善です。このフォーラムの多くのポスターが発声しているにもかかわらず、マネージャーは通常、プログラマーよりもビジネスの実行についてはるかによく知っています。彼らは、株主へのリターンを最大化することを含む、より大きな構想を持っています。壊れていないものを修正することがこれに寄与することはまれであり、コードも例外ではありません。
編集：重要なインフラストラクチャの保守スケジュールに関する興味深い記事を読みました。要点は、ムーブメントが必要なときに修理する（バグを修正する）日常的なメンテナンス（リファクタリング）から離れていることです。主な違いは監視レベルです。たとえば、原子力発電所は非常に詳細に監視し、「壊れた」ときでも障害のかなり前に修正します。発見されたのは、maintainceスケジュールへの修正はコストがかかるだけでなく、maintainceプログラムによる停止のために信頼性が低下することです。ソフトウェアにも同様の考え方が必要です-壊れそうなビットをリファクタリング-これは測定によってしか知ることができません。
それらを修正することによるビジネスへの損害がそれらを修正しないことによるよりも大きい場合は許容できます。
これが発生する状況は次のとおりです。
- 修正に必要な時間が原因で、締め切りやビジネスチャンスが失われる可能性がある場合
- コードの一部が（通常）非常に短い時間スケールで廃止されるようにスケジュールされているため、コードをリファクタリングするメリットはほとんどありません。
そして、これらの状況は発生します-商業的状況は、交渉する機会が過ぎたときに満たされなければならない人為的な締め切りと、時間の要素を含む要件を引き起こすことがよくあります-例えば、施行される法律や税制の変更特定の日付-存在します。
秘訣は、これらの状況を識別して適切に評価することです。廃止される予定のコードは、何年も使用されることがよくあります。人工的な期限は満たす必要があるかもしれませんが、多くの場合、さまざまな方法で満たすことができます（たとえば、最終リリースバージョンを必ずしも後で完了することなく、特定の日にソフトウェアを提示、デモ、および「起動」することができます）。
このようなものが提示されたとき、心を開いてアプローチする必要がありますが、常に何が表示されるのか尋ねてください。関係する仮定は現実的ですか？標準以下のコードを出荷せずに目標を達成する別の方法はありますか？利用可能な時間をどのように使用すればよいですか？
そして、代替手段がない場合は常に問題ありませんが、いつこれを修正しますか？
ほとんどの場合、ほぼ常にwhenである必要があるため、ifではありません。
経営者が積み上げたいと決心した場合 技術的負債 。これは、たとえば、初期のプロトタイプを初期の顧客に提供して、初期のフィードバックを得たい場合に行う公正な決定です。
クレジットを求めるのと同じように考えることができます。短期的にXに投資するためにお金を借りて、長期的にそれを支払うのは大丈夫ですか？明確な答えはありません。それは、組織の最善の利益になる可能性があります（たとえば、現在のクライアントの期待に応えるため）、または無責任に行われた場合は、惨事になる可能性があります。
それはすべて優先順位に帰着し、経営者は「コードを機能させる」こと、新機能を実装すること、そして顧客の期待に応えることが最優先事項であるにもかかわらず、壊れたウィンドウを離れるたびにその最優先事項を遅くすることに注意する必要がありますより難しく、より多くのリソース投資を必要とします。また、99％の時間は、新機能の開発をやめ、「コードベースの修正」に全力を注ぐのは現実的ではありません。
結論として、ローンを要求するのと同じように、壊れた窓を時々残すことは許容されます...本当に、本当に将来的にそれを支払う必要があることを覚えておいてください。そして将来的には、それを実行するための時間は、現在の時間よりもはるかに長くなる可能性はほとんどありません。
ほとんどのプログラマーは雇用主のためにお金を稼ぐ仕事をしています。それで、いつリファクタリングが起こるべきか：それがあなたの会社のお金を稼ぐとき。リファクタリングは、他のプロジェクトに費やされなかった時間と、このプロジェクトで将来節約される時間です。
それが価値があるかどうかは、主にマネージャー次第です。
プログラマーは、ビジネス側に技術的負債の範囲を知らせて、情報に基づいた決定を行えるようにする必要があります。より早く市場に出す必要性がコードのリスクを上回っている場合、選択肢はあまりありません。キャッシュフローの不足は、多くの技術的な決定に優先します。
一部の問題を非技術的な観点に当てはめるには、バグを修正して新しい機能を追加するための長い時間を指摘します。経営陣が販売およびマーケティングのバックグラウンドを持っている場合、彼らはこれを理解するかもしれません。彼らは顧客にこれらのことはもっと時間がかかるだろうと言わなければならないのを嫌います。
チームの拡大を検討している場合は、ジュニアデベロッパーを雇うのに良いタイミングかもしれません。この場合、テストカバレッジは大きな救世主になります。ドキュメントを読むよりも、実践する方が多くのことを学びます。
このシナリオの期限を設けるために、既存のコードへの主要なリファクタリングを延期することは正当化できますか？
- 何かが壊れている場合、おそらくそうではありません。ブレーキが部分的に作動している車を運転することはありませんか？ （時間内にどこかに到達しないリスクが、故障したブレーキのためにクラッシュするリスクよりも大きい場合を除きます。）理想的な解決策には程遠いですが、残念ながらそれは起こります。
ただし、作業コードのリファクタリングについて話している場合は、次のことを検討します。
それが私たちのソフトウェアをリリースすることは決してなかったというよりも、それが私たちの上級開発者またはテクニカルディレクター次第だったとしたら。私たちは常にリファクタリングを行い、完璧主義を目指しています。
リファクタリングがビジネスの収益性に悪影響を与える場合は、再スケジュールする必要があります。
特定の機能を特定の日付までに提供すると約束した場合は、後でリファクタリングします。 Red Nose Dayチャリティーについて考えてみてください。毎年24時間または48時間、寄付を集めることができます。彼らがその時間差で寄付をするのを止めるかもしれないと彼らが思ったならば、彼らが彼らのコードベースをリファクタリングする方法はありません。さらに、壊れたウィンドウがあっても、寄付を受ける能力に影響しない場合は、リファクタリングしないことを選択する可能性が高くなります。
あなたはいつも何かをするためのより良い方法を見つけるでしょう。それは自然なプロセスであり、線を引くことができることが非常に重要です。
通常、可能な場合は、修正する必要があります。これにより、メンテナンスに費やされる潜在的な時間を防ぐことができます。ただし、一部の野蛮な非アジャイルプラクティスは、機能している限り、現状を維持する傾向があります。一部のマネージャは、変更の「予期せぬ影響」を恐れています。
私の考えでは、正常に機能している場合（最適化によってのみ機能し、機能によっては機能しません）だけにして、リファクタリングを行う場合、テストする時間がありません。ただし、できるだけ早く修正する必要があることに注意してください。
機能が壊れており、新しい機能がそれに依存している場合は、できるだけ早く修正することをお勧めします。