プログラマーとして、仕事で古いプロジェクトを引き継ぐ可能性が高いです。
- あるピットから別のピットにジャンプし、古いプロジェクトを引き継ぎます
- 同僚が水を流していて、彼のすべてのプロジェクトがあなたに引き渡されています
- チームの「コア」メンバーが新しいプロジェクトや主要プロジェクトに取り掛かろうとしており、チームの人的資源が調整され、「コア」メンバーの古いプロジェクトがメンテナンスのためにあなたに引き渡されます。
古いプロジェクトを手にした人は誰でも知っていますが、落とし穴か涙があります。
前任者によって行われた新しいプロジェクトは、パフォーマンスとプロモーションを獲得し、終了時に口を拭き、それをあなたに投げました。
他の人は肉を食べましたが、まだスープはありますか?
スープを飲むことについて話さないでください、あなたはプロジェクトの穴がどこにあるかわかりません。多分いつか問題があり、責任はあなたにあります。
ブラザー、仕事で古いプロジェクトを引き継ぐことは避けられないので、私たちは古いプロジェクトの仕事をどのように行うかを考えなければなりません。
1.古いプロジェクトのパフォーマンスの最適化
古いプロジェクトを行う場合、一般的なアイデアはパフォーマンスを最適化することです。
まず、ブレークスルーに焦点を当て、パフォーマンスが不十分なインターフェイスを見つけて、改善策を提案します。
時間のかかるインターフェースの最適化を過小評価しないでください。これは作業全体のブレークスルーです。
この画期的な進歩により、プロセスをゆっくりとスムーズにし、プロジェクト内の特定のリンクの最適化計画を立てることができます。
インターフェースを最適化しても作品のハイライトが表示されないが、特定のリンクを最適化できれば、これは間違いなくリーダーからの作品のハイライトであると言えます。
これは実際には、量的変化が質的変化を引き起こすという考えです.1つのインターフェース最適化では不十分ですが、いくつかのインターフェース最適化を最適化の特定のリンクにパッケージ化すると、質的変化が生じる可能性があります
2.単一プロジェクトのパフォーマンス最適化に関する一般的なアイデア
2.1馬や兵士を動かさずに先に進む-最初にパフォーマンスモニタリング
製品やその他の川下のビジネスから苦情が聞こえる場合がありますが、それは遅いか何かであり、その後、コードを変更し始めます。
ブラザー、ちょっと待ってください、仕事はそのようなものではありません。
作業を開始する前に、考慮すべき2つの質問があります。何をすべきか。私がこの仕事をし、うまくやったことをどのように証明できますか?
インターフェイスのパフォーマンスを最適化する場合、最初に行うことは、パフォーマンスモニタリングを追加し、データを取り出して、XXの時間のかかるインターフェイスが高すぎることを示すことです。これがあなたの仕事の背景と出発点です。最後に、最適化されたインターフェースと時間のかかるものを取り出します。比較すると、作業の効果がわかります。
2.2SQLの最適化
ほとんどのシステムはキャッシュまたはDBを操作し、パフォーマンス最適化の最初のステップはDBSQLを最適化することです。
一般的なSQL最適化対策:
- 説明後、テーブルにインデックスを追加します
- 結合をキャンセルし、メモリアセンブリに変更します
- 遅い/大きなSQLの分解。たとえば、inクエリに1000個の要素が含まれている場合、SQLステートメントは非常に大きくなり、ログの数行になります。次に、inを複数のinクエリに分割できます。
2.3コードの最適化
一般的なコード最適化対策:
db in forループをチェックインし、クエリでに変更します
for element in list {
// do something
sql query (element)
// do something
}
// 优化后
sql query in (list)
データベースを再帰的にチェックし、必要なデータを見つけたらメモリ構成に変更します
func buildTree(tree) {
if has child:
buildTree(tree)
// 递归里查db
sql query
}
// 优化后
// 先一把查出所需的数据
alldata = sql query
// 内存递归在数据上构建
func buildTree(alldata) {
if has child:
buildTree(alldata)
}
N * 2 N * 3ロジックを避ける
二次および三次時間計算量のコードロジックは避けてください。
- 剪定、計算の範囲を減らします。最初に要件を満たさないデータをクリーンアップします。
- 早く帰れる人は早く帰りますので、降りる必要はありません。
- マップセットなどのデータ構造を使用した時間のスペース
2.42層キャッシュDafa
メモリキャッシュ
ほとんど変更されていないデータの一部はメモリキャッシュに直接配置できるため、アクセス効率が最も高く、redisなどのサードパーティのキャッシュよりも高くなります。
サードパーティのキャッシュ
Redisなど。
大きく変化するデータの場合、メモリキャッシュは各インスタンス内にあるため、メモリキャッシュは使用できません。また、リクエストは特定のインスタンスにロードバランスされることが多く、さまざまなインスタンス間でメモリキャッシュデータの一貫性が失われます。
この時点で、サードパーティのキャッシュを使用する必要があります。