(擬)研發中心軟件設計流程與規範

(擬)研發中心軟件設計流程與規範

1. 需求分析規劃整理

   • 後端需參與，以便確認用戶的第一需求

     有時候一個簡單的需求通過多方傳遞以後，會失真，致使多花力氣。

2. 版面設計（內部初審&用戶終審）

3. 建模&mockAPI（推薦EoLinker）[1]

   • 建模相當重要，不管是前端仍是後端亦或是數據，沒有建模或者不合理的建模會影響整個團隊的開發效率

     • 數據庫建模（此模式適用於多後端開發） 如圖：
       • 數據庫建模讓開發再也不糾結於字段定義
     • 實體類建模（此模式通用於各類開發，簡單高效快速，適合敏捷和迭代）

       經過代碼生成器構建一套後端代碼，同時生成數據庫，支持導出數據庫到EoLinker或Doc文檔

   • mockAPI——鏈接先後端開發的橋樑，真正把先後端從各自的自測中解放出來，提升溝通效率。

     mockAPI不只定義了前端請求URL，並且也定義了後端的模塊分組、功能分組等，方面快速構建團隊生產體系和先後端的生產目標

4. 任務規劃

   將軟件研發的工做拆分，利用甘特、燃盡或其餘的輔助工具管理軟件的研發週期，方便及時的對項目狀態進行調整

   • 思惟導圖讓參與者快速瞭解項目
   • 任務管理讓開發者瞭解項目的開發節點，合理安排本身的時間

5. 代碼框架選型&代碼編寫

   • JavaDoc MVC極速開發模板JavaDoc
   • 代碼規範（基礎）
     • 命名規範
       • 數據庫
         • 表名、字段名稱使用全小寫蛇形命名
       • Java
         • 包名、字段名、方法名使用小駝峯命名
         • class interface enum等使用大駝峯命名
         • 基本常量請封裝到interface中使用全大寫蛇形命名，避免使用static
         • 組合常量請封裝到enum中使用全大寫蛇形命名
     • MVC的分層規範
       • controller只負責頁面跳轉和數據傳遞，儘量不要把過多的業務邏輯摻雜至此
       • service是具體業務邏輯，由controller調用執行具體邏輯（數據庫各類操做的有機結合）
       • dao是數據庫操做的抽響映射，不作贅述
     • 註釋規範

       請參照JavaDoc協議規範，對於重要的邏輯部分和功能務必作到行行註釋，以確保此項目任何人可接手。關於JavaDoc規範，請參看上述模板，此模版也是急速開發模版，足夠精簡。

---

• 先後端聯合開發標準化規範樣例

  HTTP_API

  • url
    • /模塊名稱/功能名稱/操做名稱
  • 請求方式
    • Rest風格
      • 查詢操做GET方法，URL傳參
      • 添加操做POST方法，JSON傳參
      • 刪除操做DELETE方法，url傳參
      • 修改操做PUT方法，JSON傳參
    • 簡易風格（推薦使用）
      • 查詢刪除操做GET方法，URL傳參
      • 保存修改操做POST方法，JSON傳參
  • 請求頭
    • Access-Token: 單點登陸認證
  • 請求體
    • 參看請求方式
    • 利用工具構建統一的請求格式
  • 響應頭
    • 暫無
  • 響應體
    • JSON格式
    • 利用工具構建統一的請求格式

  以此規範爲先後端開發的標準，先後端開發只須要對接此文檔便可

  • 詳情參看 [1]

---

• 構建一體化的測試環境

  • 根據項目的具體狀況能夠針對不一樣等級的業務作不一樣的測試
    • 單元測試、白盒測試
    • 黑盒測試、集成測試（必要）
    • 對拍測試（健壯性穩定性測試）
  • 後端測試功能
    • 先後聯測
    • 後端API快速測試 詳情參看 [[1]][[1]]

---

• 代碼管理、版本控制與發佈（推薦Git）

  • 多人協做開發
    • 分支管理模式
      • 任何人不容許在主分支上開發
      • 各自維護各自分支
      • 功能代碼合併請PULL REQUEST
    • review審覈模式
      • 在分支上提交的代碼須要有人審覈經過以後才能進入分支
        • 代碼審覈
        • 測試審覈
  • 代碼註釋習慣
    • 可參考標準JavaDoc
    • 關鍵業務邏輯行行註釋