Java の最適化 - 重いコード、コードをより美しく、簡潔にします。

要するに

プロジェクト作業では、SQL の最適化、プロジェクト構造の最適化、ビジネス層の最適化、コード構造の最適化などの最適化が行われることがよくあります。これらの最適化はすべて、システムの保守、理解、拡張を容易にするためのものです。以下に私の個人的な経験をいくつか紹介します。どのプログラムも頼れるアーキテクトである必要があると感じています。

以前は、もっとビジネスに時間を費やし、機能開発を完了し、セルフテストに合格してからクラスメートをテストするだけでよく、製品が受け入れられればOKだと感じていました。コードの品質を向上させる方法、後続のチームをどのように調整して特定の意識を形成するか、自発的にコードのスケーラビリティを考慮するかコードを作成し、Zhuangxing などをビルドします。

1. コードの最適化は面倒です

なんでそんなこというの？

多くの場合、コードの最適化は、以前のビジネスに基づいて他の人や自分のコードを最適化し、最適化のアイデアを提案することに基づいていますが、現在のコードの読みやすさ、保守性、および設計の方向性があまりフレンドリーではないため、最適化する必要があります。既存のビジネス、コード、またはアーキテクチャに基づいて再構築されました。最適化する前に、既存のコードロジックと以前の設計者またはビジネス開発を理解し、それらを組み合わせてコードを再構築する必要があります。

2. リファクタリングの方法

小規模リファクタリング
はコードの詳細のリファクタリングであり、主にクラス、関数、変数などのコードレベルのリファクタリングが対象です。たとえば、共通の標準化された名前付け (意味が伝わらない変数の名前変更)、大きすぎる関数の削除、重複コードの削除などです。一般に、このタイプの再構築と変更は比較的集中的で、比較的単純で、影響は比較的小さく、時間がかかります。そのため難易度は比較的低く、日常の開発もこのバージョンで十分に行えます。
大規模なリファクタリング
は、システム構造、モジュール構造、コード構造、クラス関係の再構築を含む、コードのトップレベルの再構築です。一般的に採用される手法としては、サービスの階層化、ビジネスのモジュール化、コンポーネント化、コードの抽象化の再利用などが挙げられます。このタイプのリファクタリングでは、原則の再定義、パターンの再定義、さらにはビジネスの再定義が必要になる場合があります。多くのコードの調整や修正を伴うため、影響が比較的大きく、時間がかかり、比較的高いリスク（プロジェクト中断リスク、コードバグリスク、ビジネス脆弱性リスク）を伴います。そのためには大規模プロジェクトの再構築の経験が必要であり、そうしないと間違いを犯しやすく、最終的には利益が損失を上回ります。

実際、他人の「尻拭い」をしたくない人がいないのと同じように、ほとんどの人はリファクタリング作業が好きではありません。

リファクタリングの方法がわからず、リファクタリングの経験や方法論が不足している場合、リファクタリング中に間違いを犯しやすくなります。
短期的なメリットを実感するのは難しいですが、長期的なメリットがあるのであれば、なぜ今努力する必要があるのでしょうか? 長期的には、プロジェクトがこれらのメリットを享受できるようになると、おそらくあなたはこの作業に対する責任を負わなくなるでしょう。
リファクタリングは既存のプログラムを破壊し、予期せぬバグをもたらしますが、こうした予期せぬバグを抱えたくないでしょう。
リファクタリングには、ユーザー側での追加の作業が必要です。また、リファクタリングが必要なコードがユーザーによって記述されていない可能性があることは言うまでもありません。

3. なぜ復興が必要なのか

プログラムには「今日何ができるか」と「明日何ができるか」という 2 つの価値があります。ほとんどの場合、私たちはプログラムに今日実行してもらいたいことだけに集中します。バグの修正であれ、機能の追加であれ、プログラムを強化し、今日の価値を高めることがすべてです。しかし、私が依然として誰もが適切なタイミングでコードのリファクタリングを行うべきだと主張するのはなぜでしょうか? 主な理由は次のとおりです。

