レガシーコード開発(Development on legacy code)
4922 ワード
詳細
レガシーコード開発(Development on legacy code)
レガシーコード
筆者は開発当初から現在に至るまで、多くのシステムは以前の遺留システムの上に構築されており、最初は遺留システムを直接廃棄することは難しく、特にいくつかの業務論理が非常に複雑な金融電信システムである.これらのコードには、次のような特徴があります.
1.古いプログラミング言語の開発は非効率です.
2.コードが冗長で、品質が悪い.
3.新しい機能の追加とバグ修正(Bugs)のサイクル時間が長くて苦しい.
4.これらのコードはユニットテストがなく、機能テスト、発煙テスト、回帰テストもない.
5.コードを書いている人たちの多くが退職しているため、これらのコードを引き継ぐことができません.
6.これらのコードを維持する代価が高く、みんなは驚いて、特にシステムが特殊な状況(祝日、ピークアクセス期間など)に出会って、落ち着くことができません.
7.しかし、これらのコードは当時の機能を完成することができ、直接これらのコードを捨てることができ、再開発には大きな資源がかかり、必ずしも成功するとは限らない.新しい需要が絶えず変化すれば、これらのコードを再開発する時間がないことが多い.これらの残されたコードの機能には、完全なドキュメントの説明がなく、甚だしきに至ってはありません.この現状では、これらのコードをどのように改善するかは、プログラマーとチームの知恵を試すことになります.
かいはつ
筆者は長年の遺留システムの開発硝煙の中で、多くの苦痛、技術面、政治面などを味わった.しかし、これらの磨きがなければ、何の収穫もありません.くだらないことは言わないで、今私たちがどのようにこれらの残されたシステムを改造するかを見てみましょう.
システムを保持しますか?それとも置換しますか?
1.パフォーマンスのボトルネックが残るシステム:
かつて1つの応用サービスに出会ったことがあって、C言語が書いたので、周囲の他のシステムはすべてJavaを採用して開発して、このシステムとのインタラクションはすべて非標準のプロトコルを採用して完成して、その上このシステムは比較的に核心の位置にあって、しかしメンテナンスはとても複雑で、不安定で、アクセスの圧力はいつもダウンタイムで、レベルの拡張ができなくて、ハードウェアの設備のレベルを高めることしかできませんなどの方式は考慮します.
既存のプロトコルの基礎の上で開発して、それにレベルの拡張能力を持って、代価と1セットの標準プロトコルの実現を開発していかなる違いがなくて、往々にしてプロトコルが完備していないことによる問題を持っています.そこで,新しい標準プロトコル,WS,MQなどを開発し,標準プロトコル上で負荷等化してレベル拡張を実施することが便利である.
その後の発展に伴い、この残留コードも徐々に新開発システムに取って代わられ、期間中に新システムと旧システムが同時に存在することを経験したが、この時、新システムは旧システムのすべての機能を完全に持っていない.この過剰はまあまあ順調だ.
2.機能性改造システム:多くはこのようなシステムで、保留すると、コードと複雑で、メンテナンスが面倒で、捨てると、一夜にして新しいシステムを書くことができません.
コードとドキュメントを含め、开発に失败したプロジェクトを引き継いだことがありますが、やり直すと、结局お得ではありません.その后、このシステムの山で改造を行い、特に多くの时间をかけてユニットテストを书き、コードテストのカバー率が非常に高いことを保证します.このようにコードを熟知しながら、コードを再构筑し、システムの丈夫さが根本的に変わります.前提は时间があります.これは特例にすぎない.
多くの場合、同じテストコードが少なく、新しい機能を追加したり、エラーを修正したりする際に、これらの接触可能なコードのためにテストを改善するには、新しいコードはカバー率を高くテストしなければなりません.4ヶ月後、このシステムのコードカバー率は50%以上に達しました.今後の反復開発はますます速くなる.
以下、この方式の開発過程について説明する.
レガシーコードでプログラミング
コード修正点を探す
残されたシステムコードは、テストが少ないか、ないことが多く、ソフトウェア開発者がソフトウェアのリリースに自信を持っていない.しかし、すべてのレガシーコード書き込みユニットのテストでは、初期コストが非常に高く、小さな機能を追加するときに、大きな干渉をする時間はありません.
どのように切り込み点を探しますか?
新しい変更のために、修正すべきコードがどこにあるかを見つけることができます.以下のいくつかの状況にすぎません.
1.コードを修正すればいい.この时は非常に简単で、コードを修正するのは切り込み点で、この修正を见つけて、ここのコードのために完璧なユニットテストコードを书いて、特に入力条件とテスト条件に対してできるだけ完全なテストをすることができます.
2.複数箇所のコードを修正して、位置が分散して、しかも修正おばさんがもし多種の方案があれば、私達は最も少なくコードを修正する場所を探し出して、最も良い修正方式ではありませんて、多くの時、この時最も良いコードの修正は多くのコードを修正することができて、テストコードが一気に改善することができなくて、また、この時思った最も良い方案は時間の推移に従って、また悪いコードかもしれないので、これ以上苦労する必要はありません.もちろん、中庸な方法を選ぶこともできます.
テクニック
1.テストの便利さを探して、残されたコードを修正するために小さい方法を変更します.
2.1つのクラスで繰り返される方法を再構築し、その頑丈性を保証する.
3.依存する特定のクラスのために新しいインタフェースを抽出し、注入依存技術を使用することで、Mock toolを使用しても、自分でMockオブジェクトを作成しても、テストが容易になります.
たとえば、
次のように変更できます.
DoSomethingにインタフェースアクションを提供し、依存、mockというDoSomethingのようなクラスを採用し、kickOff()メソッドをテストします.
4.できるだけテストの範囲を修正の影響を受けたクラスに縮小し、クラスの変更を全面的にテストする.各箇所が完全なテストを修正することを保証し、テストクラスが減少することを保証します.
5.クラス間の相互作用のコード再構築.これらの相互作用が修正されたコードの中にある場合、修正されたコードが完全にテストされることを保証すればよい.この場合、コードを変更する必要がない他のクラスに影響を及ぼす可能性がある場合は、まず置いて、新しいメソッドを作成し、今回の変更と後で変更するときに、新しいメソッドを使用して再構築することができます.古い方法では、後でコードオーバーライド率が向上し、このようなインタラクティブな方法のコードをすべてオーバーライドできるようになったら、この方法を再構築します.これは、修正が簡単で、修正が間違っていたり、極端な論理を処理できなかったりすると、問題点を見つけやすくなります.
6.業務の論理知識を汲み取るよう努力する.
7.「コードを修正する芸術」(Michael Feathers著)は、切り込み点(Inflection Point)を見つけることを提案しています.多くの場合、私たちが探している点が多く、修正するたびに異なる可能性があります.そのため、多くの代価を払って探すよりも、直接修正に入り、コードの過度な再構築と修正を避け、影響を減らす最適な修正方法を見つけるほうがいいです.これこそ実践的価値と意義がある.
品質保証
要するに、残されたコードと付き合うとき、発表の自信と効率を高めるために、速度と品質が私たちの追求です.
1.できるだけすべてを自動化する:
ユニットテストの自動化は最も基本的な要求であり、できるだけすべてのテストを自動化し、ユニットテスト、機能テスト、圧力テスト、煙テスト、回帰テストにかかわらず.
パブリケーションの自動化も重要です.
2.プロジェクトに発煙テストと回帰テストを加える.コードの品質を徐々に保証します.
3.制御可能な変化を堅持し、徐々に浸透する原則を堅持し、システムが着実に丈夫な方向に進むことを維持する.
推奨される書籍の再構築について:
『再構築:既存コードの設計を改善する』Martine Fowler著
『再構築とモード』:Joshua Kerievsky著
『コード修正の芸術』:Michael Feathers著
参照先:
『コード修正の芸術』:Michael Feathers著
著者:
現在、ある会社の金融ソフトウェアの高級ベテラン技術アーキテクチャ師に就任し、「漫談設計モデル」という本(清華大学出版社)を著している.
レガシーコード開発(Development on legacy code)
レガシーコード
筆者は開発当初から現在に至るまで、多くのシステムは以前の遺留システムの上に構築されており、最初は遺留システムを直接廃棄することは難しく、特にいくつかの業務論理が非常に複雑な金融電信システムである.これらのコードには、次のような特徴があります.
1.古いプログラミング言語の開発は非効率です.
2.コードが冗長で、品質が悪い.
3.新しい機能の追加とバグ修正(Bugs)のサイクル時間が長くて苦しい.
4.これらのコードはユニットテストがなく、機能テスト、発煙テスト、回帰テストもない.
5.コードを書いている人たちの多くが退職しているため、これらのコードを引き継ぐことができません.
6.これらのコードを維持する代価が高く、みんなは驚いて、特にシステムが特殊な状況(祝日、ピークアクセス期間など)に出会って、落ち着くことができません.
7.しかし、これらのコードは当時の機能を完成することができ、直接これらのコードを捨てることができ、再開発には大きな資源がかかり、必ずしも成功するとは限らない.新しい需要が絶えず変化すれば、これらのコードを再開発する時間がないことが多い.これらの残されたコードの機能には、完全なドキュメントの説明がなく、甚だしきに至ってはありません.この現状では、これらのコードをどのように改善するかは、プログラマーとチームの知恵を試すことになります.
かいはつ
筆者は長年の遺留システムの開発硝煙の中で、多くの苦痛、技術面、政治面などを味わった.しかし、これらの磨きがなければ、何の収穫もありません.くだらないことは言わないで、今私たちがどのようにこれらの残されたシステムを改造するかを見てみましょう.
システムを保持しますか?それとも置換しますか?
1.パフォーマンスのボトルネックが残るシステム:
かつて1つの応用サービスに出会ったことがあって、C言語が書いたので、周囲の他のシステムはすべてJavaを採用して開発して、このシステムとのインタラクションはすべて非標準のプロトコルを採用して完成して、その上このシステムは比較的に核心の位置にあって、しかしメンテナンスはとても複雑で、不安定で、アクセスの圧力はいつもダウンタイムで、レベルの拡張ができなくて、ハードウェアの設備のレベルを高めることしかできませんなどの方式は考慮します.
既存のプロトコルの基礎の上で開発して、それにレベルの拡張能力を持って、代価と1セットの標準プロトコルの実現を開発していかなる違いがなくて、往々にしてプロトコルが完備していないことによる問題を持っています.そこで,新しい標準プロトコル,WS,MQなどを開発し,標準プロトコル上で負荷等化してレベル拡張を実施することが便利である.
その後の発展に伴い、この残留コードも徐々に新開発システムに取って代わられ、期間中に新システムと旧システムが同時に存在することを経験したが、この時、新システムは旧システムのすべての機能を完全に持っていない.この過剰はまあまあ順調だ.
2.機能性改造システム:多くはこのようなシステムで、保留すると、コードと複雑で、メンテナンスが面倒で、捨てると、一夜にして新しいシステムを書くことができません.
コードとドキュメントを含め、开発に失败したプロジェクトを引き継いだことがありますが、やり直すと、结局お得ではありません.その后、このシステムの山で改造を行い、特に多くの时间をかけてユニットテストを书き、コードテストのカバー率が非常に高いことを保证します.このようにコードを熟知しながら、コードを再构筑し、システムの丈夫さが根本的に変わります.前提は时间があります.これは特例にすぎない.
多くの場合、同じテストコードが少なく、新しい機能を追加したり、エラーを修正したりする際に、これらの接触可能なコードのためにテストを改善するには、新しいコードはカバー率を高くテストしなければなりません.4ヶ月後、このシステムのコードカバー率は50%以上に達しました.今後の反復開発はますます速くなる.
以下、この方式の開発過程について説明する.
レガシーコードでプログラミング
コード修正点を探す
残されたシステムコードは、テストが少ないか、ないことが多く、ソフトウェア開発者がソフトウェアのリリースに自信を持っていない.しかし、すべてのレガシーコード書き込みユニットのテストでは、初期コストが非常に高く、小さな機能を追加するときに、大きな干渉をする時間はありません.
どのように切り込み点を探しますか?
新しい変更のために、修正すべきコードがどこにあるかを見つけることができます.以下のいくつかの状況にすぎません.
1.コードを修正すればいい.この时は非常に简単で、コードを修正するのは切り込み点で、この修正を见つけて、ここのコードのために完璧なユニットテストコードを书いて、特に入力条件とテスト条件に対してできるだけ完全なテストをすることができます.
2.複数箇所のコードを修正して、位置が分散して、しかも修正おばさんがもし多種の方案があれば、私達は最も少なくコードを修正する場所を探し出して、最も良い修正方式ではありませんて、多くの時、この時最も良いコードの修正は多くのコードを修正することができて、テストコードが一気に改善することができなくて、また、この時思った最も良い方案は時間の推移に従って、また悪いコードかもしれないので、これ以上苦労する必要はありません.もちろん、中庸な方法を選ぶこともできます.
テクニック
1.テストの便利さを探して、残されたコードを修正するために小さい方法を変更します.
2.1つのクラスで繰り返される方法を再構築し、その頑丈性を保証する.
3.依存する特定のクラスのために新しいインタフェースを抽出し、注入依存技術を使用することで、Mock toolを使用しても、自分でMockオブジェクトを作成しても、テストが容易になります.
たとえば、
class Manager{
...
public void kickOff(){
...
DoSomething doSomething = new DoSomething(...);
doSomething.doSomething(objects);
}
...
}次のように変更できます.
class Manager{
...
DoSomething doSomething;
public void setAction(Action doSomething){
this.doSomething = doSomething;
}
public void kickOff(){
...
doSomething.doSomething(objects);
}
...
}
interface Action {
void doSomething(List marks);
}DoSomethingにインタフェースアクションを提供し、依存、mockというDoSomethingのようなクラスを採用し、kickOff()メソッドをテストします.
4.できるだけテストの範囲を修正の影響を受けたクラスに縮小し、クラスの変更を全面的にテストする.各箇所が完全なテストを修正することを保証し、テストクラスが減少することを保証します.
5.クラス間の相互作用のコード再構築.これらの相互作用が修正されたコードの中にある場合、修正されたコードが完全にテストされることを保証すればよい.この場合、コードを変更する必要がない他のクラスに影響を及ぼす可能性がある場合は、まず置いて、新しいメソッドを作成し、今回の変更と後で変更するときに、新しいメソッドを使用して再構築することができます.古い方法では、後でコードオーバーライド率が向上し、このようなインタラクティブな方法のコードをすべてオーバーライドできるようになったら、この方法を再構築します.これは、修正が簡単で、修正が間違っていたり、極端な論理を処理できなかったりすると、問題点を見つけやすくなります.
6.業務の論理知識を汲み取るよう努力する.
7.「コードを修正する芸術」(Michael Feathers著)は、切り込み点(Inflection Point)を見つけることを提案しています.多くの場合、私たちが探している点が多く、修正するたびに異なる可能性があります.そのため、多くの代価を払って探すよりも、直接修正に入り、コードの過度な再構築と修正を避け、影響を減らす最適な修正方法を見つけるほうがいいです.これこそ実践的価値と意義がある.
品質保証
要するに、残されたコードと付き合うとき、発表の自信と効率を高めるために、速度と品質が私たちの追求です.
1.できるだけすべてを自動化する:
ユニットテストの自動化は最も基本的な要求であり、できるだけすべてのテストを自動化し、ユニットテスト、機能テスト、圧力テスト、煙テスト、回帰テストにかかわらず.
パブリケーションの自動化も重要です.
2.プロジェクトに発煙テストと回帰テストを加える.コードの品質を徐々に保証します.
3.制御可能な変化を堅持し、徐々に浸透する原則を堅持し、システムが着実に丈夫な方向に進むことを維持する.
推奨される書籍の再構築について:
『再構築:既存コードの設計を改善する』Martine Fowler著
『再構築とモード』:Joshua Kerievsky著
『コード修正の芸術』:Michael Feathers著
参照先:
『コード修正の芸術』:Michael Feathers著
著者:
現在、ある会社の金融ソフトウェアの高級ベテラン技術アーキテクチャ師に就任し、「漫談設計モデル」という本(清華大学出版社)を著している.