軟件開發工做過程當中的一些總結

聲明

• 本文還在不斷完善中，更多的是但願能引發思考，不要照搬。
• 首次發表：www.youmeek.com/java-sofawa…

核心

• 盡最大可能幫助企業更加高效協做，以更好的數字化體驗吸引客戶，同時讓維護更加容易、低廉。
• 每一個公司的組織結構都有其特色，本文沒法直接套用，須要根據其結構優化調整
• 持懷疑態度對待任何問題，包括本文任何字眼，多思考。
• 有序、規範化不等同於要失去靈活，它們之間有一個度，而咱們再尋找那個度、平衡

理念

• 敏捷：快速響應市場的變化，爭取活下來，再談盈利。
• DevOps：開發運維一體化，目標一致，高效溝通、配合。
• 測試驅動開發（TDD）：有助於作更好的開發質量，協助開發量化指標，從而有更高效的響應。
• 無狀態：保證 API 接口可伸縮性
• 功能開關：開關多樣化能夠儘量避免回滾和屢次發佈
• 分享精神，促進溝通，凝聚力根本（必須）
  • 開發總結，文章分享（必須）
  • 優質文章，開發分享心得
  • 圖書分享
  • 教程分享
  • Switch 遊戲分享

會議

• 項目啓動會
  • 需求概要
  • 利益關係
  • 主要目標
• 每日站立會（15 分鐘）
  • 前一天工做內容
  • 遇到什麼困難
  • 今天計劃工做內容
• 項目交接演示會
  • 整體功能點描述
  • 主流程演示
  • 具體功能模塊演示
  • 客戶反饋
  • 首次交付的開始也是真正考驗的開始
• 項目回顧會
  • 需求、分析、設計、演化、交付過程當中各個心得
  • 技術分享

過程文檔

• 產品
  • 產品說明書（Markdown）
  • 產品需求文檔（Markdown）
  • 產品操做手冊（Markdown）
• 開發
  • 項目設計文檔（包括概要、詳細），突出流程圖，關係圖，結構圖，文字描述儘量少。（Markdown）
  • 數據庫實體關係圖（表結構關係 ER 圖）（StarUML）
  • 詳細表結構設計（協同 Excel）
  • API 接口（Swagger API、YAPI）
  • 測試用例（Markdown）

團隊常見問題（儘量避免）

• 目標不明確
• 人員不穩定
  • 增長人手並不能百分百增長效率，除非是有計劃的調整，不會影響到現有團隊成員的進度。
• 工位不集中（借調）
• 有各種緣由的干擾
• 多種不一樣類型的需求併發一塊兒處理
• 需求不夠細化
• 團隊角色模糊
• 需求變動
  • 沒法避免的事實，它也是讓軟件不斷退化的主要緣由
  • 儘量 持續有效的溝通 是避免不斷返工的最好辦法之一
  • 變動發生得越早，風險越小
• 測試工做在開發結束後有大量堆積
• 每一個工程師在溝通能力、技能水平、主動性、服從性、一致性、責任心上都有着巨大差別，每一個人都是須要特殊對待。
• 與外部溝通不暢
  • 上游協做：客戶
  • 下游協做：運維
  • 交叉協做：其餘開發團隊

需求、任務、問題的跟蹤

• TAPD
  • 看板
  • TAPD 敏捷全生命週期項目
• JIRA

---

開發環境搭建（統一全部版本）

• JDK
• IntelliJ IDEA
• Git
• Maven
• Node
• MySQL
• MyCAT
• 中間件版本
  • Redis
  • RabbitMQ
  • Kafka
  • Zookeeper
• 大數據
  • Flink
  • Hadoop
• 自動化
  • 嚴格禁止漏提交引發的沒法構建行爲
  • Gitlab
  • Jenkins
  • Sonar
  • Nexus
• 部署
  • CentOS
  • Zabbix
  • Nginx
  • ELK
  • Ansible
  • Docker（Portainer、Rancher、K8S）
• 開發系統
  • macOS（黑蘋果優先）
  • Windows 10
  • Ubuntu
• 硬件（我的提供）
  • 便攜投影儀
  • MacBook Pro

測試環境搭建

• 數據庫
  • 清洗我的隱私數據（密碼、身份證、手機號、郵箱地址、居住地址）
  • 數據同步規則、同步週期
• 自動化測試
  • TestNG + Selenium，UI 自動化
  • TestNG + Http，作接口自動化
• 壓力測試
  • Gatling + Maven（優先）
  • JMeter

運維生產環境搭建

• 服務器監控（Zabbix）
• 跳板機
• 防火牆（端口）
• 基礎服務（版本與開發環境一致）

---

項目流程（路線）

