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


64

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

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


あなたは自分の時間にこれをやっていますか?
JBRウィルキンソン

42
ほとんどの場合、最初の責任は会社に価値を加えることです。あなたが一番下の行に直接追加しない何かをしているなら、他のものは無駄な努力です。古いテスト済みの動作中のコードは、テスト済みの動作中のコードです。金メッキの演習と同じようにタッチすると改善され、テストされていない新しいコードになり最終的に価値を追加しません。

7
上司にあなたに何をしてほしいか尋ねてください。ほとんどの場合、そのままにしておくように言われます。また、私の経験では、コードの変更は実際の配信の一部としてのみ行う必要があります。時間の経過に伴うランダムな変更は、エラーが発生する可能性が大きすぎるため、変更を念頭に置いていないため、修正に時間がかかりすぎます。

1
ドキュメントに改善の可能性についてコメントを追加し、それを残しますか?
ジェームズP.

2
単体テストまたは回帰テストを作成します。コードを変更しないでください。ただし、コードに精通していなくても、誰かが後で一緒に来て必要な変更を自信を持って行えるようにします。
ジェームズヤングマン

回答:


66

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

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


4
私が考えていたのは、「ソフトウェアの腐敗」と実用的なプログラマーからの壊れたウィンドウ理論とソフトウェアエントロピーの影響です。pragprog.com/the-pragmatic-programmer/extracts/software-entropy
jmq

5
すでに機能し、運用中のコードをリファクタリングして会社に価値を追加する場合を除き、上司に「ソフトウェアの腐敗」を取り除くために必要な時間を正当化することは困難です。これを行うのは、このコードで積極的に作業する場合のみにしてください。そうしないと、リファクタリングの経験が得られる以外のメリットはあまりありません。
バーナード

11
@jmquigley、ソフトウェアはソースコードが変更された場合にのみ腐敗し、壊れたウィンドウは表示された場合にのみ効果があります。古いコードベースは、それに触れる必要がない場合、その環境で許可されている限り同じように機能します。
ペテルトレック

2
それを「改善」する過程で作業プログラムにエラーを導入しないようにしてください;-)
ロブラムブッシュ

4
コード「腐敗」は不幸な比metaだと思います。コードが腐敗することはありません。何もしなければコードはまったく変化しません。どちらかといえば、コードの作業が強化されます-作業中にエントロピーが導入され、リファクタリングに多くのエネルギーを費やすことでこのエントロピーを削除できます(リキャスト/フォージングに似てい
ます

32

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

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

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

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


「リファクタリングによりリグレッションが発生する」とはどういう意味ですか?リファクタリングの目的は、動作を変更せずにソフトウェアの設計を改善することですか?例を挙げていただけますか?
マンフレッド

3
@John:はい、それはリファクタリングの目的です。コードを改善しますが、動作は維持します。
バーナード

@Johnは、特にリグレッションテストが実施されていない場合に、重要なリファクタリングが意図せずに動作を変更するリスクを負います。
ギャレットホール

14

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

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

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

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

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

何を学びますか?

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

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

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

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


4
ソフトウェアではない実際の例を借りるために、輸送会社の中には、さまざまな理由で従業員に報酬を支払ってリグをきれいに磨くものがありますそして、それにもっと注意を払う。問題を迅速かつ便利に回避します。同じトークンで、もしマイルを稼ぐなら、トラックに乗り込んでそれを運転し、さらに数千マイル(海岸から海岸に行く)後に掃除することを心配します。
JustinC

@justinC-まさに!この例では、別の理由と機会費用の両方を把握しています。
MathAttack

コスト(またはvalueなど)は、まさに正しい答えのキーワードです。全体の価値を高める必要があります。古いコードに触れると、どんなに最適化されていても、何かを壊す(値を削除する)可能性があることも考慮してください。
クレゴックス

6

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

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

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

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

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


5

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

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

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

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

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


4
初心者に悪いコードを与えることは、プロジェクト管理の最悪のアンチパターンです。彼らはそれを見て、それが正しいと考え、それを複製するだけです。

1
@JarrodRoberson私がもっと明らかにすべきだったことを指摘してくれてありがとう。私は答えを編集して、これを学習体験の一部として非常に具体的に行っており、彼らはメンターと協力していることに注意しました。スローエンドインザディープエンドの状況ではありません。
-jcmeloni

私は今でも人々が「初心者に教えてください。特にインターンと学生」という言葉で書かれていると思いますすぐに読解を停止します。シニアメンバーとジュニアメンバーのペアでXPスタイルまたはそのような何かをプログラミングすることから始まったと言われた場合、それほど悪くないかもしれません。私は金メッキの側面に問題があり、最初の弾丸のポイントを変更するために物事を変更するリスクを追加しました。

1
コードレビューは、のためのもの防止バージョン管理に入るの悪いコードを、事後に貧しいコードを識別するために、それが遅く、その後への道ではありません。

@JarrodRoberson私のあいまいで、残念ながら誤解を招く可能性のある言語であなたが抱えていた問題を指摘してくれてありがとう。私はさらに編集を行い、現在の状況に対応しています。
jcmeloni

2

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

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


4
「それを変更しても、計画されたスケジュールに多くの時間が追加されない場合」
-HLGEM

2

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

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


2

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

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

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

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

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


2

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


1

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

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

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


1

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

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

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

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


1

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


1

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

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

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

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

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


本番環境にプッシュすることを意図していない本番コードの変更 しかし、開発ブランチに保管されていますか?うーん。私はそれを受け入れるとは思わないでください。後で開発を混乱させ、複雑にするだけです。なぜなら、それが変更されるべきかどうか(再び)、生産を目的とする他​​の変更に準拠するべきかどうかが誰にもわからないからです。
マルジャンヴェネマ

@MarjanVenema:開発が停止したとき、すべてのブランチは同一でなければなりません。後で改善できるが改善する必要のないものを後で見つけた場合は、開発ブランチで改善し、開発が再開されて新しいプッシュが行われるのを待ちます。
-jmoreno

ああ、わかった。私にとって、それはそれがまだ後の生産のために意図されていることを意味します。また、問題追跡システムに付随する問題があることを確認しない限り、非常にリスクが高くなります。そのため、テスター/ QA部門も「改善点」を突き止めることができます。それ以外の場合、他の変更と一緒に動作するため、テストせずに本番環境に移行します。
マルジャンヴェネマ

@MarjanVenema:すぐに本番環境にプッシュするつもりだと言ったほうがいいでしょう。変更がprodにプッシュされないことを確信している場合は、変更を行わないでください。OTOHの場合、あなたは不確かですが、変更は簡単に行われ、あなたはすでにそこにいます...変更を行います。追跡とテストについては、「必要に応じてレビューする」でカバーすることを意図していました。
jmoreno

うーん、私が取り組んでいることに直接関係しない限り、変更を行わないことを選ぶと思います。そして、私たちは問題ごとに分岐を持っているので、いつ(どのリリースで)何かが本番に入るかを常に知っています。また、必要に応じて「ただ」レビューするのではなく、変更をテストする必要があると感じています。リスクを構成するものに対する人々の評価は異なり、2番目のペアは決して迷わない。繰り返しになりますが、私は主にサーバー側のコードで作業し、そこでは変更がクライアントに返される結果に微妙に影響する場合があります。クライアント側のコードの変更に対するリスク評価は、おそらくはるかに簡単です。
マルジャンヴェネマ

1

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

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

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


1

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

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

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

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


0

場合によります。

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.