レガシーコードを渡されたときに、独自のコーディングバイアスをどのように克服しますか？
プログラマーとして、私たちはしばしば自分のスキルに信じられないほどのプライドを持ち、「良い」コードと「悪い」コードとは何かについて非常に強い意見を持っています。
私たちのキャリアのどの時点でも、おそらくいくつかのレガシーシステムがラップで落とされ、「私の神、このコードはうんざりです！」完全に機能的で保守可能なコードであったかもしれないという事実にもかかわらず、それは良いコードがどうあるべきかという私たちの考えに適合しなかったからです。
他のプログラマーの仕事に頭を回そうとするとき、あなたはどのように精神的に準備をしていますか？
レガシーコードベースの場合、それを処理するために精神的に準備する正しい方法はそれのユニットテストを書くことから始めるです。
それが悪いかどうかにかかわらず、あなたは最初にものを壊すことなくそれを変えることができるという自信を持つ必要があります！
「ああ、これは完全に間違っている」と何度言ったかを書き直し、そのコードがなぜそのように書かれたのかを正確に知ることはできません。通常、これは明らかではない、記述されていない、または文書化されていない要件です。少なくとも、私が現在取り組んでいるレガシーコードではそうです。
あなたはあなた自身の安っぽいレガシーコードにぶつかるのに十分な時間が経つまで待つ。それは謙虚な体験であり、学習プロセスの一部です。私はすべてを知っている時間を待ち望んでいます。
Foscoは、それを潜在的な時間と機能制限のコンテキストに入れることができるという素晴らしい点を持っていたと思います。時々あなたは何かを働かせることを強いられます。
そして最後に、これがあなたが仕事をしている理由だということを理解してください。
それを笑って、あまり判断しないように一生懸命努力して、ただそれを乗り越えてください。本当のコードナチになるのは良くありません...確かに「十分十分」または「その時点で十分」のようなものがあります。危機を修正するために何かが開発されたり、包帯されたりして、二度と再訪されないことがよくあります。
それが本当に悪いなら、あなたがそれを書き直すための主張をすることができるかどうか確かめてください..それが重要ではないなら、ただ入り込んで出て行ってください。
あなたの戦いを選んでください。 「私はこのように書かない」と「これは深刻な保守またはサポートの課題を生み出す」の違いを知っている
多くの場合、元の開発者が良かったと思っていたものを感じ取るのに役立ちます。
彼らが行ったことに対するパターンとテーマを探してください。多くの場合、そもそも奇妙な決定のいくつかには理由があることがわかります。
元の開発者が実際には悪かったのに、当時彼らがどのような悪さをしていたかがわかる場合があります。
いずれにせよ、これを実行した後、すべてをリファクタリングしなくても、どこから書き直しを開始できるか、またはクイックフィックスがどのようになるかをよりよく理解できるはずです。
最も重要なのは、醜いからといって悪いとすぐに思い込まないことです。何かを近代化するために時間を費やして、それがオリジナルよりも能力が低いことを発見するだけであるということは、あなたを馬鹿げて見せることはありません。
私はいつも醜いコードは多くのデバッグを見たコードであり、大まかな検査では明らかではない多くの微妙な点があると推論します。それを交換したり、大幅に再設計したりする場合は、コードの機能のすべての側面を完全に理解する必要があります。底を打つ時間がない場合は、リスクを最小限に抑えて、目標を達成するために最小限の変更を加える必要があります。
通常、私は小さな修正/変更を行い、後で開発するための機能を提案します。この機能は、物事の根底に到達し、全体をリファクタリングすることを許しません。次に、機能がロードマップに載るまでコードを無視するように最善を尽くします。
レガシーコードが2年以上前のものである場合、そのコードが書かれたときに存在していた言語やオペレーティングシステムなどの制限のために、そのように書かれた可能性があります。ちょっと今は悪く見えますが、それでそれは悪かったですか？私は開発者が彼または彼女がしたことの理由があったと仮定しようとします。その理由はもはや当てはまらないかもしれませんが、一般的な無能の代わりに1つあったと仮定すると（若いプログラマーは5年間であなたのコードについて同じことを考えるかもしれませんが、それよりもさらに少ないでしょう）、怒りが少なくなります。それが機能し、それに関連する問題がない場合は、よりエキサイティングな問題の解決に取り掛かることができるので、どんなに醜いものであっても、そのレガシーコードを大切にしてください。
時間がある場合私はそれを攻撃しますで、不十分に書かれたコードを殺します。
それは戦争です。
将来、コードと必要な修正を所有する準備ができていない限り、触れないでください。書き始める前に十分に研究していなかったために書いていないものを壊したときに修正したいという傾向を克服します。また、それを再び機能させるには、2日とファイアドリルが必要です。 。
誤解しないでください...コードをリファクタリングする正当な理由がありますが、ビジネスでコードが機能することを要求し、ジャンプする前に結果を知らずにコードを「修正」すると、傷ついた世界を求めていることになります。
以前は、他の誰かのコードに腹を立ててそれを「私の」スタイルに打ち負かす時間がなかったとき、私は非常にタスク駆動型であることに頼らざるを得ませんでした。
このコードに追加しようとしていることは何ですか？
私がその目標に向かって取り組んでいることは何ですか？そうでない場合は、やめ、タスク指向の変更を最後に行ったときの状態に戻します。
私はこのタスクを完了しましたか？もしそうなら、たとえそれが非知性的な火星の型によって書かれたように見えても、コードのいじりをやめます。
少しずつリファクタリングすることは便利ですが、その動作が存在する理由と影響を理解しない限り、コードが実際にどのように動作するかを少しだけ変更する場合は特に注意してください。残念ながら、最悪のコードを必要とするコードは、通常は動作を変更せずに変更するのが最も難しい場合がありますが、通常はコードの一部を修正するか、少なくともコメントすることができます。
経験を積むと、コードが本当に悪いのか、それとも別のスタイルで書かれたのかを判断することができます。それが完全に機能的で保守可能である場合そして十分な自動化されたテストカバレッジがある場合、それは悪くはなく、ただ心を開く必要があります。あなたはおそらく何かを学ぶでしょう。不良コードは機能せず、保守もできません。
これは本当に悪いコードのいくつかのマーカーです：
- ロジックの大きなブロックがリファクタリングされる代わりに複製されました。
- クラスまたはパッケージ間の循環依存関係
- 高結合;凝集力が低い
- 未使用の変数、決して読み込まれない変数への書き込み、到達不可能なコード。
- 標準ライブラリ関数の再実装。日付のフォーマット。
- 不必要に複雑なロジック。つまり、50行のコードでは、10行で十分です。
- クラスまたはメソッドの目的を説明するコメントはありません。
- 誤解を招くコメント。
自動テストの欠如は、コードが悪いことを意味するわけではありませんが、プロジェクトが悪いことを意味します。
これらは好みの問題ではありません。これらの慣行により、プログラムのメンテナンスは非常に高価になります。
どのように準備しますか？
新しいコードベースで正常に作業できるようになるにはしばらく時間がかかるという事実を受け入れます。 「完全に保守可能」であり、テストカバレッジが高い場合、所要時間は短くなりますが、すぐには実行されません。コードが悪い場合、私が最初に行うことは、関係者に、コードの状態が悪く、初期の進行が遅くなることを警告することです。それらが懐疑的である場合、私は彼らに実際のコードの問題のサンプルを示し、それが業界のベストプラクティスとどのように異なるかを説明することによって私の主張を裏付けます。
私は最近レガシーコードにほぼ専念して取り組んでおり、いつも「ああ、%%どう思いましたか？」と思っています。 それから私はコードの単体テストの作成を開始しますそして、それが本当に制御フローと依存関係を分析する必要があるポイントです。
単体テストを簡単に作成できない場合があります。しかし、試してみるうちに、コードに関する情報が得られ、コードがそのように記述された理由が理解できます。時にはそれがコードが本当に混乱していることを証明するかもしれません、時には私は元の開発者の思考プロセスを理解し、新しい機能を追加したいときに有用なドキュメントを追加したりコードの一部を書き直したりできます。
私にとって、それは自分のコードは、12か月後に戻ってくると同じように見えますと考えるのに役立ちます。