技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

目次

目次

1. プロジェクトの仕様:

(1) プロジェクトの構成：

(2) 送信データオブジェクト

2. コード仕様:

(1) データベースの命名規則:

(2) アノテーション仕様：

(3) ネーミング仕様：

(4) フロントエンドとバックエンドの仕様:

(5) その他の仕様:

3. Apifox の使用:

(1) ダウンロードとインストール:

(2) 新しいプロジェクトを作成し、チームメイトを招待します。

(3) インターフェース文書の仕様書作成

4. デバッグ機能（バックエンドの知識が必要）

5. テストカテゴリー

6. 注:

(一人の人間が国を支配することはできません!!!)

---

1. プロジェクトの仕様:

(1) プロジェクトの構成：

具体的なものは次のとおりです。

(1) エンティティ層: エンティティ層には、データベース内のオブジェクトに対応する特定のオブジェクト エンティティが格納されます。

(2) DAO 層: (2 つの層 (dao のインターフェース層と dao の実装層) に再分割できます) は、データベースと対話する層であり、データベースの追加、削除、変更、およびクエリ操作が含まれます。

(3) サービス層 (2 つの層 (サービス インターフェイス層とサービス実装層) に細分化できます): 主にビジネス モジュールの論理アプリケーション設計を担当します。

(4) コントローラー層: コントローラー層は、特定のビジネス モジュール プロセスの制御を担当します。コントローラー層は、フロントエンドとバックエンドの対話、フロントエンド要求の受け入れ、サービス層の呼び出し、サービス層から返されるデータの受信を担当します。サービス層、そして最後に特定のページとデータをクライアントに返します。

(5) Util 層: ツール層には、一般的に使用されるツール クラスが配置されます。たとえば、いくつかの一般的なメソッドを util 関数として記述でき、コード全体を簡素化できます。

(6) 例外層: 統合された戻り例外層を作成できます。

(7) フィルタ層: アイデンティティ認証を均一にフィルタリングするなどのフィルタ層。フィルタが通過しない場合はゲスト モードのみになります。

(2) 送信データオブジェクト

DTO は、フロントエンド リクエストによって送信されるデータ構造です。

VO は、フロントエンドによって送信されたリクエストに応じてバックエンドによって返される応答です。

PO は、オブジェクト エンティティとデータベース オブジェクト テーブルの間の実際の対応関係です。

BOは、業務処理プロセスにおけるオブジェクトエンティティです。

2. コード仕様:

中国語のピンインではなく、英語で名前を付けてください。

派手ではなく、わかりやすくすること。

通常の名前の代わりにこぶの名前を使用します。

一定の間隔で改行し、長い段落を書かないでください。

個人主義ではなく、注釈を付けてください。

Java 言語コーディング仕様 - Java 言語コーディング仕様 (中国語版) - オンライン ドキュメント - JAVA プログラミング資料 Niubi Station (javanb.com)http://doc.javanb.com/code-conventions-for-the-java-programming-language-zh/index.html#312

Java 自体で特別な意味を持つキーワードや予約語などは使用しないでください。 ！ ！

(1) データベースの命名規則:

(1) テーブル名は一意であり、複数のテーブル名で同じ名前を使用することはできません。

(2) テーブル名は、大文字や特殊文字の使用を避け、「user_info」または「tbl_user」を使用してください。

(3) キーワードと矛盾しないようにしてください。like、desc、range、match、delayed などの予約語を無効にするには、MySQL 公式の予約語を参照してください。

(4) データベースフィールド名：「user_id」、「user_name」、「user_password」、「user_register_time」、「user_login_time」など、26 文字の英字（大文字と小文字を区別）とアンダースコア「_」で構成されます。

(5) 主キーと外部キーの仕様:

主キー: pk_+テーブル名
例えば：pk_main
外部キー：fk_+スレーブテーブル名+_+メインテーブル名
例えば：fk_sub_main

(2) アノテーション仕様：

(1) クラスのアノテーション:

クラス アノテーション (Class) は主に、クラスの用途と、作成者、作成日のバージョン、パッケージ名などの情報を宣言するために使用されます。

/**
* @バージョン: V1.0
* @著者: フェンドー
* @クラス名: ユーザー
* @パッケージ名: ユーザー
* @description: これはユーザークラスです
* @データ: 2024-07-01 12:20
 **/

(2) メソッドのアノテーション (コンストラクター):

/**
* @著者: フェンドー
* @メソッド名: addUser
* @description: ユーザーを追加します
* @パラメータ: xxxx
* @return: 文字列
* @スロー:
*/

(3) コードブロックのコメント: コードの特定の部分の目的を説明します。

/**
* ユーザーをインスタンス化する
* xxxxxxxxx
 */
ユーザー user=新しいユーザー();

