レガシーコードを渡したときに、独自のコーディングバイアスをどのように克服しますか？[閉まっている]

プログラマとして、私たちはしばしばスキルに信じられないほどの誇りを持ち、「良い」コードと「悪い」コードとは何かについて非常に強い意見を持っています。

私たちのキャリアのどの時点でも、おそらくいくつかのレガシーシステムがラップに落ちていて、「このコードはダメだ！」それは、完全に機能的で保守可能なコードである可能性が高いにもかかわらず、優れたコードがどうあるべきかという概念に適合しなかったためです。

他のプログラマーの仕事を回避しようとするとき、どのように精神的に準備しますか？

レガシーコードベースの場合、それを扱うための精神的な準備をする正しい方法は、それに対するユニットテストを書くことから始めることです。

それがひどいものであろうとなかろうと、まずは物を壊すことなく変更できるという自信が必要です！

「ああ、これはまったく間違っている」と何度も言って書き直した後、そのコードがそのように書かれた理由を突き止めました。通常、それはいくつかの非自明な未記述/文書化されていない要件です。少なくとも、私が現在取り組んでいるレガシーコードではそうです。

あなた自身のくだらないレガシーコードに出会うのに十分な長さになるまで待ちます。それは謙虚な経験であり、学習プロセスの一部です。私はすべてを知っていた時間を切望しています。

Foscoには、潜在的な時間と機能の制限のコンテキストに入れることができる大きなポイントがあったと思います。時には何かを働かせる必要があります。

最後に、これがあなたが仕事を持っている理由であることを理解するようになります。

笑って、判断しすぎないように頑張って、それを乗り越えてください。本当のコードナチになるのは良くない...間違いなく、「十分に良い」、あるいは「その時点で十分に良い」というものがあります。危機を解決するために何かが開発されたり包帯で包まれたりして、決して再訪しないことが何度もあります。

それが本当に悪い場合は、書き直しのケースを作成できるかどうかを確認してください。それが重要でない場合は、単に出入りしてください。

戦いを選びます。「このように書かない」と「これは深刻な保守またはサポートの課題を生み出す」との違いを知っている

多くの場合、元の開発者が良かったと感じたことを感じるのは便利だと思います。

パターンやテーマを探してみてください。多くの場合、そもそも奇妙な決定のいくつかの理由があることがわかります。

元の開発者が実際に悪かったと感じることもありますが、当時どのような悪が売れていたのかがわかります。

いずれにせよ、これを行った後、リファクタリングを開始することができる場所、またはすべてをリファクタリングすることなくクイックフィックスがどのように見えるかについて、より良い画像が得られるはずです。

最も重要なことは、それがいからといって、それが悪いとすぐに考えないでください。何かを近代化するために時間を費やすことは、それを見つけるためだけに能力が低いということを、あなたがもっと愚かに見えることはありません。

時間があれば、それを攻撃し、うまく書かれていないコードを殺します。

それは戦争です。

私はいつも、いコードは多くのデバッグを見たコードであり、大雑把な検査では明らかではない多くの微妙な点があると推論します。置き換えたり、深く再設計したりする場合は、コードの機能のあらゆる側面を完全に理解する必要があります。最下位に到達する時間がない場合は、リスクを最小限に抑え、目標を達成するために可能な限り小さな変更を行う必要があります。

通常、私は小さな修正/変更を行い、物事の底に到達して全体をリファクタリングすることを許す、後の開発のための機能を提案します。その後、機能がロードマップに掲載されるまで、コードを無視するように最善を尽くします。

レガシーコードが2年以上前の場合、コードの作成時に存在していた言語やオペレーティングシステムなどの制限のために、そのように作成された可能性があります。おいしそうに見えますが、それで悪かったのですか？私は開発者が彼または彼女がしたことの理由を持っていると仮定しようとします。その理由はもはや当てはまらないかもしれませんが、一般的な無能の代わりに1つがあったと仮定すると（若いプログラマーは5年以内にあなたのコードについて同じことを考えているかもしれません）それが機能し、それに関連する問題がない場合は、よりエキサイティングな問題を解決できるように、どんなにくてもそのレガシーコードを大事にします。