ソフトウェアアーキテクチャが常に優れた設計を維持できるようにします。ソフトウェア設計を改善し、ソフトウェアアーキテクチャを良い方向に発展させ、常に安定したサービスを外部に提供できるようにし、予期せぬさまざまな問題に冷静に対処します。
保守性の向上と保守コストの削減は、チームと個人にとって好循環となり、ソフトウェアが理解しやすくなります。将来の世代が先人が書いたコードを読んでも、後から自分のコードを見直しても、ロジック全体をすぐに理解し、ビジネスを明確にし、システムを簡単に保守できます。
研究開発のスピードを上げ、人件費を削減します。システムの立ち上げ時、システムに機能を追加する際、完成スピードは非常に速いことはよく理解していると思いますが、コードの品質を注意しないと追加に1週間以上かかる場合があります。後でシステムに小さな機能を追加します。コードのリファクタリングはコードの品質を確保するための効果的な手段であり、優れた設計はソフトウェア開発速度を維持するための基礎です。リファクタリングはシステムの劣化を防ぎ、設計の品質を向上させることもできるため、ソフトウェアの開発を迅速化するのに役立ちます。

3. リファクタリングの方法

小さなリファクタリング

小さなリファクタリングのほとんどは、日常の開発で実行されます。一般的な参照標準は、開発仕様書とガイドラインです。目的は、コード内の悪臭を解決することです。一般的な臭いを見てみましょう?

if-elseが多すぎる

スケールコード:

if(){
    
    
	if(){
    
    
		if(){
    
    
			} else if(){
    
    
			}
	} else if(){
    
    
	}
} else if(){
    
    
}

それ以外の場合は、3 層を超えないようにすることをお勧めします

for ループには多くのレベルがあり、上記の if else の例と同じです。

重複したコード

プロジェクト内には剰余値が計算される場所が複数あります。関数を通じて結果をカプセル化し、メソッドを均一に呼び出すか、同様のコードスニペットでメソッド呼び出しを均一に抽出することを検討できます。

関数が長すぎます

優れた関数は、単一責任の原則を満たし、短く簡潔で、実行することが 1 つだけである必要があります。過度に長い関数本体やマルチタスクメソッドは、読み取りやコードの再利用に役立ちません。

命名規則

良いネーミングは、「名前にふさわしい、名前から理解できる」、単純で曖昧さのないものである必要があります。

不当なコメント

コメントは両刃の剣です。良いコメントは良い指針を与えてくれますが、悪いコメントは人々を誤解させるだけです。コメントに関しては、コード統合時にコメントも一緒に修正しないとコメントとロジックに齟齬が生じてしまいます。また、コードの意図が明確に表現されている場合、コメントは冗長になります。

役に立たないコード

役に立たないコードを使用する方法は 2 つあります。1 つは使用シナリオがないことです。このタイプのコードがツールメソッドやツールクラスではなく、役に立たないビジネスコードである場合は、適時に削除してクリーンアップする必要があります。もう 1 つはコメントで囲まれたコードブロックであり、コメントが付いている場合はこれらのコードを削除する必要があります。

大きすぎるクラス

クラスがあまりにも多くのことを実行し、あまりにも多くの関数を維持すると、可読性が低下し、パフォーマンスも低下します。たとえば、注文関連の関数をクラス A に配置し、商品在庫関連の関数もクラス A に配置し、ポイント関連の関数もクラス A に配置します。想像してください。ごちゃごちゃしたコードブロックがすべて配置されます。 1 クラスです。くそー、読みやすさについて話しましょう。コードは、単一の責任に従って異なるクラスに分割する必要があります。

これらは、比較的一般的なコードの「嫌な匂い」です。もちろん、実際の開発には、わかりにくいコード、わかりにくいロジック、複雑なクラス関係など、他の「嫌な匂い」もあります。これらのさまざまな「嫌な匂い」を嗅いだときは、次のことを試してみるべきです。ただ放置するのではなく解決するために。

大規模なリファクタリング

大規模リファクタリングは小規模リファクタリングに比べて考慮すべき事項が多く、状況が変わりやすいため、リズムを決めて段階的に実行する必要があります。

ゾウを冷蔵庫に入れる手順は、大きく 3 つのステップに分けることができます: 1) 冷蔵庫のドアを開ける (イベント前)、2) ゾウを押し込む (イベント中)、3) 冷蔵庫のドアを閉める (イベント終了後)。イベント）。日常的なことはすべて 3 段階のアプローチを使用して解決でき、リファクタリングも例外ではありません。
ここに画像の説明を挿入します

事前

準備はリファクタリングの最初のステップです。この部分に関係することは比較的複雑であり、最も重要でもあります。事前の準備が十分でない場合、実行中またはリファクタリングの開始後に生成される結果が不完全になる可能性が非常に高くなります。期待と一致しない現象。

