Ali 開発マニュアル仕様書 (JAVA)

目次

1. プログラミングプロトコル 

(1) 命名規則

(2) 定数の定義

(3) コード形式 

(4) OOPプロトコル

(5) 日時

(6) 収集処理 

(7) 並行処理

(8) 制御文

(9) 注記および法規

(10) フロントエンドおよびバックエンドプロトコル

2. 例外ログ 

(1) エラーコード

(2) 例外処理

(3) ログプロトコル 

3. 単体テスト 

4. 安全規制

5.MySQLデータベース 

(1) テーブル作成プロトコル

(2) インデックスプロトコル 

(3) SQL文

(4) ORMマッピング

6. エンジニアリング体制 

(1) アプリケーションの階層化

(2) セカンドパーティライブラリの依存関係 

(3) サーバー 

7. 設計規定 


1. プログラミングプロトコル 

(1) 命名規則

1. コード内の名前は、アンダースコアまたはドル記号で始めることはできず、また、アンダースコアまたはドル記号で終わることもできません。反例: _name / __name / $name / name_ / name$ / name__。

2. ピンインと英語を混合することは禁止されています。反例: DaZhePromotion [割引] / getPingfenByName() [スコア]。

3. クラス名には大きなキャメル ケースの命名方法が使用され、メソッド名、パラメーター名、メンバー変数、およびローカル変数はすべて小さなキャメル ケースの命名方法が使用されます。

4. 定数の名前はすべて大文字で、単語はアンダースコアで区切られます (: MAX_STOCK_COUNT / CACHE_EXPIRED_TIME)。

5. 型の後には配列を示す角括弧が続きます。: 整数配列 int[] arrayDemo を定義します。 

6. ブール型変数の場合、部分シリアル化フレームワークでのエラーを避けるために、is で始めないでください。反例:ブール値は存在します。

7. 意味の無理解を避けるために、完全に非標準的な略語をやめてください。反例: AbstractClass は AbsClass に「短縮」され、condition は condi に「短縮」されます。

8. Service クラスと DAO クラスの場合、それはインターフェイスである必要があり、実装は Impl のサフィックスで終わる必要があります。
CacheService CacheServiceImpl などのインターフェイスとは異なります。

9. 列挙型クラス名には Enum という接尾辞が付けられます。列挙型メンバー名はすべて大文字である必要があり、単語はアンダースコアで区切られます。 

10. クラスインターフェイスの属性とメソッドに修飾子を追加しないでください。

(2) 定数の定義

1. マジック値 (つまり、事前定義されていない定数) をコード内に直接出現させないでください。  否定的な例: String key = "id=" + id;

2. Long と Long を最初に割り当てるときは、数字の 1 との混同を避けるために大文字を使用する必要があります。
: Long a = 2L   逆の例: Long a = 2l

3. すべての定数を定数クラスで管理するのではなく、できる限り機能ごとに分割・分類し、個別に管理します。理解と保守が簡単です。

(3) コード形式 

1. 中括弧が空の場合は、{} と書くだけで、中括弧の間に改行やスペースは必要ありません。空ではないコード ブロックの場合: (1) 左中括弧の前に改行はありません。左中括弧の後の改行。(2) 閉じ中括弧の前で改行します。  

2. 左括弧と次の文字の間にスペースはありません。右括弧と前の文字の間にはスペースがありません。
: if (flag == 0)。

3. if/for/while/switch/do などの予約語と括弧の間にスペースを追加する必要があります。 

4. 二項演算子および三項演算子では、左側と右側にスペースを追加する必要があります。 

5. コメントの二重スラッシュとコメントの内容の間には、スペースが 1 つだけあります。 

6. メソッドのパラメータを定義して渡す場合、複数のパラメータの場合はカンマの後にスペースを追加する必要があります。: メソッド("a", "b", "c");

(4) OOPプロトコル

1. クラス名を直接使用して、クラスの静的変数または静的メソッドにアクセスします。

2. オーバーライドが成功したかどうかを正確に判断するには、すべてのオーバーライド メソッドに @Override アノテーションを付ける必要があります。

3. 外部インターフェイスは原則として変更を避け、新しいインターフェイスを追加できます。古いインターフェイスには @Deprecated のアノテーションを付ける必要があります。

4. Objectのequalsメソッドはnullポインタ例外をスローしやすいため、equalsを呼び出すには定数または必ず値を持つオブジェクトを使用する必要があります。: "テスト".equals(object); 

