第 1 章 第一部分 軟件項目管理

1.1 傳統(tǒng)的 軟件項目管理流程

可行性分析階段：可行性分析報告
? 需求階段：需求說明書、需求規(guī)格（分析）說明書
? 設計階段：概要設計說明書、詳細設計說明書
? 開發(fā)階段：軟件開發(fā)框架、重點難點攻關(guān)
? 測試階段：測試用例、測試報告
? 運維階段：運維手冊、運維報告
? 運營階段：運營手冊、運營報告
小結(jié)：
測試工作 簡述： 軟件 的實際承載能力， 例如Tomcat實際承受 并發(fā)350 、 獨立接口 和集成階段測試 。
運維工作 簡述：7*24 小時 服務，每天系統(tǒng)的報告，異常數(shù)量連接數(shù) 。
運營工作 簡述 ： 生產(chǎn)環(huán)境出問題怎么解決，需要完整解決系統(tǒng)問題 的 流程，統(tǒng)計業(yè)務量 、需求 指 標量 報告。

1.2 敏捷 的軟件項目管理流程

? 需求階段：產(chǎn)品需求說明書
? 設計階段：流程設計、數(shù)據(jù)庫設計、接口設計
? 開發(fā)階段：軟件開發(fā)框架、重點難點攻關(guān)
? 測試階段：測試用例、測試報告
? 運維階段：運維手冊、運維報告
? 運營階段：運營手冊、運營報告
小結(jié)：
對于 復雜度高的項目需要一個穩(wěn)定的團隊，大家的思路和框架流程都熟悉 ；
對于 簡單的項目增刪改查，這時需要的 只是 簡單的人員

1.3 項目 評審

? 需求評審：對需求進行質(zhì)詢，明確需求內(nèi)容、范圍
? 設計評審：確認設計方案、重點難點解決方案，依據(jù)評審結(jié)果進行開發(fā)工作量評估
? 測試用例評審：確認用例覆蓋度
小結(jié)：
項目真正 的目 、 明確需求 、 內(nèi)容 、范圍 、 并 構(gòu)建最終 明確文檔（ 只可 微調(diào)） 。
會議評審 主要 對于 每個人的對于 方案 的解決方法，
解決 需求確認，評審確認后的時間概念：選擇團隊中的某一個人（ 中間 人只做參考-中級程序員） ， 根據(jù)中間點來確定工作量的完成 時間 。
溝通 交流培育的成本，五個人和十個人不一定 時間 就能提前 ， 技術(shù)是細節(jié) 重要 的是 測試 和評審

1.4 測試流程

? 開發(fā)人員自測、交叉測試
? 第一輪測試
? 第二輪測試
? UAT （用戶驗收）測試
? 準生產(chǎn)環(huán)境測試
? 生產(chǎn)環(huán)境驗證
小結(jié) ：
第一輪： 是代碼提交測試
第二輪：測試 人員 ? 集成測試 ?
主要 解決 版本 問題 等git 的版本控制根據(jù)我們的環(huán)境來定義我們的版本，例如truck 版本
測試 人員發(fā)布版本 ? UAT測試 ? 內(nèi)網(wǎng)測試
準生產(chǎn) 環(huán)境 ? 和 上產(chǎn)環(huán)境時 保持 一致 ? 生產(chǎn)環(huán)境驗證
注意 ： 測試環(huán)節(jié)是保證系統(tǒng)安全上線的最關(guān)鍵環(huán)節(jié)，每一輪測試都需要提供獨立的測試環(huán)境。

1.5 上線 流程

? 產(chǎn)品人員提出上線申請
? 測試人員將代碼部署至 UAT 環(huán)境
? 產(chǎn)品人員進行 UAT （用戶驗收）測試
? 運營人員進行準生產(chǎn)環(huán)境測試
? 運營人員進行生產(chǎn)環(huán)境驗證

第 2 章 軟件 架構(gòu)設計

2.1 業(yè)務架構(gòu) 分解

2.2 技術(shù) 架構(gòu) —部署 要求

? 高可用架構(gòu) 的重要性
? 數(shù)據(jù) 的前瞻性 提前 備份防范
? 安全 十分總要 、例如 ：增加安全組 進行 安全掃描才能上線
? 安全 漏洞：框架漏洞 黑客 腳本，
? 根據(jù) 業(yè)務線選擇 上線時間
? 各類數(shù)據(jù) 緩存要求
緩存小結(jié) ：
字典 類數(shù)據(jù) 采用本地緩存效率 更高
用戶數(shù)據(jù)動態(tài) 數(shù)據(jù)采用 分布式 緩存
其余 放在 表結(jié)構(gòu) 等定長 文本 放入 mysql

