2021年9月15號更新
【強制】前后端交互的 API，需要明確協議、域名、路徑、請求方法、請求內容、狀態碼、響應體。
說明：
1） 協議：生產環境必須使用 HTTPS。
2） 路徑：每一個 API 需對應一個路徑，表示 API 具體的請求地址：
a） 代表一種資源，只能為名詞，推薦使用復數，不能為動詞，請求方法已經表達動作意義。
b） URL 路徑不能使用大寫，單詞如果需要分隔，統一使用下划線。
c） 路徑禁止攜帶表示請求內容類型的后綴，比如".json",".xml"，通過 accept 頭表達即可。
3） 請求方法：對具體操作的定義，常見的請求方法如下：
a） GET：從服務器取出資源。
b） POST：在服務器新建一個資源。
c） PUT：在服務器更新資源。
d） DELETE：從服務器刪除資源。
4） 請求內容：URL 帶的參數必須無敏感信息或符合安全要求；body 里帶參數時必須設置 Content-Type。
5） 響應體：響應體 body 可放置多種數據類型，由 Content-Type 頭來確定
【強制】服務端發生錯誤時，返回給前端的響應信息必須包含 HTTP 狀態碼，errorCode、
errorMessage、用戶提示信息四個部分。
說明：四個部分的涉眾對象分別是瀏覽器、前端開發、錯誤排查人員、用戶。其中輸出給用戶的提示信息
要求：簡短清晰、提示友好，引導用戶進行下一步操作或解釋錯誤原因，提示信息可以包括錯誤原因、上
下文環境、推薦操作等。 errorCode：參考附表 3。errorMessage：簡要描述后端出錯原因，便於錯誤排
查人員快速定位問題，注意不要包含敏感數據信息。
正例：常見的 HTTP 狀態碼如下
1） 200 OK: 表明該請求被成功地完成，所請求的資源發送到客戶端。
2） 401 Unauthorized: 請求要求身份驗證，常見對於需要登錄而用戶未登錄的情況。
3） 403 Forbidden：服務器拒絕請求，常見於機密信息或復制其它登錄用戶鏈接訪問服務器的情況。
4） 404 Not Found: 服務器無法取得所請求的網頁，請求資源不存在。
5） 500 Internal Server Error: 服務器內部錯誤
【強制】對於需要使用超大整數的場景，服務端一律使用 String 字符串類型返回，禁止使用Long 類型。
說明：Java 服務端如果直接返回 Long 整型數據給前端，JS 會自動轉換為 Number 類型（注：此類型為雙
精度浮點數，表示原理與取值范圍等同於 Java 中的 Double）。Long 類型能表示的最大值是 2 的 63 次方
-1，在取值范圍之內，超過 2 的 53 次方 (9007199254740992)的數值轉化為 JS 的 Number 時，有些數
值會有精度損失。擴展說明，在 Long 取值范圍內，任何 2 的指數次整數都是絕對不會存在精度損失的，所
以說精度損失是一個概率問題。若浮點數尾數位與指數位空間不限，則可以精確表示任何整數，但很不幸，
雙精度浮點數的尾數位只有 52 位。
反例：通常在訂單號或交易號大於等於 16 位，大概率會出現前后端單據不一致的情況，比如，"orderId":
362909601374617692，前端拿到的值卻是: 362909601374617660
【推薦】不要在視圖模板中加入任何復雜的邏輯。
說明：根據 MVC 理論，視圖的職責是展示，不要搶模型和控制器的活。
【推薦】任何數據結構的構造或初始化，都應指定大小，避免數據結構無限增長吃光內存。
【推薦】及時清理不再使用的代碼段或配置信息。
說明：對於垃圾代碼或過時配置，堅決清理干凈，避免程序過度臃腫，代碼冗余。
正例：對於暫時被注釋掉，后續可能恢復使用的代碼片斷，在注釋代碼上方，統一規定使用三個斜杠(///)
來說明注釋掉代碼的理由。如：
public static void hello() {
/// 業務方通知活動暫停
// Business business = new Business();
// business.active();
System.out.println("it's finished");
}
專有名詞解釋
- POJO（Plain Ordinary Java Object）: 在本規約中，POJO 專指只有 setter/getter/toString 的
簡單類，包括 DO/DTO/BO/VO 等。- DO（Data Object）：阿里巴巴專指數據庫表一一對應的 POJO 類。此對象與數據庫表結構一
一對應，通過 DAO 層向上傳輸數據源對象。- DTO（Data Transfer Object）：數據傳輸對象，Service 或 Manager 向外傳輸的對象。
- BO（Business Object）：業務對象，可以由 Service 層輸出的封裝業務邏輯的對象。
- Query：數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用
Map 類來傳輸。- VO（View Object）：顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。
- AO（Application Object）: 阿里巴巴專指 Application Object，即在 Service 層上，極為貼近
業務的復用代碼。- CAS（Compare And Swap）：解決多線程並行情況下使用鎖造成性能損耗的一種機制，這是
硬件實現的原子操作。CAS 操作包含三個操作數：內存位置、預期原值和新值。如果內存位
置的值與預期原值相匹配，那么處理器會自動將該位置值更新為新值。否則，處理器不做任何
操作。- GAV（GroupId、ArtifactId、Version）: Maven 坐標，是用來唯一標識 jar 包。
- OOP（Object Oriented Programming）: 本文泛指類、對象的編程處理方式。
- AQS（AbstractQueuedSynchronizer）: 利用先進先出隊列實現的底層同步工具類，它是很多上
層同步實現類的基礎，比如：ReentrantLock、CountDownLatch、Semaphore 等，它們通
過繼承 AQS 實現其模版方法，然后將 AQS 子類作為同步組件的內部類，通常命名為 Sync。- ORM（Object Relation Mapping）: 對象關系映射，對象領域模型與底層數據之間的轉換，本
文泛指 iBATIS, mybatis 等框架。- NPE（java.lang.NullPointerException）: 空指針異常。
- OOM（Out Of Memory）: 源於 java.lang.OutOfMemoryError，當 JVM 沒有足夠的內存
來為對象分配空間並且垃圾回收器也無法回收空間時，系統出現的嚴重狀況。- 一方庫: 本工程內部子項目模塊依賴的庫（jar 包）。
- 二方庫: 公司內部發布到中央倉庫，可供公司內部其它應用依賴的庫（jar 包）。
- 三方庫: 公司之外的開源庫（jar 包）
前言
以前對這塊並沒有去具體了解，就是簡單的了解了一些小demo的開發流程。這次對這塊寫個記錄。
后端
分享一篇微信上的文章：《優秀的項目代碼是怎樣分層的》，這是來自B站一個Up主codesheep的文章。
還有一篇文章：《Java命名規范》https://mp.weixin.qq.com/s/fY9crroOviqmstTZZIM5Ew
接下里其實見得最多的就是阿里的這張圖以及阿里的解釋
圖片解釋：
• 開放 API 層：可直接封裝 Service 接口暴露成 RPC 接口；通過 Web 封裝成 http 接口；網關控制層等。
• 終端顯示層：各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染，JS 渲染，JSP 渲染，移
動端展示等。
• Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
• Service 層：相對具體的業務邏輯服務層。
• Manager 層：通用業務處理層，它有如下特征：
1） 對第三方平台封裝的層，預處理返回結果及轉化異常信息，適配上層接口。
2） 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。
3） 與 DAO 層交互，對多個 DAO 的組合復用。
• DAO 層：數據訪問層，與底層 MySQL、Oracle、Hbase、OB 等進行數據交互。
• 第三方服務：包括其它部門 RPC 服務接口，基礎平台，其它公司的 HTTP 接口，如淘寶開放平台、支
付寶付款服務、高德地圖服務等。
• 外部數據接口：外部（應用）數據存儲服務提供的接口，多見於數據遷移場景中。分層領域模型規約：
• DO（Data Object）：此對象與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。
• DTO（Data Transfer Object）：數據傳輸對象，Service 或 Manager 向外傳輸的對象。
• BO（Business Object）：業務對象，可以由 Service 層輸出的封裝業務邏輯的對象。
• Query：數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類
來傳輸。
• VO（View Object）：顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。
盡量對整個Maven工程結構進行分層拆分，增加工程的可擴展性，實現高內聚低耦合的開發要求。
例子：圖中將工程拆分為一個父工程和三個子工程：
•CancerCenter：父工程，只有POM的約束，無具體業務代碼。
•CancerCenter_Common：通用工程，最下層依賴，包含utils，model，exception等整個項目的公共模塊，提供整個項目的基礎支撐。
•CancerCenter_Service：業務工程，向下依賴於Common，向上被Web依賴，包含service和mapper，是整個項目的核心業務。
•CancerCenter_Web：Web工程，向下依賴於Service，對外提供接口，包含接口、配置等Web項目獨有的模塊。
前端
1.資源路徑編譯規則
默認情況下，vue-loader 使用 css-loader 和 Vue 模版編譯器自動處理樣式和模版文件。在編譯過程中，所有的資源路徑例如 、background: url(...) 和 @import 會作為模塊依賴。
路徑的編譯規則如下：
如果路徑是絕對路徑，會原樣保留；
如果路徑以 . 開頭，將會被看作相對的模塊依賴，並按照你的本地文件系統上的目錄結構進行解析；
如果路徑以 @ 開頭，也會被看作模塊依賴。如果你的 webpack 配置中給 @ 配置了 alias，這就很有用了。所有 vue-cli 創建的項目都默認配置了將 @ 指向 /src；
2.build目錄和config目錄
build 目錄下存放的是 webpack 的配置文件；
config 目錄下存放的是與項目構建相關的常用的配置選項、變量；
通常情況下，除非要配置 webpack 的 loader 或者 插件，否則，你應該優先嘗試更改 config 目錄下的文件；
3.src目錄
根據項目結構的核心思想，src的目錄結構將以業務功能划分。
注意事項：
I . 項目的業務代碼應該從 src/app/ 目錄開始；
II . src/common/ 的子目錄中，在深度上的層級結構應該是盡量扁平的，不應該有很深的層級結構；如果 src/common/ 中的目錄樹 與 src/app/ 中的目錄樹在深度上有十分相似的層級結構，則就表示你應該重新考慮 src/common/ 中的資源是否是真的需要被共享的資源，被共享的資源的目錄層級結構應該是盡可能扁平的；對於不必共享的資源，應該放在 src/app/ 下相應的目錄結構中；
III . src文件或文件夾的組成分為3種。直接在src目錄下的vue文件是工程內直接於業務相關頁面文件；components文件夾下是組件文件；其他文件夾是一些活動和主業務耦合性不大的文件。
4.static目錄
static目錄可以添加任何資源，如：圖片、代碼 等等。不過工程內圖片大多存放七牛，static/project.js存放公共函數
微信文章：https://mp.weixin.qq.com/s/mNWc2tJWZlxJkKQh-kNpVg；可以參考一下，做個簡單的前端認識。
下圖來自於該篇文章。
最后
平時沒事可以看看《阿里開發手冊》，有助於對Java項目的開發流程的認識以及對規范的認識，可以有個良好的開發習慣。