この段階は大きく 3 つのステップに分けることができます。

復興の内容、目的、方向性、目標を
明確にするこのステップで最も重要なことは、方向性を明確にすることであり、この方向性は誰もが疑問に思うことに耐えることができ、少なくとも今後3年から5年の方向性を満足させることができます。もう一つは、今回の再構築の目標ですが、技術的な限界や歴史的な重荷などの理由により、この目標が最終目標ではない可能性があります。その場合、最終目標が何なのかを明確にする必要があります。この再構築の目標から最終的な目標まで、何をする必要があるのかを明確にすることが最善です。
データを整理する
ステップでは、再構築部分に関係する既存のビジネスとアーキテクチャを整理し、再構築されたコンテンツがシステムのどのサービスレベルに属するか、どのビジネスモジュールに属するか、依存者と依存者が誰であるかを明確にする必要があります。どのようなビジネスシーンがあるのか、それぞれの場面でのデータの入出力は何なのか？この段階では出力が得られます。これには通常、プロジェクトのデプロイメント、ビジネスアーキテクチャ、技術アーキテクチャ、サービスの上流と下流の依存関係、強い依存関係と弱い依存関係、プロジェクトの内部サービス階層化モデル、コンテンツと機能の依存関係モデル、入出力データフローが含まれます。、など設計図や文書。
プロジェクトの立ち上げ
プロジェクトの立ち上げは、復興に関わるすべての部署やグループに復興事業の概要を説明し、おおよそのスケジュール（おおよその時間）を把握し、各グループの主な責任者を明確にするなど、会議を通じて行うのが一般的です。さらに、リファクタリングにはどのような業務やシナリオが関係するのか、おおよそのリファクタリング方法、ビジネスへの影響、困難さ、ボトルネックが発生する可能性のある手順などを把握しておく必要があります。

進行中

このステップの実行に関連するタスクは比較的困難であり、比較的長い時間がかかります。

アーキテクチャ設計とレビュー
アーキテクチャ設計レビューには、主に標準的なビジネスアーキテクチャ、技術アーキテクチャ、およびデータアーキテクチャの設計とレビューが含まれます。レビューを通じてアーキテクチャ上およびビジネス上の問題を発見します。このレビューは通常、チーム内でのレビューです。レビュー後にアーキテクチャ設計を決定できないことが判明した場合は、チームがソリューションアーキテクチャについて合意に達するまで調整を行う必要があります。また、審査通過後は審査結果を参加者にメールで通知する必要があります。

この段階の出力: 再構築されたサービス展開、システムアーキテクチャ、ビジネスアーキテクチャ、標準データフロー、サービス階層化モデル、機能モジュール UML 図など。

詳細な実装設計計画とレビュー
: この実装設計計画は実装において最も重要な計画であり、後続の R&D コーディング、セルフテストと共同デバッグ、依存当事者のドッキング、QA テスト、オフラインリリースと実装計画、およびオンラインリリースおよび実装計画、具体的な作業負荷、難易度、作業のボトルネックなど。この詳細な実装計画は、研究開発全体、オフラインテスト、オンラインプロセス、および AB グレースケールプログラムや AB 検証プログラムを含むグレースケールシーンの詳細にまで踏み込む必要があります。

ソリューション設計で最も重要な部分は、再構築が完了したかどうかを評価およびテストするための標準的な基盤である AB 検証プログラムと AB 検証スイッチです。一般的な AB 検証手順は大まかに次のとおりです。
ここに画像の説明を挿入します

データ入口では、同じデータを使用して、新しいプロセスと古いプロセスの両方に対する処理リクエストを開始します。処理が完了すると、処理結果がそれぞれログに出力されます。最後に、オフラインプログラムを使用して、新しいプロセスと古いプロセスの結果が一致しているかどうかを比較します。従うべき原則は、同じ入力パラメーターを使用すると、応答結果も一貫している必要があるということです。

AB プログラムでは、2 つのスイッチが関係します。グレースケールスイッチ(オンの場合のみ、リクエストはコード実行のために新しいプロセスに送信されます)。実行スイッチ(新しいプロセスに書き込み操作が含まれる場合、新しいプロセスで書き込むか古いプロセスで書き込むかを制御するスイッチを使用する必要があります)。転送する前に、グレースケールスイッチと実行スイッチ (通常は構成センターで構成され、いつでも調整できます) をスレッドコンテキストに書き込む必要があります。これは、構成センタースイッチを変更するときに不一致な結果が生じるのを避けるためです。

