私が新人の頃、方向性を教えてくれたり、落とし穴の経験を共有してくれる先輩がいれば、遠回りすることがなくなり、学習コストも節約できるかもしれません。
この記事では、私の長年の実務経験に基づいて、新人向けにいくつかの提案をまとめました。お役に立てば幸いです。
メモを書く
- コメントのないコードは保守が容易ではありません。
- 適切なコメントを書く必要がありますが、冗長すぎないように、キーまたはコア コードにコメントを追加する必要があります。特定のメソッドが何を行うのか、主なステップは何か、アルゴリズムのデモ例を書くなどを行うことができます。
- こうすることで、時間が経ってからもう一度このコードを見たときに、簡単に始めることができます。
単体テスト
- たとえば、新しい Util ツール クラスが作成される場合、そのツール クラスのいくつかの単体テスト コードがテスト ディレクトリに同時に書き込まれます。
- 多くの友人は、単体テストを書くのは時間の無駄であり、その必要はないと考えています。
- より多くの単体テストを作成することは開発にとって非常に良い習慣であり、コードの品質の向上に役立ちます。
- 最初は開発時間が比較的タイトで単体テストを作成する時間がなかったとしても、後で空いた時間に単体テストを追加することをお勧めします。
SQL実行計画
- クエリ SQL ステートメントを作成した後、Explain キーワードを使用して SQL ステートメントにインデックスが作成されているかどうかを確認する習慣が付いています。
- 比較的大量のデータを含むテーブルの場合、SQL ステートメントの実行時間はインデックスの有無で数百倍も異なる場合があります。
- したがって、Explain を使用して SQL ステートメントの実行計画を表示し、SQL の最適化時に速度が低下する具体的な理由を見つけて、対応する最適化計画を提示することをお勧めします。
- 参照: https://blog.csdn.net/u010800804/article/details/109594810
オンラインでチェックリストを整理する
- システムをオンラインにする前に、オンライン リスト (いわゆるチェックリスト) を整理する必要があります。
- システムの立ち上げは非常に複雑な問題であり、多くのことが関係する可能性があります。
- サービス A がサービス B に依存し、サービス B がサービス C に依存するとします。この場合、サービスのリリース順序は CBA になります。順序を間違えると問題が発生する可能性があります。
- 新しい関数を起動するときに、事前に SQL スクリプトを実行してデータを初期化する必要がある場合があります。そうしないと、新しい関数で問題が発生します。
- たとえば、オンラインにする前に、関連する構成を構成センターとタスク スケジューリング センターで実行する必要があります。そうしないと、プロジェクトが異常に開始される可能性があります。
- オンラインになったら、対応するメニューを追加して、指定したユーザーまたはロールに権限を割り当てる必要があります。
- システムがオンラインになると、プロセス全体に多くのことが関係する可能性があるため、それらをチェックリストに記録し、漏れがないようにする必要があります。
インターフェイスのドキュメント
- インターフェイスのドキュメントは、インターフェイスのプロバイダーとインターフェイスの呼び出し元にとって非常に重要です。
- インターフェイス ドキュメントがない場合、インターフェイスのアドレス、インターフェイス パラメーター、リクエスト メソッド、複数のインターフェイス パラメーターのコードの意味、戻り値のフィールドを他の人がどうやって知ることができるでしょうか。 、 等々。
- 相手が知らない場合は必ず何度も質問することになり、目に見えないコミュニケーションコストが増加します。
- インターフェースのドキュメントの書き方が悪く、他の人が理解できないように書かれている場合、入力パラメータの列挙値が実際の状況と異なるなど、インターフェースのドキュメントに多くの誤りが存在します。
- インターフェイス ドキュメントは、主にフロントエンドとの共同デバッグに使用される内部インターフェイス ドキュメントにも分類されます。1 つは openapi インターフェイス ドキュメントで、他のインターフェイスに提供されるインターフェイスは開発および自己テストする必要があり、フロントエンドは直接行うことはできません。インターフェースを呼び出すときにエラーを報告してください。不正行為をすると、他の人を不幸にすることになります。
- したがって、インターフェース文書の作成は適切に作成する必要があり、不注意に用事を処理してはなりません。
事前の事業評価リクエスト
- インターフェースを設計する際には、ビジネス側やプロダクトマネージャーにリクエスト量を確認する必要があります。
- たとえば、頻繁に呼び出されるインターフェイスをキャッシュするかデータベースに直接クエリするか、特定のサービスをロックするかどうかなどです。
- インターフェイスが 100qps にしか耐えられないが、実際には 1000qps を生成するとします。
- このように、インターフェイスはそのような大きな圧力に耐えることができず、直接ハングアップする可能性があります。
- さらに、他のユーザーが悪意を持ってインターフェイスを呼び出すことを防ぐために、インターフェイスのフローを制限する必要があります。これにより、サーバーに過剰な負荷がかかります。
- 電流制限の場合、ユーザー ID、IP アドレス、インターフェイス アドレスなどの複数の次元に同時に基づいて制限することができます。
- 電流制限は、nginx 層またはゲートウェイ層で行うことができます。
インターフェースの冪等設計
- インターフェイスを設計するときは、同時呼び出しの状況を考慮する必要があります。
- たとえば、ユーザーがフロントエンド ページで保存ボタンを非常に素早く 2 回クリックすると、非常に短い時間内にインターフェイスが 2 回呼び出されます。
- 冪等設計を行っていない場合、データベース内に重複したデータが２つ生成される場合があります。
- 別のケースでは、ビジネス側がユーザー側のインターフェイスを呼び出すと、インターフェイスがタイムアウトになり、自動再試行メカニズムが備わっているため、ユーザー側でデータの重複が発生する可能性があります。
- そのため、開発段階では実際のビジネスシナリオに基づいた冪等設計や制限を行っておりますが、インターフェースの同時実行数がそれほど大きくない場合には、よりシンプルなテーブルに一意のインデックスを追加するソリューションを使用することをお勧めします。
インターフェイスパラメータの慎重な調整
- 私たちが提供するインターフェイスでは、パラメーターを調整する必要がある場合があります。
- たとえば、新しいパラメータが追加されるか、パラメータのタイプが int から String に変更され、パラメータ名が status から AuditStatus に変更され、パラメータが単一の ID から idList のバッチに変更されます。
- インターフェイスパラメータを変更するときは注意することをお勧めします。
- インターフェースのパラメータを変更する場合は、必ず呼び出し元と影響範囲を評価し、こっそり変更しないでください。何か問題が発生した場合、後で発信者は間違いなく頑張らなければなりません。
- インターフェースのパラメータを調整するときは、互換性を考慮する必要があります。
- パラメータ名を変更する場合、データを受信する新しいパラメータを追加できますが、古いデータは引き続き保持され、コードには互換性があります。
本番環境、データバックアップ
- オンラインデータに問題が発生し、データを修復する必要がある場合がありますが、データ量が多すぎます。
- このとき、オンラインデータを処理する前にデータをバックアップすることをお勧めします。
insert into member_20230806 select * from member
- データをバックアップした後、1 日後にデータが誤って処理された場合でも、バックアップ テーブルから直接データを復元して悲劇を防ぐことができます。
フィールドのタイプと長さを適切に設定する
- テーブルを設計するときは、関連するフィールドに適切なフィールド タイプと長さを設定する必要があります。
- フィールドの種類と長さが不十分な場合、一部のデータが保存されない可能性があります。
- 次の原則を参照できます。
できるだけ少ないストレージスペースを占めるフィールドタイプを選択し、通常のビジネスニーズに合わせて小規模から大規模まで選択してください。
文字列の長さが固定されている場合、またはその差が大きくない場合は、char 型を選択できます。文字列の長さが大きく異なる場合は、varchar 型を選択できます。
フィールドかどうかにかかわらず、ビット タイプを選択できます。
列挙フィールドでは、tinyint 型を選択できます。
主キーフィールドはbigint型を選択できます。
金額フィールドでは、小数タイプを選択できます。
時刻フィールドでは、タイムスタンプまたは日時タイプを選択できます。
一度に大量のデータをクエリしないようにする
- インターフェイスを設計したり、他の人のインターフェイスを呼び出したりするときは、一度に大量のデータをクエリすることを避けなければなりません。
- 一度に大量のデータをクエリすると、クエリに時間がかかる可能性があり、さらに深刻な場合はシステムで OOM 問題が発生することがあります。
- Excel エクスポートを実行するときに、すべてのデータを一度にクエリして Excel ファイルにエクスポートすると、システムで OOM 問題が発生する可能性があります。
- サードパーティのバッチ クエリ インターフェイスの呼び出しに特定のパフォーマンス要件がある場合は、バッチ処理後に複数のスレッドでインターフェイスを呼び出し、最後に返されたデータを要約することができます。
ビジネス上の問題
- 多くの場合、データベース内の複数のテーブルに格納されているデータの整合性と一貫性を確保するために、コードでは @Transactional アノテーションが付けられた宣言型トランザクション、または TransactionTemplate を使用したプログラム トランザクションを使用する必要があります。
- トランザクションに参加した後、3 つのテーブル A、B、C が同時にデータを保存すると、それらは一緒に成功するか、一緒に失敗します。
- たとえば、テーブル A は正常に保存されたが、テーブル B と C は保存に失敗したなど、データの半分が保存される状況は発生しません。
- この場合、データは直接ロールバックされ、3 つのテーブル A、B、C のデータは同時に保存されません。
- さらに、トランザクションの導入により、大規模なトランザクションの問題が発生し、インターフェイスのタイムアウトやデータベースのデッドロックの問題が発生する可能性があります。
- したがって、大規模なトランザクションには多くの危険があるため、コードを最適化し、大規模なトランザクションの問題を回避する必要があります。
一括操作を使用することを好む
- for ループでは、リモート インターフェイスを 1 つずつ呼び出すか、データベースの更新操作を実行します。
- ループ内で何度も実行されている単一の操作をバッチ操作に変更しようとします。これにより、コードのパフォーマンスが大幅に向上します。
for(User user : userList) {
userMapper.update(user);
}
userMapper.updateForBatch(userList);
同期の問題
- 面接中、面接官から同期ロックされた試験の質問についてよく質問されます。
- しかし、実際の業務において同期ロックを使用する機会はそれほど多くありません。
- 同期はスタンドアロン環境に適しており、複数のスレッドがサーバー ノード上の共通リソースにアクセスするときに、1 つのスレッドだけがロックを取得でき、他のスレッドは待機する必要があります。
- しかし実際には、私たちのシステムのほとんどは分散環境にあります。
- サービスの安定性を確保するために、通常、システムを 3 つ以上のサーバー ノードにデプロイします。
- 1 日後、サーバー ノードがダウンしても、システムは別のサーバー ノードでも正常に実行できるようになります。
- このとき、同期ロックを使用すると問題も発生します。
- したがって、作業ではより多くの分散ロックが使用されます。
データベースの悲観的ロック。
タイムスタンプまたはバージョン番号に基づく楽観的ロック。
Redis 分散ロックを使用します。
Zookeeper の分散ロックを使用します。
非同期思考
- インターフェイスのパフォーマンスの最適化が行われており、非常に重要な最適化方法の 1 つは非同期です。
- データ節約 API インターフェイスのビジネス ロジックが非常に複雑な場合、タイムアウトの問題が頻繁に発生します。
- まずはインデックス作成と SQL ステートメントの最適化から始めます。
- インターフェイスのリアルタイム要件が高くない場合は、テーブルを使用してユーザー データを保存し、ジョブまたは MQ を使用するこの非同期方法でテーブルのデータを読み取り、ビジネス ロジック処理を実行できます。
- 非コア ロジックの場合は、job または mq を使用して非同期に処理できます。
Git にはコードを送信する良い習慣が必要です
- Git でコードを送信する良い習慣は、複数回送信することです。
- 一度に大量のコードをコミットしないようにしてください。
- これにより、コード損失のリスクが軽減されます。
- さらに重要なのは、複数の人が開発に協力する場合、他の人ができるだけ早く最新のコードを入手できるため、コードの競合を可能な限り減らすことができます。
- 1 日かけてコードを開発し、それを送信しようとすると、コードの一部が他の人によって変更されており、その結果、多くの競合が発生していることがわかります。
- コードを複数回送信できる場合は、他の人の最新のコードを時間内に取得できるため、コードの競合の発生が減る可能性があります。なぜなら、コードをプッシュする前に、Git はコードが更新されたかどうかを最初にチェックするため、更新がある場合は、最初に最新のコードをプルする必要があります。
- また、Git を使用してコードを送信する場合は、コメント、送信されたコードがどのような機能を実装しているか、どのようなバグが修正されているかを必ず書いてください。
オープンソースツール
- 私たちはオープンソース ツールにもっと精通する必要があります。これは、開発効率を向上させ、仕事の車輪の再発明を避けるのに非常に役立ちます。
- hutool は、日常業務のほとんどのユーティリティを解決するのに役立ちます。
技術ブログ
- 新しい知識を学ぶと、学んだ後に忘れてしまいがちです。
- 後者を学んで前者を忘れてしまうことがよくあります。
- そのため、メモを取る習慣を身につけることをお勧めします。
- 技術的なブログを書くことでメモをとることができ、学んだ知識を印象付けるだけでなく、表現力を鍛えることもできます。
- さらに、作業中に発生したいくつかの問題とその解決策を技術ブログに投稿できます。
- 一方で、次回同じ間違いをしないようにするためです。
- 一方で、他の人が回り道を避けるのにも役立ちます。