レガシーソフトウェアを理解してデバッグする方法
可能性のある複製：
20万行のスパゲッティコードを継承しました—今はどうなりますか？
少し前まで、私の会社では、運用中の最も複雑なバグのいくつかに対処するチームに私を配置しました。問題は、これらのバグのほとんどすべてがレガシーアプリケーションにあり、理解とデバッグが非常に困難なことです。これらの理由のいくつかは次のとおりです。
悪いソフトウェア設計
たくさんのコードの重複
誤解を招くコメント
悪い名前
まったくドキュメントなし
ソフトウェアの作成者は会社で働いていません
本当に大きなクラスとメソッド、非常にひどくプログラムされた
バグは非常に不適切に文書化されており、運用チームは発生した問題について非常に不十分に文書化されたレポートを作成します。
それは非常に時間がかかり、イライラします。 TDDとATDDの開発者として、私は問題を三角測量して特定するためのテストを作成することから始めますが、モックする必要があることが非常に多く、非常に困難です。また、ビジネスアナリストは自分自身も知らないため、このソフトウェアの基準を提供していません。彼らが言う唯一のことはそれが修正される必要があるということです。
このような環境でバグに対処する方法についてのアドバイスをくれるレガシーソフトウェアの経験を持つ誰かをここで見つけることができるかもしれないと私は思った。これを使っているとき、私は software archeology をしているように感じます。また、非常にストレスが多く、バグを修正するのに数週間かかることもあるので、この大きなフラストレーションは私を役に立たなく非生産的に感じさせます。私はいつもグリーンフィールド開発に携わっていましたが、これが初めての制作サポートです。アドバイスをいただければ幸いです。
あなたは頭に釘を打ちました-あなたが不満を言っているのは「レガシーソフトウェア」の定義です。このクラスのソフトウェアで作業するには、グリーンフィールド作業とは異なる考え方が必要です。あなたのストレスはあなたが非現実的な対策に対してあなたの進歩を測定した結果です。
今日のイデオロギーを昨日の仕事にかけようとしないでください。 TDDとUTを中心に設計されていない場合、レトロフィットによるテスト主導の方法論は、大規模で高価で困難な作業です。あなたが見つけているように-今日の銀の弾丸を昨日失敗したものに靴磨きすることは、働くのに理想的な方法とはほど遠いです。目標と利点を明確に理解していれば、慎重に検討しても、価値はあります。ただし、それはすぐにマイナスのリターンに発展します。 「ぶら下がっている果物」を選び、何度も使用され、多くの欠陥が見つかる場合に限り、テストを開発してください。
最善のアプローチは、非現実的な期待を取り除くことです。生産性は低く、コードの分析は困難であり、障害は修正が困難です。変更の予期しない副作用が発生する可能性が高く、ご存じのように、存在しない回帰テストのレガシーコードの維持は遅くて難しいため、多くの開発者がGreen Fieldsプロジェクトを実行しています。私はやりがいがありますが、あなたがあなたの期待をリセットした場合のみです。
欠陥に取り掛かるときは、まず3つのことに焦点を合わせ続けることから始めます。コードが今何をしているか、予期しない副作用を引き起こさないこと、および修正されたときに何をすべきか。 「コードの重複」が「予期しない副作用」よりも優れていることに気付くかもしれません...適切なテストと要件がない場合、回帰の導入は多くの場合、最大の罪です。
常にコードを見つけた状態よりも良い状態に保つように努めますが、必要な場合を除いてコードの動作を変更しないように注意してください。
これは常に、私が参加するユーザーグループや会議で頻繁に議論される領域です。私が今まで聞いた中で最高のアドバイスはこれです：
新しい、十分にテストされたコードの場合、テストはすべての真実の源です。テストされていないレガシーコードの場合、コードベースはすべての真実の源です。新しい機能を追加するときは、確実な単体テストを作成してください。既存のモジュールに対処するとき、または欠陥を修正するときは、できる限りテストして、リグレッションを回避してください。時間をかけて、落ち着いて、続けてください。
これは明らかにいくつかの見事な見方の言い換えですが、核心はこれです。コードベースは明らかに「壊れています」が、機能は壊れておらず、それがユーザーの関心事です。しかし、完全に保守できなくなり、機能を迅速かつ正常に再実装する方法について考えている場合は、恐ろしい「大きな書き換え」の可能性を持ち出す時がきたかもしれません。
私はキャンプにいることを認めますが、そうなるまで、大きな書き換えは決して良い考えではありません。あなた、あなたのチーム、そしてあなたの顧客は、その時が来たかどうか、いつ来るかについて話し合い、交渉する必要があります。幸運なことに、正しい解決策が1つもない恐ろしい状況です。知っておくべきです、私は数回前にそこに行ったことがあります。
これは遅い仕事です。我慢して。あなたの同僚は、おそらく利用可能な情報の最高の情報源です。知識を得たら、コメントを追加して、次の人があなたがすでに知っていることを再学習する必要がないようにします。
この仕事はそれほど面白くなく、キャリアを前進させるのにあまり役立たないので、あなたはもっと支払われるべきですあなたが新しい開発のために得るよりも=。私はおそらくこのタイプの仕事をサラリーマンとしては受けないでしょう。確実に発生する多くの「緊急事態」の残業代を含めた契約者料金を取得したいと思います。
他の人のコードを読んで理解する方法を学ぶことは、プログラマーであることの大きな部分です。あなたが読むコードのいくつかはあなた自身のものです。コードが全体にどのように適合するかを完全に理解していない場合、コードを変更するのは危険です。ユニットテストを導入し、なんらかの自動ビルドシステムの一部として実行することで、それらがカバーするコードが動作を変更しないようにすることができますが、これは（特にレガシーコードの場合）、変更するコードの使用方法を理解する必要があることを意味しますシステムによって。
複雑すぎると思われるコード（または意味が何であれ、無造作）を破棄して、自分で書き直すのは魅力的です。 （誰もが建築家になりたいと思っています）。古いコードを破棄してゼロから書き直す場合の危険は、時間とハードな経験によって得られた知識も捨ててしまうことです。同じ間違いを繰り返し、元の開発者が行ったのと同じバグを修正しない限り、通常は取り戻すことは困難です。時間。
レガシーシステムに（またはその上に）TDDを導入するのは難しい場合があります。これらのテストでバグを修正する準備をしてください。コード自体に矛盾が必ず見つかるからです。テストは完全ではないことを忘れないでください。既存のシステムをよりよく理解するようになると、それらを改善/修正する必要があります。
あなたが説明したのと同様の状況で作業しているときに私が非常に便利であると思ったアプローチがあります。通常レガシーコードは、非常にモノリシックであいまいな方法で記述されています。しかし、レガシーコードで作業を開始する興味深いアプローチがあります： 承認テスト 。 ゴールデンコピー の記録から始めて、取得した情報にビジネスにとって意味のある値が含まれていることを確認することをお勧めします。次のステップでは、ゴールデンコピーをビジネスアナリストに示します。通常、それはこの表現を理解するだけでなく、それらの数値のどこが間違っているかを教えてくれます。これで、プログラム実行の現在の結果とアナリストによるコメントの両方が得られたので、レガシーコードの安全なリファクタリングとバグ修正を開始できます。