2.3 技術(shù)架構(gòu)—分布式 CAP 理論

? 一致性（ C ）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）
? 可用性（ A ）：在集群中一部分節(jié)點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
? 分區(qū)容忍性（ P ）：一個數(shù)據(jù)項復制到多個節(jié)點上，那么出現(xiàn)分區(qū)之后，這一數(shù)據(jù)項就可能分布到各個區(qū)里

應用 服務器集群架構(gòu)

業(yè)務 拆分

分布式 數(shù)據(jù)的一致性解決 方法 ：
每 500 萬 一個庫 群組 做分庫
冷熱 數(shù)據(jù)的區(qū)分和隔離 時間 的分片原則 每一小時 就會生成一個庫

基于 所有的東西都拆分開

2.4 技術(shù) 架構(gòu) —— 架構(gòu)設計 誤區(qū)

一味追隨大公司的解決方案
為了技術(shù)而技術(shù)
企圖用技術(shù)解決所有問題

第 3 章 技術(shù)雜談

3.1 技術(shù) 雜談 ——jvm 調(diào)尤

? jvm 優(yōu)化
? j vm 學習 方向
? jvm 邏輯 問題

3.2 技術(shù)雜談—內(nèi)存參數(shù)設置

vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
-vmargs 說明后面跟隨的是JVM的參數(shù)設置
-Xms128m JVM初始分配的堆內(nèi)存
-Xmx512m JVM最大允許分配的堆內(nèi)存，按需分配
-XX:PermSize=64M JVM初始分配的非堆內(nèi)存
-XX:MaxPermSize=128M JVM最大允許分配的非堆內(nèi)存，按需分配

3.3 技術(shù)雜談—數(shù)據(jù)庫的四個隔離級別

? 數(shù)據(jù)庫操作面臨的問題：臟讀、不可重復讀、幻讀、更新丟失。
? 為了避免上面出現(xiàn)的幾種情況，在標準 SQL 規(guī)范中，定義了 4 個事務隔離級別：
? 讀未提交（ Read Uncommitted ）
? 讀已提交（ Read Committed ）
? 可重復讀取（ Repeatable Read ）
? 序列化（ Serializable ）

3.4 技術(shù)雜談— Spring 中的事務傳播特性

? PROPAGATION_REQUIRED: 如果存在一個事務，則支持當前事務。如果沒有事務則開啟
? PROPAGATION_SUPPORTS: 如果存在一個事務，支持當前事務。如果沒有事務，則非事務的執(zhí)行
? PROPAGATION_MANDATORY: 如果已經(jīng)存在一個事務，支持當前事務。如果沒有一個活動的事務，則拋出異常。
? PROPAGATION_REQUIRES_NEW: 總是開啟一個新的事務。如果一個事務已經(jīng)存在，則將這個存在的事務掛起。
? PROPAGATION_NOT_SUPPORTED: 總是非事務地執(zhí)行，并掛起任何存在的事務。
? PROPAGATION_NEVER: 總是非事務地執(zhí)行，如果存在一個活動事務，則拋出異常
? PROPAGATION_NESTED ：如果一個活動的事務存在，則運行在一個嵌套的事務中 . 如果沒有活動事務 , 則按 TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行

3.5 技術(shù)雜談—程序員的職業(yè)生涯

? 1-3 年，初級：做好增刪改查功能，熟練使用開發(fā)框架，培養(yǎng)良好的思維習慣
? 3-5 年，中級：能夠完成簡單系統(tǒng)的設計，獨立完成系統(tǒng)的開發(fā)
? 5-10 年，高級：深入理解技術(shù)原理，配合架構(gòu)師完成架構(gòu)落地，解決重點難點問題
? 10 年以上，架構(gòu)師：項目評審、架構(gòu)設計、技術(shù)選型、重點難點分析、技術(shù)攻關(guān)、溝通與協(xié)調(diào)、提升理論知識

第 4 章 指出 問題

接口 流程： 寫完代碼 要給接口 方 提供可用完成的接口 。
評估 工作： 項目的評估到個人工作的評估，工作 量 評估 范圍 取決 于中間 評估人。
任務 完成： 每個人 接任務的時候要清除自己的工作目標必須有時間的約束 。
工作 范圍： 說任何話 做任何事都要有范圍的，不然都是錯的 。
測試 人員：測試 人員是 最重要的 環(huán)節(jié) ，決定項目能否上線的必須流程。

總結(jié)

以上是生活随笔為你收集整理的宜信（刘志波）技术培训的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。