(4) 単一文のコメント: 個々のコードをコメントします。

ユーザー user=new User() // ユーザーをインスタンス化します。

(3) ネーミング仕様：

他の人が理解できるように名前を付け、キャメルケースで名前を付け、大文字と小文字を区別します。

例: UserController、FileController、BookService

例: MAX_STOCK_COUNT / CACHE_EXPIRED_TIME

(4) フロントエンドとバックエンドの仕様:

a) GET: サーバーからリソースを取得します。 (選択操作として見ることができます)

b) POST: サーバー上に新しいリソースを作成します。 (挿入操作とみなすことができます)

c) PUT: サーバー上のリソースを更新します。 (更新操作として見ることができます)

d) DELETE: サーバーからリソースを削除します。 (削除操作とみなすことができます)

• code：httpステータスコード
  • 自分で定義した追加のエラーがある場合は、独自のエラー コードを使用することも検討できます。
• message：対応するテキスト記述情報
  • エラーが発生した場合は、特定のエラー情報が表示されます。
  • それ以外の場合、操作は成功し、通常は簡略化された処理で OK が返されます。
• data
  • データに対応するjson文字列
    • の場合配列の場合、対応する最外層は次のようになります。[]のlist
    • の場合物体の場合、対応する最外層は次のようになります。{}のdict

{
 "code": 200,
 "message": "new user has created",
 "data": {
   "id": "user-4d51faba-97ff-4adf-b256-40d7c9c68103",
   "firstName": "crifan",
   "lastName": "Li",
   "password": "654321",
   "phone": "13511112222",
   "createdAt": "2016-10-24T20:39:46",
   "updatedAt": "2016-10-24T20:39:46"
   ......
 }
}

(3) レスポンスステータスコード

エラー：

• 1xx (情報ステータス コード)：受信したリクエストが処理中であることを示します。
• 2xx (成功ステータスコード) ：リクエストが正常に処理されたことを示します。 200 は、リクエストが正常に返されたことを意味します。
• 3xx (リダイレクトステータスコード): このリクエストを完了するにはフォローアップ アクションが必要です。
• 4xx (クライアントエラーステータスコード) : リクエストに構文エラーが含まれているか、リクエストを完了できないことを示します。 400、404、401、403 はすべて、リクエストの送信時にフロントエンドが原因で発生するエラーです。フロントエンドで最初に問題を確認する必要があります。そうしないと、バックエンドの書き込みでエラーが発生する可能性があります。
• 5xx (サーバーエラーステータスコード) : サーバーがリクエストを処理中にエラーが発生しました。 バックエンドの問題、例外がスローされる可能性がある、サーバーエラーなど。

2XX の成功

200 ok (リクエストは成功しました)
204 コンテンツがありません (リクエストは成功しましたが、結果は返されませんでした)
206 部分コンテンツ (クライアントがリソースの一部を要求し、サーバーが正常に応答して、一連のリソースを返します)

3XX リダイレクト

301 永久に移動 (永久リダイレクト)
302 件見つかりました (一時リダイレクト)
303 see other (リクエストに対応するリソースには別の URI があるため、GET を使用する必要があることを示します)
要求されたリソースを取得するためのメソッド)
304 変更されていません (クライアントがリソースへの条件付きアクセスを使用すると、サーバーはリソースを見つけますが、リクエストの条件が条件を満たさないことを示します。リダイレクトとは関係ありません)
307 一時リダイレクト (302 と同じ意味)

4XXクライアントエラー

400 不正なリクエスト (リクエスト メッセージに構文エラーがあります)
401 不正 (認証が必要 (最初の返信) または認証失敗 (2 回目の返信))
403 禁止 (リクエストはサーバーによって拒否されました)
404 見つかりません (要求されたリソースがサーバー上に見つかりません)

5XXサーバーエラー

500 内部サーバー エラー (サーバーがリクエストを実行したときにエラーが発生しました)
503 サービスを利用できません (サーバーが過負荷になっているか、メンテナンスのためにダウンしているため、リクエストを処理できません)

(5) その他の仕様:

例証します: nginx のデフォルトの制限は 1MB で、tomcat のデフォルトの制限は 2MB です。ビジネスでより大きなコンテンツを転送する必要がある場合は、サーバー側の制限を増やすことができます。

例証します: try ブロック内の return ステートメントが正常に実行された後、すぐには戻りませんが、finally ブロック内のステートメントの実行が続行されます。ここに return ステートメントがある場合は、ここで直接戻り、 内のリターン ポイントを容赦なく破棄します。ブロックしてみてください。

3. Apifox の使用:

(1) ダウンロードとインストール:

