1. 個人プロジェクト: 質問リスト
- プロジェクトの具体的なプロセスについて話します:
プロジェクトの 3 層構造: コントローラー層、サービス層、Dao 層。各セクションが何を達成する必要があるかを分析します。
1) データの操作が必要な場合は、Dao レイヤーという記述メソッドを使用し、マッパー内の xml ファイルに SQL 言語を記述してデータベースを操作し、データの追加、削除、変更、クエリを実行します。 - プロジェクトがフロントエンドおよびバックエンドと対話するとき、セキュリティの問題を考慮しますか?
1) 通信リクエストは、機密性レイヤーのある https を使用します。
2) 本人確認メカニズムでは、各リクエストが合法であるかどうかを検証する必要があります。認証。 - バックエンドは階層化されていますか?
1) 3 層アーキテクチャ モデルの使用 - 使用するデータベースとこれを使用する理由
1) Mysql は主流のデータベースであり、多くの人が使用しており、オープンソースで安定しています。これはリレーショナル データベースです。
2) Redis はキャッシュとして使用される非リレーショナル データベースです。 - プロジェクトの各モジュールと技術スタックを紹介します。
1)登録およびログイン機能の実装の
困難さ: 分散セッションの問題 (セッション管理、トークン、Redis)、パスワード セキュリティの問題 (MD5 コード (パスワード + ソルト)) を解決する方法、およびログイン問題の最適化 (Redis はログイン認証情報を保存し、Redis は検証コードを保存します。Redis を使用してユーザー情報をキャッシュします)
2)インターセプタは
インターセプタを利用してすべてのリクエスト(認証)をインターセプトし、パスすると、1つのリクエストについて、各スレッドが保持するTreadLocalにユーザ情報が保存され、ユーザ情報をグローバルに利用できるようになります。
3)ログ管理
(1) AOP はサービス層のすべてのビジネスメソッドのログ記録を実装します
(2) インターセプタは主にコントロール層コントローラを対象としています
異なる操作 (フロント、ミドル、バック操作) を実行するために異なるインターセプターを作成すると、
すべてのインターセプター、つまりスキャンされたファイルを構成できます。
4) Redis の
いいね情報: Set を使用、リストにない場合にカウントするのに便利、
ユーザーが受け取ったいいねを見つけるのが簡単: 数がわかっていれば関数 int を使用、同時に操作フォローするのもフォローされるのも便利です
: 関数 set を使用し、共通の友人、交差点を取得します、
sister ユーザーがフォローするエンティティ: zset、並べ替えに便利です
5) トランザクション
使用する場所: コメントとコメントの数を増やす、注目と注目の数を増やす; フォロー成功とファン追加の同期;
肯定的なトランザクション: @Transaction はアノテーションでマークされます
プログラム的なトランザクション: multi と 2 つのコマンドを実行します。
6) 実行する必要はないが、非常に面倒なこと
非同期メッセージキュー: kafka 7.
プロジェクトの開発中に遭遇したバグを簡単に紹介
8. プロジェクトのログはどのように出力されますか?
9. インターフェイスをどのように設計しましたか?
10. バージョン管理はどのように機能しますか? 大きな問題が発生し、バージョンが返されましたか?
11. プログラムをデバッグするとき、エラー メッセージが報告された場合、どのように分析しますか?はい、最も印象に残ったデバッグはありますか?
12. プロジェクトの難しさと個人的な利益 (重要な問題、遭遇した最大の問題)
2. インターンシッププロジェクト：質問一覧
- インターンシップの内容
1)要件開発プロセス: 要件の提案からソフトウェア バージョンのリリースまで、要件開発のプロセス全体を明確に管理します。
要件提案 -> 要件分析 -> クロストーク (つまり、要求提案者、フロントエンド、バックエンド、およびテストタスクによる要件分析の実装) -> アンチクロストーク (バックエンド、フロントエンド、およびテスターが独自の変更計画を提案し、実装する)実行する必要があるタスク) –> バックエンド機能の実装 –> デモショー (応答機能がテスト プラットフォームに実装されているかどうかを表示); 2) 要件 (1) 製品ページにカスタマー サービス ホットラインを追加します (
注
)以前にホットラインがなかった製品と互換性があること、つまり、製品を編集するときは、元のフィールドに入力する必要があり、元のフィールドに入力する必要があります); カスタマー サービス ホットラインの検証ルールを確認してください。
(2) 製品の検証を繰り返し、重複した製品の ID を返します (問題がある場合、つまりサードパーティのインターフェイスがあり、両者のデータベースが不一致であり、判断ロジックもあります) (3) ホワイトリストの検証 (
リスト内の白い場合は、直接クリックして監査部分をスキップできます) (考え方: 主にその後の拡張を考慮し、RPC コードの再利用) (4) フォームのページ操作
:注意すべき点は、権限の確認とパラメータの検査です。
(5) SQL ステートメントを確認します。結合テーブル クエリにより SQL の実行が非常に遅くなります。大規模なデータ操作では、リストをリンクしないようにし、テーブルを分解する必要があります。 - プロジェクトの難しさ
1) プロジェクトの難しさは主に機能実装の標準化に反映されています。インターフェイスの開発では、互換性、間接性、スケーラビリティ、コードの再利用に注意を払う必要があります。 - 個人的なメリット
1) プロジェクト開発のプロセス全体を明確に理解する
2) 要件開発の分析に十分に精通しているため、プロジェクトをすぐに開始して要件を開発できる。
3) コミュニケーションは非常に重要です。開発前に、何が必要で、どのような方法が利用できるかを把握する必要があります。残りは開発であり、より慎重に考える必要があります。
4) 要件作成の要件: 権限検証、パラメータ検証、アノテーション仕様。