5. 整数ラッパーオブジェクト間の値比較はすべてequalsメソッドで行うこととし、==で判定すると値の範囲に制限が生じます。

6. StringBuilder の append メソッドを使用して、ループ本体内の文字列を連結します。

7. 構築メソッド内にビジネスロジックを追加することは禁止されており、初期化ロジックがある場合はinitメソッド内に記述してください。 

8. 浮動小数点数間の等価判定では、基本データ型は == 、パッケージデータ型はイコールで比較できません。 

(5) 日時

1. 日付をフォーマットする場合、受信パターンで年を表すために小文字の y が一律に使用されます。 

2. 現在のミリ秒を取得します: new Date().getTime() の代わりに System.currentTimeMillis(); します。 

(6) 収集処理 

1.equals を書き換えるたびに、hashCode を書き換える必要があります。

2. コレクション内のすべての要素が空かどうかを判断するには、size()==0 メソッドの代わりに isEmpty() メソッドを使用します。

3. ArrayList の subList メソッドの結果を ArrayList に変換することはできません。(subList は ArrayList ではなく ArrayList の内部クラスを返し、ArrayList のビューです。SubList に対するすべての操作は ArrayList の元のリストに反映されます。)

4. collection-to-array メソッドを使用するには、コレクションの toArray(T[] array) を使用する必要があります。

5. foreach ループ内の要素を削除/追加しないでください。要素の削除には Iterator メソッドを使用してください。操作を同時に実行する場合は、Iterator オブジェクトをロックする必要があります。 

6. ツール クラス Arrays.asList() を使用して配列をコレクションに変換する場合、add/remove/clear などのコレクションの変更に関連するメソッドは使用できません。UnsupportedOperationException 例外がスローされます。

(7) 並行処理

1. シングルトン オブジェクトを取得するには、スレッドの安全性を確保する必要があり、そのオブジェクト内のメソッドもスレッドの安全性を確保する必要があります。 

2. スレッド リソースはスレッド プールを通じて提供する必要があり、スレッドの作成が多すぎることを避け、スレッドの作成と破棄のオーバーヘッドを軽減するために、アプリケーションでスレッドを明示的に作成することは許可されません。

3. スレッド プールは Executor を使用して作成することはできませんが、ThreadPoolExecutor を通じて作成できます。Executor によって返されるスレッド プール オブジェクトの欠点は、多数のスレッドが作成されたり、多数のリクエストが蓄積されて OOM が発生する可能性があることです。 。

4. 同時実行性については、ロックのパフォーマンス損失を考慮してください。ロックなしでロックできる場合は、ロックは必要ありません。ブロックをロックできる場合は、メソッド全体をロックしないでください。オブジェクトをロックできる場合は、クラスをロックしないでください。

5. 複数のリソース、データベース テーブル、およびオブジェクトを同時にロックする場合、一貫したロック シーケンスを維持する必要があります。そうしないと、デッドロックが発生する可能性があります。

6. アクセス競合の可能性が高くない場合は、楽観的ロックを使用することをお勧めします。

7. HashMap の容量がリサイズできない場合、同時実行性が高く、デッドリンクが発生し、CPU が高騰する可能性がありますので、開発時にはこのリスクを回避するよう注意してください。 

8. ThreadLocal オブジェクトには静的変更を使用することをお勧めします

(8) 制御文

1. switch ブロックでは、各ケースはブレーク/リターンによって終了するか、どのケースが実行されるかをコメントで示します。スイッチには空の場合でもデフォルトが含まれている必要があります。

2. スイッチの括弧内の変数の型が String で、この変数が外部パラメータの場合、最初に null 判定を行う必要があります。

3. if/else/for/while/do ステートメントでは中括弧を使用する必要があります。 

4. 同時実行性の高いシナリオでは、割り込みまたは終了条件として「等しい」判定を使用することは避けてください。 反例:賞品の残数が0と判定された場合、賞品の配布を終了するが、並行処理エラーにより賞品の数が瞬時にマイナスとなるため、この場合はアクティビティを実行できない。終了しました。 

(9) 注記および法規

1. クラス、クラス属性、およびクラス メソッドに関するコメントは、Javadoc 仕様を使用し、/**content*/ 形式を使用する必要があり、// xxx メソッドは使用しないでください。

2. すべての抽象メソッド (インターフェース内のメソッドを含む) には Javadoc の注釈が付けられている必要があります

