一、 培訓簡介
無數軟件企業及其研發團隊都面臨著,大量初級程序開發人員低質量軟件開發帶來的嚴重問題,即使那些工作多年的高級程序員也存在著對提高軟件設計質量認識不深的問題。正是由于以上的問題,造成許多公司對運行了多年的核心業務,運行維護成本越來越高,卻不能更換、一直維護下去的惡性循環。
如何通過培訓,切實有效地提高員工設計開發水平,從而有效地改善軟件設計質量,成為越來越多的軟件企業迫切需要解決的問題。
本課程不僅在講解高質量軟件設計的理論知識,更關鍵是將這些知識投放到各個真實的設計場景中。在這些場景中,我們可以看到我們要面對的設計難題,通過對設計難題的深入剖析,尋找問題的根源,對癥下藥,從而制訂出正確的設計方案。
不僅如此,本課程的案例選取了許多在需求變更中不斷變化的設計過程,從而用慢動作的手法展現了,最初的需求與設計是怎樣,第一次變更的設計,第二層變更的設計,第三次變更的設計……這樣的過程展示了,如何在需求變更的過程中,通過每一次正確的設計,不讓軟件退化,來保證高質量的軟件設計。
本課程首先深入剖析軟件質量下降的根源,提出重構是軟件變更中保持高質量的必然,講解如何運用“兩頂帽子”的方式應對變更,拒絕腐化。站在實戰的角度講解高質量軟件設計的“小步快跑”過程。接著,用真實案例講解已經代碼腐化的遺留系統是如何通過“軟件重構七步曲”,由簡入深、循序漸進地重構一個大系統。課程的最后,更加深層次地講解軟件重構面臨的難題,以及有效地解決之道。
本課程注重實戰,采用案例貫穿的方式,收集了大量的真實案例,針對項目過程中技術人員常犯的錯誤進行了匯總與研討,并最終形成培訓教程。通過大量的真實案例,詳細地介紹了軟件設計過程需要注意的要點以及難點,這些知識都是講師十幾年經驗的總結。本次課程1/3時間講解核心思想,1/3時間動手重構實踐,1/3點評分析總結。
二、 學員基礎
學員學習本課程應具備下列基礎知識:
l. 目前正在面臨復雜遺留系統,必須需要維護和重構
2. 具有面向對象的基本概念,熟悉基本設計模式。
三、 課程對象
初中高級工程師、企業架構師、軟件設計師等;
各類軟件研發中心的軟件設計師、架構師、項目經理、技術總監、質量部門經理。對于重構技術懷有疑問和困惑,需要梳理解答的團隊和個人,效果最佳。
代碼重構 | 設計重構 | 軟件腐爛監控 | 重構管理 | |
程序員 | 必須精通 | 需要了解 | 需要了解 | 需要了解 |
設計師 | 必須精通 | 必須精通 | 需要了解 | 需要了解 |
架構師 | 必須精通 | 必須精通 | 必須精通 | 必須精通 |
數據庫工程師 | 需要了解 | 需要了解 | / | / |
質量管理 | / | / | 必須精通 | 必須精通 |
管理者 | / | / | 需要監控 | 需要了解 |
四、 課程安排
第1-2天 | 軟件設計模式授課內容 |
第一部分 高質量軟件設計 | |
第一章 什么是高質量的軟件設計 |
情景劇:軟件設計焦慮癥 1. 上次的設計太糟糕了,痛下決心以后要好好設計 2. 再次進行軟件設計時卻不知道該怎樣設計 1) 思考了很多,不知如何下手 2) 需求一變更,重新回到了糟糕的狀態 探討:如何進行高質量的軟件設計 什么是高質量的軟件設計 1. 軟件的質量保證:內部質量與外部質量 2. 高質量軟件設計的標準:易讀、易于維護、易于變更 |
第二章 軟件設計原則 |
易于閱讀: 1. 規范代碼、編寫注釋與表明動機 案例:代碼編寫范例與簡便易行的方法 2. 領域驅動設計 易于維護與變更 1. 互聯網+帶來的挑戰 1) 系統需要不斷地技術升級與改造 2) 傳統行業必須向互聯網轉型 3) 但技術變革不是換零件那么簡單 4) 剖析應對技術變革的方案 2. 案例講解軟件設計原則 1) 低耦合 a. 依賴反轉原則(DIP) 案例:購票業務類與數據訪問類 b. 開放-封閉原則(OCP) 案例:需求變更與可擴展點設計 案例:Square/Circle的解決方案 c. 里氏替換原則(LSP) 案例:Rectangle/Square的問題 案例:查詢參數傳遞類的問題 2) 高內聚 案例:評審系統的設計 a. 單一職責原則(SRP) 案例:財務憑證變更帶來的問題 案例:超級大函數與大對象的難題 案例:MySQL讀寫分離的改造過程 b. 信息專家模式 c. 不要重復自己原則(DRY) 典型的代碼重復案例 探討代碼復用的難題 探討軟件設計模式: 1. 設計模式的由來 2. 設計模式的發展 3. 設計模式對高質量軟件設計的作用 |
第二部分 軟件設計模式 | |
第三章 適配器模式 |
什么是適配器模式 1. 軟件設計中外部接口的難題 2. 第三方框架帶來的設計難題 3. 適配器模式及其概念 適配器模式的應用 1. 適配器模式解決第三方框架帶來的難題 案例:Hibernate適配器的設計 2. 適配器模式解決外部接口的設計難題 案例:第三方支付接口的設計 案例:財務數據接口的設計 |
第四章 策略模式 |
什么是策略模式 1. 工資發放功能遇到的難題 1) 工資發放功能最初的設計及其問題 2) 對問題的分析過程及其新的設計思路 2. 策略模式及其概念 策略模式的應用 1. 案例:工資發放功能設計改進的過程 1) 工資發放功能的Java實現 2) 工資發放功能的C++實現 2. 案例:數據導出功能的設計實現 1) 深入理解開放-封閉原則 2) 數據導出功能的變更與改進過程 3. 案例:財務憑證生成功能的設計過程 1) 財務憑證生成功能的初始需求與設計 2) 財務憑證生成功能的擴展與分析過程 3) 財務憑證生成功能的最終設計 4) 深入理解單一職責原則 5) 學習“兩頂帽子”的設計方式 練習:財務憑證生成功能的設計與實現 |
第五章 工廠模式 |
探討軟件設計中遇到的難題 1. 依賴反轉原則的設計難題 2. 開放-封閉原則的設計難題 3. 探討工廠模式的本質 簡單工廠模式 1. 簡單工廠模式的C++實現 2. 基于配置的簡單工廠模式 3. 剖析簡單工廠如何實現依賴反轉原則 案例:剖析Spring的beanFactory 4. 解讀工廠模式對設計的重大意義 5. 講解如何創建一個工廠 1) 創建工廠的步驟與關鍵點 2) 利用Spring框架簡化工廠類的設計 案例:數據導出功能的工廠實現 工廠方法模式 1. 工廠方法模式的概念 2. 工廠方法模式的應用 案例:SAX框架的工廠類設計 抽象工廠模式 1. 抽象工廠模式的概念 2. 抽象工廠模式的實現 案例:標簽庫的設計改進過程 1) 最初的標簽庫設計 2) 運用簡單工廠的標簽庫設計 3) 運用工廠方法的標簽庫設計 4) 運用抽象工廠的標簽庫設計 5) 最終基于配置的標簽庫設計 |
第六章 單例模式 |
什么是單例模式 1. 設計工廠類面臨的問題 2. 單例模式及其概念 3. 如何實現單例模式 單例模式的應用 1. 單例模式帶來的設計變革 1) 充血模型vs.貧血模型 2) 探討單例模式與性能問題 2. 單例模式改變了很多軟件的設計 |
第七章 原型模式 |
什么是原型模式 1. 工廠類在提供產品時遇到的設計問題 2. 原型模式及其概念 原型模式的設計實現 案例:函數調用的無副作用問題 案例:JavsScript中的原型模式 |
第八章 模板方法模式 |
什么是模板方法模式 1. 煮咖啡給我們的啟示 2. 設計工廠類的新思路 3. 模板方法模式及其概念 模板方法模式的作用與技巧 案例:一個工廠模板的設計與實現 深入理解不要重復自己原則 1. 重復代碼帶來的嚴重后果 2. 散彈式修改及其解決思路 3. 探討實現代碼復用的難題 4. 代碼復用在不同場合采用的方法 5. 模板方法模式在代碼復用中的作用 |
第九章 裝飾者模式 |
什么是裝飾者模式 1. 業務量增長帶來的多數據源問題 2. 運用裝飾者模式巧妙解決多數據源問題 3. 裝飾者模式及其概念 裝飾者模式的應用 案例:多數據源的設計實現 1. 多數據源問題的分析設計過程 2. 多數據源的設計與實現 案例:商城收銀系統的設計變更過程 1. 商城收銀系統期初的設計 2. 混合策略的設計與實現 3. 多層裝飾者的設計與實現 重新理解里氏替換原則 1. 透明的功能擴展 2. 里氏替換原則 練習:商場收銀系統的2種設計與實現 |
第十章 橋接模式 |
什么是橋接模式 1. 對象繼承的泛濫 2. 橋接模式及其概念 橋接模式的應用 案例:員工管理與工資發放的設計 1. 員工管理與工資發放帶來的繼承泛濫問題 2. 采用橋接模式的設計與實現 案例:查詢支持類的設計 1. 查詢支持類遭遇的繼承泛濫問題 2. 查詢支持類的解決方案 3. 單例模式下查詢支持類的設計 深入體會單一職責原則 |
第十一章 享元模式 |
什么是享元模式 1. Hibernate是怎樣訪問數據的 2. 享元模式及其概念 享元模式的應用 案例:數據緩存的設計實現 案例:享元模式在大數據中的應用 |
第十二章 其它設計模式 |
觀察者模式:JobHunter的情景劇 代理模式:老板與秘書的差異 命令模式:像工作流一樣處理業務 外觀模式:超級家庭影院的煩惱 構建器模式:SQL Builder的設計 組合模式:如何構建一棵樹 中介者模式:QQ在溝通中的作用 迭代器模式:如何順序訪問一個集合 |
第2-4天 | 軟件重構實戰授課內容 |
第一部分 為什么軟件需要及時重構 | |
第一單元 剖析軟件質量不斷下降的根源 |
質量不斷下降的表現: 1. 程序代碼越來越亂 2. 軟件維護成本越來越高 3. 軟件變更越來越困難 4. 無法進行新技術的改造 以往采取的措施: 1. 頭痛醫頭,腳痛醫腳 2. 拋棄掉重新編寫 3. 因擔心未來變化而做的過度設計 帶來的問題 1. 團隊成員越來越多但效率卻越來越低 2. 測試變得越來越困難而任務繁重 3. 軟件系統越來越笨重而不適應未來變化 分析與反思 案例分析:一個遺留系統的演化過程 1. 起初的設計 2. 隨后的變更 3. 質量不斷下降的過程 軟件質量下降的根源: 1. 軟件總是因變更而變得越來越復雜 2. 軟件結構已經不再適應復雜的軟件需求 3. 必須要調整軟件結構以適應新的軟件需求 軟件是因需求變更而質量下降嗎? 案例分析:推演軟件變更的設計過程 應對軟件變更的最佳方式:兩頂帽子 1. 重構原有代碼以適應新的需求 2. 實現新的需求 案例:演示兩頂帽子的設計過程 案例:財務憑證生成程序的設計過程 |
第二單元 高質量的軟件設計過程 |
案例講解軟件設計原則 1. 低耦合 1) 依賴反轉原則(DIP) 案例:購票業務類與數據訪問類 2) 開放-封閉原則(OCP) 案例:需求變更與可擴展點設計 案例:Square/Circle的解決方案 3) 里氏替換原則(LSP) 案例:Rectangle/Square的問題 案例:查詢參數傳遞類的問題 2. 高內聚 1) 單一職責原則(SRP) 案例:財務憑證變更帶來的問題 案例:超級大函數與大對象的難題 案例:MySQL讀寫分離的改造過程 2) 信息專家模式 3) 不要重復自己原則(DRY) 4) 典型的代碼重復案例 5) 探討代碼復用的難題 以往軟件設計的過程: 3. 演示以往軟件設計的過程 4. 剖析以往軟件設計的問題與風險 小步快跑模式的開發過程: 1. 用最快的速度開發一個最核心的功能 2. 讓第一個版本運行起來并可以驗證 3. 在第一個版本的基礎上不斷添加功能: a. 每次只添加一個很簡單、很單一的功能 b. 每次以兩頂帽子的方式添加新功能 c. 運行、調試與驗證 d. 重復這個過程添加下一個功能 4. 復雜的系統就是由一次次正確開發的不斷積累而成 案例:演示小步快跑的開發過程 小步快跑解決的問題: 1. 復雜功能有效地解耦 2. 代碼編寫總是可測試與驗證 3. 簡化設計與思考的復雜度 4. 適時重構以避免軟件退化 案例:數據推送程序的設計過程 |
第二部分 如何進行軟件重構 | |
第三單元 何為重構 |
軟件重構的概念 1. 重構是一系列代碼的等量變換 案例:一個Hello World重構過程 2. 重構的保險索:自動化測試 案例:Hello World的自動化測試過程 3. 軟件修改的四種動機——重構的價值 4. 一個真實的謊言——重構的誤區 5. 重構的主要方法與技巧 案例分析:重構一個大型遺留系統 1. 重構第一步:分解大函數 超級大函數及其危害 案例:演示大函數產生的過程 案例:演示抽取方法操作步驟 實踐抽取方法會遇到的問題和解決方案 2. 重構第二步:拆分大對象 超級大對象及其危害 案例:演示超級大對象的產生過程 案例:演示抽取類的操作步驟 講解單一職責設計原則 案例:演示“分久必合,合久必分”的重構過程 3. 重構第三步:提高復用率 講解順序編程及其危害 “不要重復代碼”原則 案例:提高代碼復用的6個方法 案例:演示新增代碼時的代碼復用過程 用靜態檢查工具檢查重復代碼 4. 重構第四步:可擴展設計 過度設計 vs. 恰如其分的設計 講解“開放-封閉”的設計原則 案例:講解可擴展設計的4個方法 案例:講解新增代碼的可擴展設計過程 5. 重構第五步:降低耦合度 案例:講解接口、實現與工廠模式 案例:講解外部接口解耦與適配器模式 6. 重構第六步:系統分層 反思軟件架構需要怎樣的分層結構 遺留系統如何擁抱需求變化 遺留系統如何應對技術變革 7. 重構第七步:領域驅動設計 領域驅動設計的概念 講解領域模型分析方法 案例:智能溫控器分析設計過程(嵌入式+物聯網) 1) 最初的領域驅動設計過程 2) 需求變更的領域驅動設計 3) 面向物聯網的架構演進 練習:重構一個小程序并編寫測試腳本 |
第四單元 關于重構的討論 |
什么時候重構 1. 重構是一種習慣 2. 重構讓程序可讀 3. 重構,才好復用 4. 先重構,再擴展 5. 緊急任務時的重構 測試的困境 1. 重構初期的困局 2. 解耦與自動化測試 3. 建立自動化測試體系 重構的評價 1. 評價軟件質量的指標 2. 評價軟件質量的工具 |
五、 授課專家
范老師 獨立咨詢顧問,暢銷書籍《架構真意》與《大話重構》的作者,規模化敏捷SPC。曾任航天信息首席架構師,哈工大軟件工程碩士,軟件架構及重構的客座講師。從事軟件研發工作近二十年,并且現在一直堅守在大型軟件架構設計一線工作。從需求分析、軟件開發到項目管理、架構設計都有豐富的從業經驗。先后參與了數十個國內大型軟件項目,涉及國家財政、軍工、稅務、醫療等領域的大數據中臺建設、風險防控與人工智能研究。
互聯網轉型、微服務轉型及大數據轉型的實踐者與倡導者。同時,還是大型遺留系統改造專業戶,多次參與大型遺留系統改造、軟件系統重構等重大項目,長期關注大型業務系統的品質保證、防止腐化以及技術改造等困擾軟件企業的問題,在遺留系統優化與改造方面有豐富的經驗。
程老師 中國科學院軟件研究所碩士,主要研究方向:架構設計、項目管理實踐、大型高可用高并發架構設計、微服務架構、軟件測試等等。熟悉網絡分布式計算、數據庫、網絡操作系統,精通J2EE、SQL、中間件服務器。在J2EE技術領域具有理論功底和實踐經驗。在J2ME商務應用和基于J2ME游戲開發領域具有深厚的理論功底和豐富的實戰經驗。
主要授課方向:DevOps落地實踐、微服務架構、軟件構架設計、UML、GO語言、OOAD、J2EE企業級高級應用開發等。
擅長架構企業級應用;有獨立工作流引擎開發、企業系統應用集成方面的豐富經驗;在企業門戶(Portal)、報表、工作流引擎和企業服務總線(ESB)等應用領域有深入的理論研究和充分的實踐;對軟件開發的整個流程有深刻認識,有很好的協作精神和學習能力。在架構下的系統設計和開發方面均有豐富經驗。能夠結合實際,在復雜的應用環境中選擇適合的技術組合并合理利用開源中間件來降低項目開發風險、縮短開發周期、提高應用系統的可維護性和可擴展性。
尹老師 《Spring Cloud微服務-全棧技術與案例解析》,《Spring Cloud微服務入門實戰與進階》作者。簡單的技術愛好者,先后就職于京東和阿里巴巴。一直從事Java服務端開發工作,前端開發工作。主要關注分布式,高并發,后端服務,目前重心在微服務這塊。
個人成就出書:《Spring Cloud微服務-全棧技術與案例解析》《Spring Cloud微服務入門實戰與進階》GitChat: 微服務中的短信服務如何設計?演講:極部落Java開發者大會,iTechPlus Java開發者大會分享嘉賓。
本課程由中國信息化培訓中心頒發《軟件設計高級工程師》證書,證書查詢網址:www.qinzhounet.cn;證書可作為專業技術人員職業能力考核的證明,以及專業技術人員崗位聘用、任職、定級和晉升職務的重要依據。