リンク: リンクをクリックして apifox を直接ダウンロードします (最新バージョンをダウンロードするだけです)。 Apifox - API ドキュメント、デバッグ、モック、テストのための統合コラボレーション プラットフォーム。インターフェースドキュメント管理、インターフェースデバッグ、モック、自動テストなどの機能を備え、インターフェース開発、テスト、共同デバッグの効率が10倍向上します。最高のインターフェース文書管理ツールおよびインターフェース自動テストツール。https://apifox.com/

(2) 新しいプロジェクトを作成し、チームメイトを招待します。

1. チームを作成し、新しいプロジェクトを作成します。

チームメイトを招待する

2. 新しいインターフェイスと新しいデータ モデルを作成します。

(1) リクエストが何であるかを判断します (POST、GET、PUT、DELETE)。

(2) テスト環境は統一する必要があり、異なる環境では URL が異なります。

(3) リクエストパラメータは次のように設定されます。

どのようなパラメータが設定されていますか? パラメータの例、中国語名、およびパラメータの説明を提供してください。

(4) 応答は次のように構成する必要があります。

たとえば、さまざまな状態でどのような種類の情報が返されるかを指定する必要があり、成功例と例外例が存在する必要があります (フロントエンドの便宜のため)。

{
    "code": 200,
    "message": "登入成功",
    "data": {
        "user_id": 27,
        "user_name": "孟霞",
        "user_password": "123456",
        "user_age": "15",
        "user_photo": "http://dummyimage.com/400x400",
        "user_last_time": "1996-12-11 09:03:49",
        "user_indentity": "messager",
        "user_birthday": "2024-02-23"
    }
}

(5) データモデルは次のように作成できます。

複数のデータ モデルを作成できます。これは、応答フィールドを返すのに非常に便利であり、フロントエンドでデータ フィールドを表示するのにも便利です。

(3) インターフェース文書の仕様書作成

apifox の書き込み仕様と具体的な詳細。

Apifox クイック スタート | Apifox ヘルプ ドキュメントhttps://apifox.com/ヘルプ/

(1) API インターフェース文書の冒頭に序文が必要です。このセクションには次の内容を含めることができます。

• API インターフェースの名前とバージョン番号
• APIインターフェースの機能と目的
• API インターフェースの設計目的と原則
• APIインターフェースの適用範囲と制限事項

このパートの目的は、読者に API インターフェースの基本的な状況と背景情報を理解してもらうことです。

(2) インターフェース一覧

次に、API インターフェイス ドキュメントで、すべてのインターフェイスをリストする必要があります。各インターフェイスには次の情報が含まれている必要があります。

• インターフェース名と説明
• リクエストメソッド（GET、POST、PUT、DELETEなど）
• リクエストパス(URL)
• リクエストパラメータ（Queryパラメータ、Bodyパラメータを含む）
• リクエストの例 (リクエスト ヘッダーとリクエスト本文を含めることができる完全な例)
• 応答ステータスコードと説明
• レスポンスパラメータ（ヘッダパラメータ、ボディパラメータを含む）
• 応答の例 (応答ヘッダーと応答本文を含めることができる完全な例)

このセクションの目的は、読者が各インターフェイスの基本情報をすぐに理解し、ドキュメント内の例に基づいてインターフェイスを正しく使用できるようにすることです。

(3) リクエストパラメータとレスポンスパラメータの説明

インターフェイスのリストの後に、各インターフェイスのリクエスト パラメーターと応答パラメーターを詳しく説明する必要があります。このセクションには次の情報を含める必要があります。

• パラメータ名と説明
• パラメータのタイプと形式
• それは必須であり、デフォルト値ですか?
• パラメータの例

パラメーターの型と形式については、標準のデータ型と形式を使用することも、特定の状況に応じて独自のデータ型と形式を定義することもできます。必須かどうか、デフォルト値は実際の状況に基づいて決定する必要があります。

(4) エラーコードの説明

API インターフェースを使用すると、エラーが発生することがあります。この場合、エラーの種類と原因を説明するためにエラー コードを返す必要があります。したがって、API インターフェイスのドキュメントでは、考えられるすべてのエラー コードを指定する必要があります。このセクションには次の情報を含める必要があります。

• エラーコードと説明
• エラーの種類と原因
• インターフェースから返されるエラーコードの例

このセクションの目的は、読者が考えられるすべてのエラーの種類と原因を理解し、ドキュメント内の例に基づいてエラーを正しく処理できるようにすることです。

4. デバッグ機能（バックエンドの知識が必要）

2 分で Java でデバッグする方法を教える [IDEA での Java]_ケースを使わずに Java プロジェクトでデバッグする方法 - CSDN ブログhttps://blog.csdn.net/qq_43436117/article/details/113859737

5. テストカテゴリー

(1) 具体的な操作：

テストクラスを定義する

提案：

テストクラス名: テスト対象クラス名 Test CalculatorTest
パッケージ名: xx.xx.xx.test cn.itcast.test
テストメソッドの定義: 独立して実行可能

