古いコードを改善する責任はありますか？

私が書いたいくつかの古いコードを見ていました。動作しますが、すばらしいコードではありません。私は当時よりも多くのことを知っているので、改善することができました。これは現在のプロジェクトではありませんが、現在の作業中の製品コードです。過去に書いたコードに戻って改善する責任がありますか、それとも「壊れていない場合は修正しないでください」という正しい姿勢ですか？私の会社は数年前にコードレビュークラスを後援しましたが、重要なポイントの1つは、時にはそれで十分であるということでした。進め。

それで、ある時点でそれを十分に呼び出して先に進むべきですか、それともより良いと思うときに古いコードを改善するためにプロジェクトをプッシュしようとするべきですか？

バグを修正したり機能を追加したりするためにこの「古いコード」に変更を加えない限り、それのためだけに改善するつもりはありません。最終的に改善したい場合は、リファクタリングを開始する前にコードをテストするユニットテストがあることを確認してください。

「古いコード」を使用して、より良いプラクティスを学ぶことができます。これを行う場合、それはパートタイムの学習体験であり、そのコードがクライアント/顧客によって現在リリースまたは展開されているものに置き換わることを期待するべきではありません。

最も頻繁に変更する必要があるコードの領域をリファクタリングします。これらの領域に頻繁にアクセスするため、リファクタリングを行うとコードを理解しやすくなり、再度アクセスする必要があるときに読みやすくなりますが、コードをリファクタリングすることは誰にも見られません。

さらに、コードの領域を変更する必要があるときにのみコードのリファクタリングを行う場合、リファクタリングによってリグレッションが発生した場合に有効な言い訳になります。もちろん、リファクタリングを単体テストでカバーしようとしますが、これは常に可能というわけではありません。特にレガシーコードでは、時々大きなリファクタリングがリグレッションを作成することを期待する必要があります。

機能を追加する必要があり、設計によって速度が低下したり、重複が発生したりする場合は、リファクタリングします。コードを設計するとき、将来どのような変更が必要になるかを正確に予測することはほとんどありません。ただし、新しい機能を追加すると、通常は共有コードをリファクタリングします。その時までに、3番目の機能/リファクタリングサイクルを追加しました。私のリファクタリングはすでにそれ自体に対価を支払っており、共有コードはかなり安定しています。

TLDR：必要に応じてリファクタリング、義務はありません。

あなたがするすべてには費用がかかります。プログラムする時間が限られています。プログラミングで行うことはすべて、「これを行うことの利点は何ですか？」に対して検討する必要があります。そして「何か他のことをすることの利点は何ですか？」

機会費用を考慮しない場合（何か他のことをする費用はいくらですか？）、品質は無料です。コードを改善することをお勧めします。あなたは何かを学びます。うまく動作します。もっと売れます。

本当の質問は、あなたがあなたの時間を使って次にできることは何ですか？そして、あなたはトレードオフをしました。

より多くのソフトウェアを販売しますか？

サポートする頭痛が少なくなりますか？

何を学びますか？

それはより審美的に喜ばれますか？

それはあなたの評判を改善しますか？

キュー内のこのアクティビティおよびその他のアクティビティについて、これらの質問（およびあなたに関連する他の質問）を尋ねると、修正する価値がある場合に回答するのに役立ちます。これらのトレードオフは、経済学がプログラマーにとって重要である理由です。 ジョエルは私がする前にそれを言った、そして古いメンターはジョエルの前でさえ私にそれを言った。

または、より簡単な回答が必要な場合は、コードを修正するまでテレビの視聴をやめてください。:-)

逃したと思われる質問を自問することから始めるべきだと思います。コードはどのように悪いのですか？そしてこれにより、あなたは本当に次のことを自問しています：

• コードは、想定されていることを行いませんか？
• ソフトウェアを保守しているときに、コードが問題を引き起こしていますか？
• コードは完全に自己完結型ですか？
• 近い将来、いつでもコードを更新または置換する予定はありますか？
• 懸念しているコードを更新するために行うことができる健全なビジネスケースはありますか？

私が長年にわたって学んだことが1つあるとすれば、それはあなたが事後に自分自身を再考する余裕がないということです。コードで問題を解決するたびに、何かを学び、おそらくあなたのソリューション（または同様のもの）が何年も前に異なる方法で解決した問題に対するより良いソリューションであったかどうかを見るでしょう。経験から学んだことを示しているので、これは良いことです。しかし、本当の問題は、以前に書いたコードが、時間の経過とともに対処するのがより難しくなるレガシー問題になる可能性が高いかどうかです。

ここで私たちが本当に話しているのは、わずらわしいコードのメンテナンスが簡単か難しいか、そしてそのメンテナンスが時間の経過とともにどれほど費用がかかるかということです。これは本質的には技術的な負債についての質問であり、少しの外科的メンテナンスを使用してその負債を完済する価値があるのか​​、それとも負債が少しスライドできるほど小さいのかということです。