3. すべてのクラスは作成者と作成日を追加する必要があります。 

(10) フロントエンドおよびバックエンドプロトコル

1. フロントエンドとバックエンドの対話用の API では、プロトコル、ドメイン名、パス、リクエスト メソッド、リクエストの内容、ステータス コード、および応答本文を指定する必要があります。

2. フロントエンドおよびバックエンドのデータリストに関連するインターフェースが返され、空の場合は空の配列 [] または空のコレクション {} が返されます。 

3. サーバー側でエラーが発生した場合、フロントエンドに返される応答情報には、HTTP ステータス コード、errorCode、errorMessage、およびユーザー プロンプト情報の 4 つの部分が含まれている必要があります。

2. 例外ログ 

(1) エラーコード

1. エラーコードにはバージョン番号やエラーレベルの情報は反映されません。 

2. エラーコードをプロンプトメッセージとしてユーザーに直接出力することはできません。 

(2) 例外処理

1. RuntimeException から継承されたランタイム例外をキャッチしません。IndexOutOfBoundsException / NullPointerException などの例外は、それ自体でチェックして回避する必要があります。

2. 例外をキャッチした後のプロセス制御や条件制御には使用しないでください。 

3. 例外をキャッチする目的は例外を処理することです。例外をキャッチせず、何も処理せずに破棄してください。処理したくない場合は、呼び出し元に例外をスローしてください。

4.finally ブロックはリソース オブジェクトとストリーム オブジェクトを閉じ、例外が発生した場合は try-catch を実行する必要があります。finally ブロックでは return を使用しないでください。 

(3) ログプロトコル 

1. ログ実装クラスを使用せず、SLF4JのAPIインターフェースを使用し、ファサードモードを使用することで、全クラスで統一したログ処理方法を実現しやすくなります。

2. 一部の異常には「毎週」発生頻度の特性があるため、すべてのログ ファイルは少なくとも 15 日間保存されます。

3. ログを繰り返し出力してディスク領域を無駄にしないように、ログ構成ファイルで additivity=false を設定してください。 

4. ログを出力する場合、JSON ツールを直接使用してオブジェクトを文字列に変換することは禁止されています。

3. 単体テスト 

1. 優れた単体テストは AIR 原則に従う必要があります。つまり、自動化、独立性、再現性の特性を備えています。

2. 単体テストは繰り返し実行でき、外部環境の影響を受けません。 

3. 単体テストを独立させます。単体テストの安定性、信頼性、保守が容易であることを保証するために、単体テスト ケースは相互に呼び出したり、実行順序に依存したりしてはなりません。 

4. 安全規制

1. ユーザーに属するページまたは機能は、権限制御の検証を受ける必要があります。 

2. ユーザーの機密データを直接表示することは禁止されており、表示データは感度を下げる必要があります。 

3. ユーザーが入力した SQL パラメーターは、SQL インジェクションを防止し、データベースにアクセスする SQL の文字列スプライシングを禁止するために、パラメーター バインディングまたは METADATA フィールド値によって厳密に制限されます。 

4. フォームと AJAX の送信では、CSRF セキュリティ検証を実行する必要があります。 

5.MySQLデータベース 

(1) テーブル作成プロトコル

1. Yes または No の概念を表すフィールドは is_xxx の形式で名前を付ける必要があり、データ型は unsigned tinyint (1 は Yes を意味し、0 は No を意味します) です。 

2. テーブル名のフィールド名には小文字または数字を使用する必要があり、数字の先頭は禁止されており、2 つのアンダースコア間の数字のみが禁止されています。: aliyun_admin、rdc_config、level3_name。

3. desc、range、match、delayed などの予約語を無効にします。

4. テーブル名には複数名詞は使用しません。 

5. 主キーのインデックス名は pk_field name、一意のインデックス名は uk_field name、共通インデックス名は idx_field name です。注: pk_ は主キー、uk_ は一意のキー、idx_ はインデックスの省略形です。 

6. 10 進数型は 10 進数であり、float および double は禁止されています。 

7. 格納する文字列の長さがほぼ等しい場合は、固定長文字列型 char を使用してください。

8. Varchar は可変長の文字列であり、その長さは 5000 を超えてはなりません。格納長がこの値を超える場合は、テキストを使用して独立してリストします。

9. テーブルには、id、create_time、update_time の 3 つのフィールドが必要です。 

(2) インデックスプロトコル 