• 需求
  • 明確利益關係，特別是多方利益
    • 多方利益的狀況，儘量先與每一個利益方單獨溝通，遇到矛盾須要再溝通和劃分利益優先級
    • 多個利益方一塊兒溝通很容易獲得更多需求，不易於需求把控
    • 對於 信息透明化 的點，須要你們自行把控
  • 持續有效的溝通
  • 調研、寫需求、畫原型
  • 劃分需求優先級，明確迭代週期
  • 標出不肯定域
  • 客戶需求確認
  • 召集：需求評審
• 項目組長
  • 根據需求寫系統設計說明書（召集評審）
  • 細化主要開發任務（TAPD）
  • 召集：估算撲克
• 前端開發
  • 細化前端需求任務（TAPD）
  • 根據需求和原型實施前端組件
  • 先後端聯調
  • 冒煙測試，確保主流程
  • 主流瀏覽器性能調優
  • 召集：代碼評審
• 後端開發
  • 細化後端需求任務（TAPD）
  • 根據需求、原型、系統設計說明書開發功能
  • 監控埋點
  • 先後端聯調
  • 冒煙測試，確保主流程
  • 單元測試（優先保證主流程：新增 + 刪除 + 單個查詢 + 分頁查詢的單元測試）
  • 微基準測試
  • 接口壓力測試
  • 測試人員測試出的功能：必須寫單元測試
  • 召集：代碼評審、SQL 審查
• 測試開發
  • 細化測試需求任務（TAPD）
  • 根據需求寫接口自動化測試用例（優先保證主流程）
  • 根據界面寫 UI 自動化測試用例（優先保證主流程）
  • 冒煙測試，確保主流程
  • 迴歸測試
  • 壓力測試
  • 召集：測試報告分析和反饋
• 運維部署
  • 根據系統設計說明書，預先調研部署結構，部署腳本，網絡評估，系統監控
  • 自動化部署環境準備
  • 自動化測試環境準備
  • 壓力測試環境準備
  • 藍綠部署支持
  • 金絲雀發佈支持（儘量採用隨機樣本）
  • 召集：監控報告分析和反饋
  • 升級回滾設計
    • 開關設計的回滾
    • 整個環境回滾
    • 回滾腳本設計
    • 數據庫補丁回滾設計

---

接口壓力測試

• 上層 API 接口：95% Line 控制在 3 秒之內
• 底層 API 接口：95% Line 控制在 300 毫秒之內
• JVM 異常監控（VisualVM、JProfile）

源代碼管理

• Gitlab
• Git flow
• 項目版本號：SemVer 標準

認證

• OAuth 2.0 協議

細化監控、反饋

• 服務器監控
• 應用程序監控
• 流計算
• 日誌監控
• 對錯誤進行響應
• dashboard
• 郵件/IM 通知

容量規劃

• 長期容量規劃
• 短時間容量規劃

Wiki 管理

• 有道雲協做
• 騰訊文檔
• hexo-theme-Wikitten

安全

• SQL 注入
• CSRF 跨站請求僞造
• XSS 跨站腳本
• 密碼加鹽再加密
• OAuth 2.0
• 對稱加密（AES） + base64
• 非對稱加密（RSA） + 簽名和驗籤方式
  • 請求參數
  • 按照第一個字符的鍵值 ASCII 碼遞增排序（字母升序排序），若是遇到相同字符則按照第二個字符的鍵值 ASCII 碼遞增排序，以此類推。
  • 將排序後的參數與其對應值，組合成 「參數=參數值」 的格式，而且把這些參數用 & 字符鏈接起來，此時生成的字符串 爲待簽名字符串，相似格式：aa=11&bb=22&cc=33
  • 簽名：安全BASE64(SHA256WithRSA(代簽名字符串 + 私鑰))

後端開發 KPI 設定

• 分爲 A、B、C、D 四個等級，採用加分、減分計算方式
• C
  • 正常狀況
• D
  • 有生產事故
    • 超過 1 小時沒法恢復，必然 D
    • 有財務風險，必然 D
    • 1 個小時內恢復
      • 無投訴，無財務風險，不影響
      • 有投訴，最高加分到 B
  • 測試反饋報告顯示質量低
    • 因爲我的緣由，超過 30% 的功能須要返工，必然 D
    • 缺乏核心主流程單元測試，必然 D
  • 有我的緣由的異常，阻礙其餘人、小組進度
    • 每個月累計阻礙累加超過一天（7 小時），必然 D
    • 每個月累計超過半天（4 小時），最高加分到 B
• B
  • 小組類優秀文章（沒有減分行爲前提）
  • 小組類優秀文章定義：組內成員打分，去掉最高、最低分取平均分
• A
  • 公司類優秀文章（沒有減分行爲前提）
  • 公司類優秀文章定義：公司開發主管打分，去掉最高、最低分取平均分
  • 主動改良系統瓶頸性能（提升 30%），並通過壓力測試的考驗，各開發主管審覈代碼。（有任何減分行爲不影響）