これらは、現在および将来の作業負荷と比較検討する必要がある質問であり、リソースの投資先や古いコードが価値があるかどうかをよりよく理解するために、経営陣およびチームと詳細に議論する必要がありますあなたがそれに費やす必要があるかもしれない時間-もしあったとしても。あなたが変更を導入するための良いビジネスケースを作ることができるなら、どうしてもそうしますが、あなたがそれを書いた方法に恥ずかしさを感じるためにコードをいじくり回す衝動に直面しているなら、私はないことをお勧めします古いコードを維持することに関しては、個人的なプライドの余地があります。それは機能するか機能しないかのいずれかであり、保守が容易であるか、保守に費用がかかります。昨日は今日の経験がなかったからといって、決して良いことでも悪いことでもありません。

改善するためだけに改善しないでください。他の人が言っているように（そして常識です）、時間が経つにつれて、私たちは皆（「より良い」という価値のために）良くなります。そうは言っても、コードを（正式にまたは非公式に）レビューすると、これらの断片を明らかにすることがあります。

基本的に壊れたり、安全でなかったり、非推奨/ EOLリストの機能に依存していないコードに戻って改善する責任があるとは思いませんが、この状況で過去に行ったことをいくつか紹介します：

• チームのメンバーを本当に掘り下げてコードを改善する人を特定し、達成感を与える一種の脳の浄化または素敵な一口サイズのタスクとして、定期的にそれを行うためのスケジュールの時間を見つけます。私は常にこの種のチームの少なくとも1人をチームに所属させてきましたが、このアプローチは、すべてが落ち着いているときや落ち込んでいるときに士気（または少なくとも気分）を高めることもできます。

• 学習演習の基礎として使用します。インターン、学生、またはチームの新メンバー/ジュニアメンバーの場合、チームのシニアメンバーからのガイダンスを使用して古いコードをリファクタリングすることで、新しいチームメンバーとコミュニケーションを取り、システムについてより深く理解し、記述/単体テストの更新と継続的インテグレーションの使用。この演習はガイダンスを使用して行われ、現在の標準/規範に準拠していないため、コードを改善するための演習として明確に構成されていることに注意することが重要です。

したがって、それを修正する責任はありませんが、その古いものは本当に便利です。そして、単体テストとCIはあなたの友達です！

必ずしも。ただし、コードメンテナンスを実行していて、より良いものに偶然出くわした場合、適切な単体テストがあれば、それを変更して、リグレッションが作成されていないことを確認できます。

そのようなテストが存在せず、正確にどのように動作するか確信がない場合は、そのままにしておく方が良いでしょう。

エンジニアの観点からは、それ以上改善されなくなるまで、古いコードで作業したいと強く思います。しかし、それに対するビジネスケースはありますか？結局のところ、コードは、最終的な収益、つまり職場の収益性に貢献するためのものです。そうでない場合は、そのままにしておきます。

大きな警告があります。コードを改善することでバグの発生を回避する場合（ここで大きなY2Kボールを考えてみてください）。また、コードを改善した結果について話し合います。

私に関しては、質問を言い換えて一般化することができます。「その具体的なコードがうまく機能するのに、なぜ誰かが追加のリソース（時間、お金、精神など）を費やす必要があるのですか？ ？」

レガシーコードを見つけるたびに、重要だと思われるいくつかのことを考えます。

1. 何を変更するのですか？
2. このコードをサポートする必要がありますか？それはいつ（近い/遠い未来）起こりますか？
3. このコードは動作するのに十分快適ですか？（たった今）
4. 私が行うすべての変更が安全であると確信できますか？通常、さまざまなテストがこの質問に答えるのに役立ちます。
5. コードの変更中に間違いを犯した場合、どのような結果に遭遇しますか？変更をすぐに元に戻すことは可能ですか？時間の無駄になりますか？
6. ...

実際、多くの質問を自問する必要があります。それらの完全で最終的なリストはありません。あなたとおそらくあなたのチームメイトだけが答えを見つけることができます。

PS私はコードを頻繁に書き換える傾向があることに気付きましたが、私の友人やチームメイトはそのままにしておく傾向があります。それは、私たちが言及された質問に異なる答えをするからです。そして、私たちはそれらを非常に頻繁に間違って答えると言わざるを得ません...私たちは未来を予測できないからです。

Microsoftはウィンドウを更新する必要がありますか？すべての* nixディストリビューションは進化し​​続ける必要がありますか？または、より実用的な例として、誰もが1970年代の車を運転していますか？

通常、2回目はコードをより適切に記述できます。最初に記述して、ドメインについてより多くを学びました。

再確認する価値があるかどうかについての簡単な答えはありません。一般的に、a）それはあなたにとって良い学習エクササイズであるか、b）より良いコードで長期的に時間を節約しない限り、あなたはすべきではありません。すべての変更がバグのリスクを伴うことを忘れないでください。

サイドノートとして、ユニットテストを強く推奨します。自動休符で明確にマークダウンされた現在の動作がない場合は特に、再火付けを台無しにするのは非常に簡単です。

私たちには、今日できる限り最高のコードを書く責任があると思います。つまり、過去に学んだことをすべて使用し、設計を短縮することを拒否します。スケジュールのプレッシャーが原因で何かが切断される場合、私たちのソフトウェアの品質を考慮する必要があるとは思いません。