1. ビジネスにおいて固有の特性を持つフィールドは、複合フィールドであっても、固有のインデックスに構築する必要があります。 

2. 3 つを超えるテーブルの結合は禁止されています。結合する必要があるフィールドのデータ型は完全に一貫している必要があります。複数テーブルの関連付けクエリを実行する場合は、関連付けられたフィールドにインデックスが必要であることを確認してください。

3. varchar フィールドにインデックスを作成する場合は、インデックスの長さを指定する必要がありますが、フィールド全体のインデックスを作成する必要はなく、実際のテキストの識別に従ってインデックスの長さが決定されます。 

4. 左ボケや全ボケは厳禁です。

5. テーブルに戻らないように、カバリング インデックスを使用してクエリ操作を実行します。 

(3) SQL文

1. count(*) の代わりに count (列名) または count (定数) を使用しないでください。count(*) は、SQL92 で定義された行をカウントするための標準構文であり、データベースとは何の関係もありません。 NULL と非 NULL を処理します。 

2. カラムの値がすべて NULL の場合、count(col) の戻り結果は 0 になりますが、sum(col) の戻り結果は NULL となるため、sum() を使用する場合は NPE 問題に注意してください。 

3. in 演算は避けられる場合は避け、どうしても避けられない場合は、in の背後にある集合要素の数を慎重に評価し、1000 以内に制御する必要があります。 

(4) ORMマッピング

1. テーブル クエリでは、クエリのフィールド リストとして * を決して使用しないでください。また、どのフィールドが必須であるかを明確に記述する必要があります。

2. POJO クラスのブール属性では is を追加できませんが、データベース フィールドでは is_ を追加する必要があります。これには、resultMap 内のフィールドと属性間のマッピングが必要です。 

3. sql.xml 構成パラメータの使用: #{}、#param# ${} は使用しないでください。この方法は SQL インジェクションが発生しやすいです。

4. データテーブルのレコードを更新する場合、そのレコードに対応する update_time フィールドの値も現在時刻と同時に更新する必要があります。 

6. エンジニアリング体制 

(1) アプリケーションの階層化

1. 階層ドメインモデルの仕様: 
• DO (Data Object): このオブジェクトはデータベースのテーブル構造と 1 対 1 に対応しており、データ ソース オブジェクトは DAO 層を介して上向きに送信されます。 
• DTO (データ転送オブジェクト): データ転送オブジェクト、サービスまたはマネージャーが転送するオブジェクト。 
• BO (ビジネス オブジェクト): ビジネス オブジェクト。サービス層によって出力できるビジネス ロジックをカプセル化するオブジェクト。 
• クエリ: データ クエリ オブジェクト。各層は上位層からクエリ要求を受け取ります。2 つ以上のパラメータを持つクエリのカプセル化に注意してください。Map クラスを使用して転送することは禁止されています。 
• VO (View Object): 表示層オブジェクト。通常は Web からテンプレート レンダリング エンジン層に送信されるオブジェクトです。 

(2) セカンドパーティライブラリの依存関係 

1. セカンドパーティライブラリのバージョン番号の命名方法:メジャーバージョン番号、マイナーバージョン番号、リビジョン番号。

2. 列挙型はセカンドパーティのライブラリで定義でき、パラメータでは列挙型を使用できますが、インターフェイスの戻り値では列挙型または列挙型を含む POJO オブジェクトの使用は許可されません。 

3. セカンドパーティのライブラリ グループに依存する場合、バージョン番号の不一致を避けるために、統一バージョン変数を定義する必要があります。 

4. サブプロジェクトの pom 依存関係で、同じ GroupId、同じ ArtifactId、ただしバージョンが異なることは禁止されています。

(3) サーバー 

1. 同時実行性の高いサーバーの場合は、TCP プロトコルの time_wait タイムアウトを減らすことをお勧めします。

2. -XX:+HeapDumpOnOutOfMemoryError パラメータを JVM 環境パラメータに設定して、JVM が OOM シーンに遭遇したときにダンプ情報を出力できるようにします。

7. 設計規定 

1. 要件分析段階で、システムと対話する複数のタイプのユーザーと 5 つ以上の関連するユーザー ケースがある場合は、ユース ケース図を使用して、より明確に構造化された要件を表現します。 

2. ビジネス オブジェクトに 3 つ以上の状態がある場合は、状態図を使用して、状態変化の各トリガー条件を表現し、明確にします。

おすすめ

転載: blog.csdn.net/weixin_51360584/article/details/128098109