概要： 先祖代々のコードがあるとよく聞かれます。つまり、いくつかのプロジェクトは長期間維持されており、多くの人々の手によってビジネスロジックがどんどん積み上げられて、維持することがますます難しくなっています。 。
数か月前、私の同僚たちは去り、ノードによってサポートされるマスター/スレーブ構造を持つ分散タスクスケジューリングシステムを残しました。
- 運用と展開の観点から見ると、現在の状況は複数のリリースバージョンであり、バージョンが依存するノードは異なり、展開にはいくつかの依存ファイルの手動コピーが必要です。
- コード構造の観点から見ると、維持する必要のあるメインバージョンはjs構文で記述され、多くの場合、大量のビジネスロジックが1つのファイルに積み上げられます。
現在の問題を分析し、私が検討したいくつかの最適化ソリューションを分析する例としてSlaverを取り上げましょう
まず、どのモジュールと関数がSlaverセクションに含まれているか見てみましょう：
1.マスターとのメッセージ要求と応答が含まれます。
2.サブタスクのステートマシンが含まれています。
3.さまざまなタスクの処理の詳細が含まれています。
構文とパフォーマンスの観点から：
- それらのほとんどは、パラメーターとしてオブジェクト型と可変長パラメーターを使用します。
- 同じファイルには、多数のエンティティの定義と構築、エンティティオブジェクトの定義ではなくObjectの過度の使用が含まれます。これには、多くの暗黙的な型変換と長い要素参照が含まれます。
- 同期という形でのio操作が多く、ファイル操作が多すぎる。
- エラーの印刷のみが散らばっており、集中的なエラー定義はありません。
- 変数の命名規則はありません。ローカルとグローバルを区別することは不可能であり、名前が繰り返し使用されるため、理解が難しくなります。
- 変数定義が散在し、分散され、グローバルスコープ内の関数呼び出しが散在し、多くの場所に散在している
- ネストされたマルチレベルのtry ... catchステートメント
- 連続サイクルのタスク設計はサーバーリソースの浪費を引き起こす
- 関数の多くの場所で絶対パスが使用されているため、移行と移植性が低下します
最適化計画に関する考慮事項：
- js => Ts、typescript文法を使用してコード構造を再編成します（この計画の事前の同僚がバージョンを開発しました。アップグレードの調整範囲が少し大きいため、実際には、ラインの後にさらに機能上の問題があり、バージョンは一時的に保留されます）
- js => java、javaを使用して関連ロジックを再開発します（より多くのビジネスコードロジック、より多くのワークロード）;
- js言語を変更せずにリファクタリングし、元のコードを分割します。
jsと比較すると、typescript / javaはより強力な型と構文設計を備えており、オブジェクト指向のソフトウェア設計を使いやすくなっています。
しかし、jsを使用してバックエンドコードを開発するのは悪い選択でしょうか、それとも、より多くの設計と仕様の遵守が必要です。
トピックは別として、古いシステムがうまく動いていれば、それに基づいて大規模な二次開発を行う必要はありません投資コストの観点からは、この種のプロジェクトをリファクタリングする必要はないと思います。
リファクタリングとデカップリングは、ソフトウェア開発における最も長いトピックです。
つづく...
参照文書：