提案：

メソッド名: テストメソッド名 testAdd()
戻り値: void
パラメータリスト: 空のパラメータ
@Testをメソッドに追加する

Junit 依存関係環境をインポートする

判定結果：

赤: 失敗しました
緑: 成功
通常、Assert クラスの静的メソッドassertEquals(expected,actual)を使用して、期待される結果と出力結果を処理します。

Assert.assertEquals(3, 結果);

2 つのパラメータは次のとおりです: 期待値 プログラム結果値

テスト結果の処理に Assert.assertEquals(expected,actual) を使用するのはなぜですか?

赤は失敗を表し、緑は正しさを表すと規定しているからです。テスト メソッドを使用してコンピュータの加算メソッドをテストする場合、この結果のみを出力します (例外が発生しないと仮定して)。 1 と 3 を入力すると、結果 4 が得られると期待されますが、出力されるものは 2 で、取得されると期待されるものは 4 です。この時点で得られた結果は期待を満たしていませんが、実行結果はまだ緑色です。 (正しいことを表す), それは正しくありませんか? このとき、最後に Assert のassertEquals メソッドを使用して、期待値とプログラムが出力した結果値を比較し、それらが等しい場合は緑色になります。等しくない場合は赤になります。この時間は緑と赤の定義を満たしていますか?

package cn.itcast.test;
 
import cn.itcast.junit.Calculator;
import org.junit.Assert;
import org.junit.Test;
 
public class CalculatorTest {
    /**
     * 测试add方法
     */
    @Test
    public void testAdd(){
        Calculator  c = new Calculator();
        int a = 1, b = 2;
        int result = c.add(1, 2);
        Assert.assertEquals(3, result);
    }
 
    /**
     * 测试sub方法
     */
    @Test
    public void testSub(){
        Calculator  c = new Calculator();
        int a = 1, b = 2;
        int result = c.sub(1, 2);
        Assert.assertEquals(-1, 2);
    }
}
 

@前に
テストメソッドの前に @Before を追加すると、このメソッドはすべてのテストメソッドが実行される前に自動的に実行されます。

@後
テストメソッドの前に @After を追加するとリソース解放メソッドとなり、すべてのテストメソッドが実行された後に自動的に実行されます。

@Before で装飾されたメソッドは、テスト メソッドが実行される前に実行されます。

@After で装飾されたメソッドは、テスト メソッドの実行後に実行されます。

@Before または @After で変更されたメソッドは、テスト メソッドが発生するかどうかに関係なく実行されます。

(2) Testクラスプラグインを自動生成する

Java プロジェクトの単体テストを自動生成するための推奨プラグイン - Tencent Cloud Developer Community - Tencent Cloud (tencent.com)https://cloud.tencent.com/developer/article/1910893

6. 注:

(1) バックエンドのインターフェース文書を書くときは、フロントエンドが理解できるように明確に書く必要があります。自分で理解できるように書く必要はありません。書き換えられた名前とデフォルト値のインターフェイス応答は適切に記述される必要があります。

(2) 教えられた内容に加えて、メール認証の登録、認証コードのログイン、c3p0、MD5 暗号化、ログ ログ、結果のスタイルなど、その他のことを自分で学ぶこともできます。

(3) コードの記述も標準化する必要があり、ロジック (Cookie、セッション) の設定も厳密にする必要があり、空の判断が必要な場合は空の判断を行う必要があり、セキュリティを強化できる場合はそこから学ぶことができます。

(4) フロントエンドとバックエンドはうまく連携する必要があります。フロントエンドに何も言わずにバックエンドが勝手にやることを許してはいけません。フロントエンドとバックエンドのインタラクティブな応答も評価の一部であり、作成したインターフェイスは apifox 経由でのみ実行できますが、特定のフロントエンド ページに表示されるときにエラーが発生しますか。 ? 論理的な問題など、考慮が必要な点はありますか。

(一人の人間が国を支配することはできません!!!)

(5) 需要分析中に、実行したい機能とインターフェイスを指定します。フロントエンドで実行されていない機能がある場合は、それらの機能をバックエンドで実行する必要があります。 Interfaces/data を書いていない場合は、注意深く反省して、もっとコミュニケーションしてください。

実際に機能するプロジェクト、またはショッピング Web サイトなどの同様のものに対してベンチマークを行うことができます。次に、この Web サイトにあるバックエンド インターフェイス、機能モジュール、および具体的な詳細についてベンチマークを行う必要があります。

(6) やみくもに追求せず、論理的かつ合理的で、簡略化できる部分は簡略化することを学びましょう。ただし、基本的なインターフェイス数とコード量も保証する必要があります。 (私たちが最初に書いたインターフェースは基本的に 40 以上でした)