過去に他の人のコードに腹を立てて「自分の」スタイルに打ち勝つ時間がなかったとき、私は非常にタスク駆動型に頼らなければなりませんでした：

このコードに追加しようとしているものは何ですか？

私はその目標に向かって取り組んでいますか？そうでない場合は、それをやめ、タスク指向の変更を行っていた最後の時間に戻ります。

このタスクは完了しましたか？もしそうなら、たとえそれが無感覚な火星のカビによって書かれたように見えても、コードをいじるのをやめてください。

コードと将来必要な修正を所有する準備ができていない限り、触れないでください。書く前に十分に勉強しなかったので、書かなかったものを壊したときに何かを修正したいという傾向を克服します。そして、それを再び機能させるには2日と火ドリルが必要です。

誤解しないでください...コードをリファクタリングする正当な理由がありますが、ビジネスがコードの動作を要求し、ジャンプする前に結果を知らずに「修正」する場合、あなたは傷の世界を求めています。

少しずつリファクタリングすることは有用ですが、その動作が存在する理由とその影響を理解しない限り、コードの実際の動作の小さな側面を変更する場合は特に注意してください。残念なことに、それを最も必要とするコードは、動作に触れずに変更するのが最も難しい場合がありますが、通常はその一部をまっすぐにするか、少なくともコメントすることができます。

私は最近、ほとんど独占的にレガシーコードに取り組んでおり、常に「ああ、彼らは何を考えていたのか」と考えています。。次に、コードの単体テストの作成を開始します。それが、制御フローと依存関係を実際に分析する必要があるポイントです。

ユニットテストを簡単に書くことができない場合があります。しかし、私がしようとしている間に、コードに関する情報を取得し、コードがそのように書かれた理由を理解します。コードが本当に混乱していることを証明することもあれば、元の開発者の思考プロセスを理解し、新しい機能を追加するときに役立つドキュメントを追加したり、コードを書き換えたりすることもあります。

私にとっては、12か月後にコードに戻ったときに、自分のコードが自分にとって同じように見えると考えるのに役立ちます。

経験を積むことで、コードが本当に悪いのはいつか、また別のスタイルで記述されたのはいつかを判断することができます。完全に機能し、保守可能で、自動化されたテストカバレッジが良好であれば、それは悪くなく、心を開くだけです。おそらく何かを学ぶでしょう。悪いコードは機能せず、保守もできません。

本当に悪いコードのいくつかのマーカーは次のとおりです。

• ロジックの大きなブロックは、リファクタリングではなく複製されています。
• クラスまたはパッケージ間の循環依存関係
• 高いカップリング; 低粘着性
• 未使用の変数、読み取られない変数への書き込み、到達不能コード。
• 標準ライブラリ関数の再実装（日付のフォーマットなど）。
• 不必要に複雑なロジック。つまり、10行がうまくいく50行のコードです。
• クラスまたはメソッドの目的を説明するコメントはありません。
• 誤解を招くコメント。

自動化されたテストの欠如は、コードが悪いことを意味しませんが、プロジェクトが悪いことを意味します。

これらは好みの問題ではありません。これらの慣行により、プログラムのメンテナンスがはるかに高価になります。

どのように準備しますか？

新しいコードベースで正常に作業できるようになるまでに時間がかかるという事実を受け入れます。「完全に保守可能」であり、テストのカバレッジが高い場合、時間がかかりませんが、すぐには実行されません。コードが悪い場合、最初にすべきことは、それが悪い形であり、初期の進捗が遅いことを利害関係者に警告することです。それらが懐疑的であれば、実際のコードの問題のサンプルを示し、それが業界のベストプラクティスとどのように異なるかを説明することで、主張をバックアップします。