Spring Bootに基づくアプリケーション開発仕様の構築

1.規範の意義と作用

符号化仕様は、チーム開発の協力効率を最大限に向上させることができる

符号化仕様は、1つのソフトウェアのメンテナンスコストを可能な限り削減することができ、そのライフサイクル全体において、

を最初の開発者によってメンテナンスするソフトウェアはほとんどありません.

符号化仕様はソフトウェアの可読性を改善することができ、開発者にできるだけ早く新しいコード

を徹底的に理解させることができる.

規範的なコードは開発者に良いコード習慣を身につけることができ、さらに厳格な思考を鍛えることができる

2.コード倉庫仕様
2.1共通コンポーネント

共通コンポーネントは、通常、Javaライブラリを指し、特定の問題を提供するハンドラパッケージ

を提供する.

パブリックコンポーネント倉庫アドレス:https://git.company.com/java-library-group

共通コンポーネントの座標命名仕様

パケット番号:com.company.library固定取値

コンポーネント名:name nameコンポーネント名定義

コンポーネントバージョン:x.y.z x.y.zコンポーネントの実際のバージョンに基づいて

を定義します.

2.2サービスコンポーネント

サービスコンポーネントは、通常、独立して配置、実行、メンテナンス可能なサービスパッケージ

を指す.

サービスコンポーネント倉庫アドレス:https://git.company.com/server-microservice-group

アプリケーションコンポーネントの座標命名仕様

パケット番号:com.company.server固定取値

コンポーネント名:name nameコンポーネント名定義

コンポーネントバージョン:x.y.z x.y.zコンポーネントの実際のバージョンに基づいて

を定義します.

3開発環境規範

開発環境:JDK 1.7+

開発ツール:IntelliJ IDEA 2017(Lombok Pluginのインストール)

構築ツール:Maven 3.x

コード管理ツール:Git/tortoiseGit

4.プロジェクト構造規範
4.1簡単な説明
プロジェクト対応コード・ウェアハウスのウェアハウスです.プロジェクト構造とは、Mavenに基づいて作成されたプロジェクト・ディレクトリ構造です.共通コンポーネントプロジェクトで、通常はMaven通常プロジェクトが作成されます.サービスコンポーネントプロジェクト.通常、1つのMaven集約プロジェクトが作成され、集約プロジェクトディレクトリの下に、サービスコンポーネントプロジェクトのコンポーネントとして機能するMaven集約プロジェクトを継承する複数のMavenモジュールが作成されます.
4.2項目名

要件

英語名、倉庫、プロジェクト、プロジェクトルートディレクトリ、コンポーネント(共通コンポーネント、サービスコンポーネント)の名前

として使用

中国語名称、コードウェアハウスの説明

用

プロジェクト名とコードウェアハウス名が一致する

定義

プロジェクト名は、通常、チームの責任者によって決定されます.

例

プロジェクト中国語名:顔データ倉庫

プロジェクト英語名:data-warehouse-face

プロジェクトディレクトリ名:data-warehouse-face

プロジェクト倉庫住所:https://git.company.com/server-microservice-group/data-warehouse-face.git

初期バージョン:1.0.0

の例は、上述の情報に基づいて、サービスコンポーネントのMaven座標命名を決定するサービスコンポーネントである:

.

com.company.server
data-warehouse-face
1.0.0

4.3モジュールの命名

要件

モジュール名:{プロジェクト名}-{モジュール名}モジュール名簡潔体現職責

モジュール名モジュールコンポーネント名

例

顔データウェアハウスのデータアクセスモジュール名:data-warehouse-face-access

4.4プロジェクトディレクトリ

プロジェクトディレクトリMaven約定ディレクトリフォーマット

に従う
4.5ソースディレクトリ

ソースディレクトリ:{プロジェクトディレクトリ}/src/main/

パッケージ定義ディレクトリ:src/main/assembly