コードの作成、テスト、オフライン実装
このステップでは、詳細な設計計画に従って、コーディング、単体テスト、共同デバッグ、機能テスト、ビジネステスト、QA テストを実行します。合格後、オンラインプロセスとオンラインスイッチ実装プロセスをオフラインでシミュレートし、AB プログラムを検証し、期待を満たしているかどうか、および新しいプロセスのコードカバレッジがオンライン要件を満たしているかどうかを確認します。オフラインデータサンプルが比較的少なく、すべてのシナリオをカバーできない場合は、すべてのシナリオが期待を満たすことができるように、すべてのシナリオをカバーするトラフィックを構築する必要があります。オフラインのカバレージが期待に達し、AB 検証プログラムが異常を検出しなければ、オンライン操作を実行できます。

その後

この段階は、オフラインシミュレーションの実装プロセスに従ってオンラインで実装する必要があります。オフラインシミュレーションは、オンライン、大規模、修復、オフラインの古いロジック、レビューのいくつかの段階に分かれています。最も重要でエネルギーを消費するのは容積測定プロセスです。

階調切り替え処理は、
観察用の新しい処理に段階的に拡張され、1%、5%、10%、20%、40%、80%、100%と進行に応じてボリュームを増加させることができるため、新しい観察処理が可能になります。プロセスは徐々にコードロジックをカバーできますが、この段階では実際に書き込み操作を実行するためのスイッチがオンになるわけではないことに注意してください。新しいプロセスのロジックカバレッジが要件に達し、AB 検証の結果が期待どおりであれば、書き込み操作のスイッチを徐々にオンにして実際の業務を実行できます。
業務実行スイッチプロセスが
新しいグレースケールプロセスで期待を満たした後、業務実行書き込み操作スイッチプロセスを徐々にオンにすることができ、ボリュームは一定の比率に従って徐々に増加することができます。書き込み操作がオンになった後のみ、新しいロジックは書き込み操作を実行し、古いロジックの書き込み操作は終了します。この段階では、オンラインエラー、インジケーターの異常、ユーザーフィードバック、その他の問題を観察して、新しいプロセスに問題がないことを確認する必要があります。

大規模な作業が完了し、一定のバージョンが安定したら、古いロジックとAB検証プログラムをオフラインにして再構築作業が完了します。可能であれば、再建検討会議を開催して、各参加者が再建に必要な基準を満たしているかどうかを確認し、再建中に遭遇した問題とその解決策を検討し、その後の問題を回避するために沈殿法を使用することができます。仕事。

要約する

コーディングスキル

コードを記述するときは、特定の実装に依存するのではなくインターフェイス/抽象化に依存する単一原則など、いくつかの基本原則に従ってください。
コーディング標準に厳密に従って、特別なコメントには TODO、FIXME、および XXX を使用してください。
単体テスト、機能テスト、インターフェイステスト、および統合テストは、コードを記述するために不可欠なツールです。
私たちはコードの作成者であり、将来の世代はコードの読者です。コードを書くときは常にコードを見直し、先人が将来の世代が楽しめるように木を植えたことを行うべきであり、先人が将来の世代が埋められるように穴を掘ったようなことをしてはなりません。
あなたが割れ窓効果を最初に回避できる人なら、コードはすでに悪いものであり、もう変更する必要はないと考えず、コードを積み上げ続けてください。そうなると、いつか他人のコードに嫌悪感を抱き、「遅かれ早かれ返済しなければならない日が来る」でしょう。

リファクタリングスキル

上から下、外側から内側までをモデル化して分析し、さまざまな関係を明らかにすることが再構築の最優先事項です。
クラスを改良し、関数を再利用し、コア機能に焦点を当ててモジュールの責任を明確にします。
抽象化への依存よりインタフェースへの依存、実装への依存より抽象化への依存の方が良く、クラスの関係を結合できる場合は継承する必要はありません。
クラス、インターフェイス、および抽象インターフェイスを設計するときは、スコープ修飾子、どの修飾子が書き換え可能で、どの修飾子が書き換えられないのか、および汎用修飾子が正確であるかどうかを考慮してください。
大規模リファクタリングに向けた各種設計・計画を立て、さまざまなシナリオをオフラインでシミュレーション、オンライン化にはAB検証手続きが必要で、いつでも新旧切り替え可能。