古いコードを改善する責任がありますか？
私が書いた古いコードを調べていました。動作しますが、優れたコードではありません。私はその時よりも今知っているので、それを改善することができました。これは現在のプロジェクトではありませんが、現在の実用的な製品コードです。私たちは過去に書いたコードに戻って改善する責任がありますか、それとも「それが壊れていない場合は修正しないでください」という正しい態度ですか？私の会社は数年前にコードレビュークラスを主催しましたが、大きなポイントの1つは、それで十分な場合もあるということでした。進め。
それで、ある時点でそれを十分に呼び出して次に進むべきでしょうか、それともより良いと思われるときに古いコードを改善するためにプロジェクトをプッシュしようとすべきでしょうか？
バグを修正したり機能を追加したりするためにこの「古いコード」に変更を加えない限り、私はそれだけのためにそれを改善しようとはしません。最終的にコードを改善したい場合は、コードのリファクタリングを開始する前に、コードをテストする単体テストを実施していることを確認してください。
「古いコード」を使用して、より良いプラクティスを学ぶことができます。これを行う場合、それはパートタイムの学習体験であり、クライアント/顧客によって現在リリースまたはデプロイされているものをそのコードが置き換えることを期待すべきではありません。
最も頻繁に変更する必要があるコード領域をリファクタリングする。これらの領域に頻繁にアクセスするため、リファクタリングを行うと、コードへの理解が深まり、再度アクセスする必要がある場合の読みやすさが向上します。一方、コードをリファクタリングしても、誰も二度と見る必要はありません。
さらに、コードを変更する必要があるときにコード領域のみをリファクタリングする場合、それはリファクタリングによって回帰が発生した場合に有効な言い訳を提供しますです。もちろん、ユニットテストでリファクタリングをカバーするようにしてください。ただし、特にレガシーコードでは、これが常に可能であるとは限らず、大きなリファクタリングがたまにリグレッションを作成することを期待する必要があります。
機能を追加する必要がある場合、設計により速度が低下するか、複製が発生するため、リファクタリング。コードを設計するとき、将来どのような変更が必要になるかを正確に予測することはほとんどありません。ただし、新しい機能を追加すると、通常は共有コードのリファクタリングが行われます。そのときまでに、3番目の機能/リファクタリングサイクルを追加しました。私のリファクタリングはすでに採算が取れており、共有コードはかなり安定しています。
TLDR：必要に応じてリファクタリングします。義務はありません。
あなたがするすべてはコストがかかります。プログラムする時間は限られています。プログラミングで行うことはすべて、「これを行う利点は何ですか？」そして「何か他のことをする利点は何ですか？」
機会費用を考慮しない場合（何か他のことを行う場合の費用は？）、品質は無料です。コードを改善することをお勧めします。あなたは何かを学ぶでしょう。それはよりよく実行されます。もっと売るよ。
本当の質問は、あなたがあなたの時間を使って次にできる最高のことは何ですか？そして、あなたにはトレードオフがあります。
より多くのソフトウェアを販売しますか？
サポートする頭痛が減りますか？
何を学びますか？
見た目がより美しくなりますか？
それはあなたの評判を向上させますか？
キュー内のこのアクティビティや他のアクティビティについて、これらの質問（およびあなたに関連する他の質問）を尋ねてください。修正する価値がある場合は、回答に役立ちます。これらのトレードオフが、プログラマにとって経済学が重要な理由です。 ジョエル は私がする前にそれを言いました、そして、古いメンターはジョエルの前でさえ私にそれを言いました。
または、より簡単な回答が必要な場合は、コードを修正するまでテレビの視聴をやめてください。 :-)
見逃されているように思われる質問を自分自身に尋ねることから始めるべきだと思います。コードはどのように悪いのですか？これにより、あなたは本当に次のことを自問しています：
- コードは、本来あるべきことをしていませんか？
- ソフトウェアを保守しているときにコードが問題を引き起こしていますか？
- コードは完全に自己完結型ですか？
- 近い将来、いつでもコードを更新または置き換える予定はありますか？
- あなたが心配しているコードを更新するためにできる健全なビジネスケースはありますか？
私が長年にわたって学んだことの1つがあるとしたら、それはあなたが事実の後に自分自身を推測する余裕がないということです。コードで問題を解決するたびに、何かを学び、おそらくあなたのソリューション（または類似の何か）が何年も前に別の方法で解決した問題のより良い解決策であったかもしれないことを見るでしょう。これはあなたがあなたの経験から学んだことを示しているので、良いことです。ただし、本当の問題は、以前に作成したコードが、時間の経過とともに処理することがより困難になるレガシー問題になる可能性があるかどうかです。
ここで実際に話しているのは、煩わしいコードの保守が容易か困難か、そして時間の経過に伴ってその保守にかかるコストがどれほどかかるかです。これは基本的に、技術的負債についての質問であり、少しの外科的メンテナンスを使用してその負債を返済する価値があるのか、それとも少しの間スライドさせることができるほど負債が少ないのかです。
これらは、現在および将来の作業負荷と比較検討する必要がある質問であり、リソースをどこに投資するか、および古いコードに価値があるかどうかをよりよく理解するために、経営陣およびチームと詳細に話し合う必要があります。あなたがそれに費やす必要があるかもしれない時間-もしあれば。変更を導入するための良いビジネスケースを作成できる場合は、必ずそうしてください。ただし、コードの作成方法に恥ずかしいと感じてコードをいじくり回したいという衝動に直面している場合は、古いコードの保守に関しては、個人的な誇りの余地があります。それは機能するか機能しないかのどちらかであり、保守が容易であるか、保守にコストがかかります。そして、今日の経験が昨日利用できなかったという理由だけで、それは決して良くも悪くもありません。
絶対に改善しないでくださいjust改善のために。他の人が言ったように（そして常識です）、時間が経つにつれ私たちは皆、（「より良い」というある価値のために）より良くなります。とはいえ、コードを（公式または非公式に）確認すると、これらの要素が明らかになり、私たちが二度と日の目を見ることを望んでいないことがよくあります。
responsibilityに戻ってコードを改善し、根本的に壊れていないか、安全ではないか、非推奨/ EOLリストの機能に依存していないと私は信じていませんが、ここにいくつかのことがありますこの状況で過去に行われた：
頭脳を浄化したり、達成感を与えたりする一口サイズのタスクのようなものとして、実際に戻ってコードを改善しているチームの人々を特定し、定期的に実行するための時間をスケジュールで見つけます。私は常にチームにこれらの種類の人々の少なくとも1人を抱えていました。このアプローチは、全員が落ち着いたまたはダウンしているときにも士気（または少なくとも気分）を高めることができます。
学習の基礎として使用してください。インターン、学生、またはチームの新規/ジュニアメンバーの場合、チームのシニアメンバーからのガイダンスで古いコードをリファクタリングすることで、新しいチームメンバーとコミュニケーションを取り、システムについてさらに理解し、書く習慣を身につけることができます/単体テストの更新と継続的インテグレーションの操作。この演習はガイダンスを使用して行われ、演習として明確に構成されていることに注意することが重要ですコードをより良くするため現在の標準/規範に準拠していないためです。
だから、それを修正する責任はありませんが、その古いものは本当に便利です。そしてユニットテストとCIはあなたの友達です！
マイクロソフトはウィンドウを更新する必要がありますか？すべての* nix Distroは進化し続ける必要がありますか？または、より実用的な例では、誰もがまだ1970年代の車を運転していますか？
必ずしも。ただし、コードのメンテナンスを実行しているときに、より良い可能性のあるものに偶然遭遇した場合、回帰を作成していないことを確認する適切な単体テストがあれば、変更することができます。
そのようなテストが存在せず、正しく動作するかどうか確信が持てない場合は、そのままにしておくことをお勧めします。
エンジニアの観点からは、これ以上改善できなくなるまで、古いコードで作業したいと思います。しかし、そのためのビジネスケースはありますか？結局のところ、コードは、あなたの職場の収益性、つまり最終的な収益に貢献するためのものです。そうでない場合は、そのままにしておきます。
大きな注意点があります。コードを改善することでバグの発生を回避する場合（大きなY2Kボールはここにあると思います）そして、コードを改善することの結果について議論します。
私については、質問を言い換えて一般化することができます。「コードの具体的な部分が今うまく機能するのに、なぜ誰かが追加のリソース（時間、お金、精神など）を使う必要があるのですか？リソースの無駄ではありませんか？ ？」
レガシーコードを見つけるたびに、重要だと思われるいくつかのことについて考えます。
- 何を変更するのですか？
- このコードをサポートする必要がありますか？それはどれくらい早く起こりますか（近い/遠い未来）？
- このコードは使用するのに十分快適ですか？ （たった今）
- 私が行ったすべての変更が安全であることを確認できますか？通常、さまざまなテストがこの質問への回答に役立ちます。
- コードの変更中にミスを犯した場合、どのような影響がありますか？変更をすばやく元に戻すことはできますか？時間の無駄でしょうか？
- ...
実際、たくさんの質問をするべきです。それらの完全で最終的なリストはありません。あなたとおそらくあなたのチームメイトだけが答えを見つけることができます。
追伸私はコードを頻繁に書き換える傾向があるのに気づきましたが、友人やチームメイトはコードをそのままにする傾向があります。これは、前述の質問に対する回答が異なるためです。そして、私たちはそれらを非常に頻繁に誤解していると言わざるを得ません。
古いコードのリファクタリング/改善はプログラマー自身を定義していると私は感じています。 1年前に作成したコードを改善したい場合は、進捗状況のみが表示されます。アプリケーションが改善され、改善する能力、時間、および承認がある場合は、それを実行します。
より良い/改善されたのは、多軸比較です。より速く、より小さく、よりリソース効率がよく、より読みやすく、より有用な情報、より正確な結果、より柔軟で、より一般的で、より多くのシステムで実行でき、別の製品への依存を排除できると思いますか？
なぜあなたの会社は、新しいコードを書いたり、他のコードを書き直したりする代わりに、このコードを書き換えるのに時間を費やすようにお金を払う必要があるのでしょうか？
機会が現れるにつれて改善を行う必要がありますが、機会とは、すでにコードに取り組んでいるか、変更を加えるビジネス上の理由を特定したことを意味します。
本番環境への変更をプッシュすると、物事が破壊される可能性がゼロではなくなります（単体テストと機能テストではこのチャンスが減るだけで、排除されることはありません）。期待されるメリットがリスクを上回る場合にのみ実行する必要があります。
検討すべきもう1つのポイントは次のとおりです。この変更を本番環境にプッシュするつもりですか、それとも単に開発ブランチにプッシュするつもりですか？ 2つのシナリオのバーは完全に異なります。開発ブランチでのみ行われ、本番環境に入ることができない場合、基本的に機会があるということは、なんらかの理由でコードを見ていることを意味し、実行に時間はかかりません。プッシュが発生する必要がある場合は必要に応じて確認し、that時に不当と見なされる場合は省略できます。一方、先に述べたように、今すぐ本番環境に移行する場合は、この変更がコストに見合うかどうかを検討する必要があります。つまり、Pushの作成に費やされた時間と、新しいコードを使用することの利点の観点からです。
経験則の1つは、コードが何をしているかを理解するのに時間がかかった場合、およびこの時間をいくつかの適切に選択されたリファクタリングによって将来削減できる場合は、ビジネスとチームのニーズに応えることです。これらの手順を実行します。
コードが分析の恩恵を受けない場合、フィールド名がコードの意図を表すものにならず、メソッドが読み取り可能なチャンクに分解されていない場合、ビジネスは価値のあるもの、つまり理解の状態を失っています。 Visual StudioやReSharperなどのツールを使用すると、これらの種類のリファクタリングは安全で論理的に中立であり、将来の開発者の生産性と信頼性に大きな価値をもたらす可能性があります。
ボブ・マーティンおじさんが言うように、「あなたがそれを見つけたよりも常にキャンプ場をきれいにしておいてください。」
これはあなたの会社の経営者に尋ねる質問です。
戻って古いコードに変更を加えるのに必要な時間とリソースはありますか？
QAチームが壊れていないことを確認するために変更したものをテストする時間とリソースはありますか？
バグを修正するモジュールに入る前にこの罠に陥り、私または他の誰かが書いたコードが非効率的または無能であることを確認し、それを変更して、修正した場合よりも対処すべき問題が多くなる私が修正するように命じられたバグ。
通常、2回目はコードをより適切に記述できます。最初にコードを記述することで、ドメインについてさらに学習しました。
再評価する価値があるかどうかについては、簡単な答えはありません。一般に、a）それがあなたにとって良い学習のエクササイズであるか、またはb）より良いコードで長期的に時間を節約することにならない限り、すべきではありません。すべての変更はバグのリスクになることを忘れないでください。
余談ですが、ユニットテストを強く推奨します。特に自動休符で明確にマークダウンされた現在の動作がない場合は、リコアリングを非常に簡単に修正できます。
私たちには、今日できる最高のコードを書く責任があると信じています。つまり、これまでに学んだことをすべて使用し、デザインのショートカットを取ることを拒否しています。スケジュールのプレッシャーが原因で何かが削減される場合、ソフトウェアの品質も考慮に入れるべきだとは思いません。その一方で、アニメーション化された小さなアニメーションペーパークリップは...
作業をしていて、対話する必要があるコードが現在記述できるレベルまで記述されていない場合は、制御された方法で実行できる場合は修正するのが妥当です。私は個人的に、この種のリファクタリングの経験はほとんどありません。誰もが（ほぼ全員が？）、「すべてを変更して、うまくいくように祈る」ように全体を試してみました。この問題に関するMartin Fowlerの議論（ 彼の本 または 多くの記事の1つ ）を調べることをお勧めします。彼は、プロセスに関する現在の考えのほとんどに影響を与えたようです。
もちろん、コードを思い通りにクリーンアップできない場合もあります。 Joel Spolskyが、コードを単純にリファクタリングするために数週間を費やす必要がある理由についての記事を書きました。それを読んでください ここ そしてはい、それは少し古いですが、情報はまだ関連性があると思います。
それが役に立てば幸い
場合によります。
問題のコードが本当に壊れていて、ある時点で必然的に表面化するバグが含まれている場合（たとえば、ある時点でオーバーフローして厄介な問題を引き起こすカウンターがある）、それらを修正することは努力に値するかもしれませんが、新しいバグの導入を避けるために、可能な限りすべての保護手段を最初に配置してください：触れたすべてを網羅する意味のあるユニットテストがあることを確認し、有能な誰かがすべての変更をレビューし、徹底的にテストを主張し、以前のバージョンに戻せることを確認してくださいいつでもバージョンを作成し、本番環境に移行する前にデータをバックアップし、最初に受け入れ環境に展開し、実際のユーザーがテストしてもらうなど。先に進む前に承認を得ることもできます。バグが本当に時限爆弾の場合、そしてあなたの上司がやや有能であるなら、あなたは彼/彼女にあなたにそれを修正させるように説得することができます（そしてあなたが承認を得なければ、そしてそれはおそらくあなたが間違っている兆候です）。
OTOH、あなたの不満が単にコードの優雅さの欠如であるならば、あなたはそれに敢えて触れないでください。本番環境では忠実なサービスを提供してきましたが、コードを変更しても満足できるだけで価値はありません。すべての変更と同様に、何かを壊すリスクがあります。そうしなくても、あなたの時間は貴重です（文字通り：あなたはあなたがすることに対して報酬を受け取っているので、あなたの時間の毎分はお金がかかります）、そしてあなたは実際の価値を加えていないので、そのような変化は会社とプロジェクトの純損失。