コードディレクトリ:src/main/java

リソースディレクトリ:src/main/resources

/db:データベース・スクリプトのアーカイブ

/data:内部依存データアーカイブ

ドキュメントディレクトリ:src/main/docs

スクリプトディレクトリ:src/main/bin

run-manage.sh実行管理スクリプト(パラメータstart,stop,status,help info制御プログラムで実行)

sh:サービスコンポーネント起動スクリプト

sh:サービスコンポーネント停止スクリプト

5.コード仕様
5.1パッケージ仕様

プロジェクト基本パッケージ:com.company.{プロジェクトの英語名(長時間で適切に簡略化)}.{モジュール名(オプション)}

config:構成クラス

startup:サービス起動に関連するクラス

client:クライアント実装に関するクラス

を提供する

common:共通クラス、定数クラスの定義、コンポーネント

entity:データベース関連エンティティクラス

model:データモデルクラス(パラメータモデル、データ転送モデルなど)

control:制御層インタフェース

service:サービス層

dao:データベース・アクセス・レイヤ

5.2ログ

SLF 4 jインタフェース

を統一的に使用する.
5.3異常処理

運転時異常:パラメータチェックなどにより運転時異常を回避または投げ出す、ログ記録

検査異常:検査異常は捕獲、処理、ログ記録

が必要である
5.4インタフェース定義

原則

インタフェースアドレス定義は、意図

を示す.

インタフェースアドレスの定義は明確で、簡潔で、曖昧ではない

同じサービスコンポーネントのインタフェース定義は、一貫性

を有する.

形式

制御クラスの最上位アドレスフォーマット:/{最上位分類名}、例えば:/libraryライブラリ関連インタフェースの最上位アドレス

インタフェース定義Swaggerを使用するAPI注記

完全な要求情報、要求方法、要求アドレス、パラメータオプション、インタフェース記述

リクエスト方式

GET URL-Params

POST Form-Data

POST RequestBody(JSON形式)

POST Mulitpart

応答方式

統合応答モデル

5.5補助工具

文字列処理:apache common-lang 3

時間日付処理:joda-time

JSON処理:Gson,Fastjson

コレクション拡張ツール:guava

ファイルとストリーム処理:commons-io

コーデック:commons-codec

推奨:オープンソースコンポーネント

を可能な限り使用する
5.6コード注記

クラス、インタフェース、列挙最上位注釈

インタフェースメソッド注釈

静的方法注釈

開示方法注釈

クラスの属性フィールド注釈

定数注記

は、以上の

に限定するものではない.
6.コード制御仕様
6.1引き抜き原則

強制

毎日作業開始

約定

提出前に

を引き出す

6.2提出原則

強制

コミットコードは、構築に成功する必要があります(たとえば、コンパイル、パッケージ化)

コミットコードは完全でなければならない(例えば、ファイルを少なくする)

コミットコードは、ローカルテンポラリファイル(target,logs,.idea,*.iml,distなど)

に無視する必要があります.

約定

機能コミット

を完了

修正Bug修正提出

競合解決コミット

毎日終了仕事提出

6.3注釈の提出

強制

中国語記入注釈

注記今回の提出変更を反映する

.

約定

注記接頭辞の追加を説明し、接頭辞は以下の

である.

[作成]通常、プロジェクト作成時に

を使用します.

[新規]

[修正]

[削除]

[修復-number]修復Bug使用、numberはBug番号

7.構築規範
7.1共通コンポーネント構築仕様

構築出力コンポーネントパッケージ

出力コンポーネントソースパケット

を構築する.

構築は、会社のプライベート倉庫

に公開された.
7.2サービスコンポーネント構築規範

サービスコンポーネントパッケージの名前:{コンポーネント名}-{バージョン番号}-bin.zip

エンジニアリングルートディレクトリに出力dist/{コンポーネント名}-{yyyyyMMddHH}ディレクトリ

を構築する.