現在、作業中に、やり取りする必要があるコードが現在の書き込み可能なレベルまで書き込まれていないことがわかった場合、管理された整然とした方法で実行できる場合は修正するのが合理的です。個人的には、この種のリファクタリングの経験は非常に少なく、誰もが（ほぼ全員ですか？）「すべてを変えて、それが機能するように祈りましょう」全体を試してみました。この問題に関する Martin Fowlerの議論（彼の本または多くの記事のいずれか）を調べることをお勧めします。彼は、プロセスに関する現在の考えのほとんどに影響を与えたようです。

もちろん、あなたが望むようにコードをきれいにできないかもしれません。Joel Spolskyは、コードを単純にリファクタリングするために数週間を費やす理由について記事を書きました。ここでそれを読んで、はい、それは少し古いですが、情報はまだ関連があると思います。

それがお役に立てば幸いです

古いコードのリファクタリング/改善がプログラマ自身を定義すると感じています。1年前に書いたコードを改善したいのは進捗状況だけであり、それがアプリケーションを改善し、それを改善する能力、時間、承認があれば、それを実行します。

多軸比較です。より速く、より小さく、よりリソース効率的で、より読みやすく、より有用な情報、より正確な結果、より柔軟で、より一般的に、より多くのシステムで実行でき、個別の製品への依存を排除​​できると思いますか？

新しいコードを書いたり、他のコードを書き換えたりするのではなく、このコードを書き換えるのに時間をかけるためにあなたの会社があなたにお金を払わなければならないのはなぜですか？

機会が現れたら改善する必要がありますが、機会とは、すでにコードに取り組んでいるか、変更を行うビジネス上の理由を特定したことを意味します。

本番への変更をプッシュすると、物事を壊す可能性がゼロ以外になります（単体テストと機能テストはこのチャンスを減らすだけで、それを排除することはありません）。

考慮すべきもう1つのポイントは次のとおりです。この変更を運用環境にプッシュするつもりですか、それとも開発ブランチにプッシュするつもりですか？2つのシナリオのバーはまったく異なります。開発ブランチでのみ行われ、本番環境に入らない可能性がある場合、機会とは基本的に何らかの理由でコードを見ていることを意味し、時間はかかりません。プッシュが発生する場合は必要に応じてレビューし、その時点で不当と見なされる場合は除外することができます。一方、上記で述べたように、本番に移行する場合は、この変更がコストに見合うかどうかを検討する必要があります。プッシュに費やす時間と、新しいコードを使用するメリットの点で。

良い経験則の1つは、コードの実行内容を理解するのに時間がかかり、適切に選択されたリファクタリングによってこの時間を短縮できる場合は、次の方法でビジネスとチームのニーズに応えることです。これらの手順を実行します。

コードが分析の恩恵を受けない場合、フィールド名がコードの意図を表現しておらず、メソッドが読み取り可能なチャンクに分割されていない場合、ビジネスは価値のあるものを失います：理解の状態。Visual StudioやReSharperなどのツールを使用すると、これらの種類のリファクタリングは安全で、ロジックに依存せず、将来の開発者の生産性と信頼性において潜在的に大きな価値があります。

ボブ・マーティンおじさんが言うように、「キャンプ場はいつもあなたが見つけたよりもきれいにしておく」。

これは、会社の経営者に尋ねる質問です。

戻って古いコードを変更するのに必要な時間とリソースはありますか？

QAチームに変更内容をテストして、破損していないことを確認する時間とリソースはありますか？

バグを修正するモジュールの前にこのtrapに陥り、非効率的または洗練されていないコードまたは他の誰かが書いたコードを見て、それを修正し、修正したばかりの場合よりも多くの問題に対処することになります私が修正するように命じられたバグ。

場合によります。

問題のコードが本当に壊れており、ある時点で必然的に表面化するバグが含まれている場合（たとえば、ある時点でオーバーフローして厄介な問題を引き起こすカウンターなど）、それらを修正する価値があるかもしれません-しかし、新しいバグの導入を避けるために、可能な限りすべての安全対策を講じてください：触れるものすべてをカバーする意味のある単体テストがあることを確認してくださいいつでもバージョンを作成し、実稼働に入る前にデータをバックアップし、最初に受け入れ環境に展開して、実際のユーザーなどによってテストします。また、先に進む前に承認を取得する必要があります。 、そしてあなたのマネージャーはいくらか有能で、あなたは彼/彼女にあなたにそれを修正させるよう説得することができるでしょう（そして、もしあなたが承認を得なければ、それは多分それはあなたが間違っているというサインです）。

OTOH、あなたの苦情が単なるコードの優雅さの欠如であるなら、あなたはそれに触れないでください。かなり長い間、本番環境で忠実なサービスを提供してきました。コードを変更しても満足できるだけで、付加価値はありません。また、すべての変更と同様に、何かを壊すリスクがあります。そうしなくても、あなたの時間は価値があります（文字通り：あなたはあなたがすることに対して報酬を受け取っているので、あなたの時間の1分ごとにお金がかかります）、そしてあなたは実際の価値を追加していないので、そのような変化は会社とプロジェクトの純損失。