課程簡介
大泥球，是指雜亂無章、錯綜復(fù)雜、邋遢不堪、隨意拼貼的大堆代碼。這些年來，為了對付大泥球，我們看到了很多設(shè)計原則和模式,比如SOLID、GRASP 和KISS。然而，實(shí)際情形卻沒多大發(fā)化，“大泥球”看起來仍然是設(shè)計軟件的最常見方法。我們課程重點(diǎn)關(guān)注軟件設(shè)計師技能, 這是本課程的設(shè)置的目的.課程總結(jié)了多年項(xiàng)目開發(fā)的實(shí)戰(zhàn)經(jīng)驗(yàn)，讓學(xué)員體會在軟件系統(tǒng)設(shè)計過程中提高能力。
目標(biāo)收益
本課程注重實(shí)戰(zhàn),采用案例貫穿方式完成講解理論，讓學(xué)員體驗(yàn)軟件設(shè)計的思索,權(quán)衡,折中,選擇的痛苦過程，首先提出真實(shí)項(xiàng)目的需求,然后學(xué)員開始動手設(shè)計,最終講師和你一起思索,一起探討,一起權(quán)衡,一起驗(yàn)證.
培訓(xùn)對象
一般軟件企業(yè)的設(shè)計人員和初級架構(gòu)師,以及資深程序員
課程大綱
|
第一單元 軟件設(shè)計目標(biāo)-靈活性/可插入性/可擴(kuò)展 |
內(nèi)容一：擁抱需求變化---設(shè)計師必須面對的 1、 不管你在何處工作,構(gòu)建些什么,用何種語言,在軟件開發(fā)上,一直最痛苦的事情是什么? 或者什么是你開發(fā)之中最討厭的問題是什么?---需求變更 2、 殺死一個程序員不需要刀，只要需求變3次就好了!! 3、 軟件不斷變更法則:真實(shí)世界中使用的程序必須進(jìn)行變更,否則它在環(huán)境中的作用就會越來越小. 4、 需求改變的態(tài)度-拒絕變化無用，積極心態(tài)面對變化 5、 而敏捷對預(yù)測未來的方式是全新的，強(qiáng)調(diào)通過提高團(tuán)隊(duì)的能力、設(shè)計的彈性和流程的靈活性來適應(yīng)變化。這種思路對軟件開發(fā)也是很大的沖擊。 6、 軟件設(shè)計的目標(biāo)-靈活性，因?yàn)樵黾右粋€功能特性的成本并不單單是為這些功能編碼所花費(fèi)時間的成本，還應(yīng)該包括特性擴(kuò)展的障礙成本?，F(xiàn)在我們遇到的最大障礙是現(xiàn)在系統(tǒng)的混亂，難以擴(kuò)展。 7、 案例分析—通過案例分析需要變化的根源，以及各種情況 |
|
第二單元 如何設(shè)計才能實(shí)現(xiàn)靈活性 |
內(nèi)容一：軟件設(shè)計的靈活性 1、 什么是好的設(shè)計和衡量的手段,世界大師的觀點(diǎn)(Robert C Martin , Peter Code,` James Shor) 2、 一個好的系統(tǒng)設(shè)計應(yīng)該有如下的性質(zhì)：可擴(kuò)展性、靈活性、可插入性。－Peter Code [CODE99] 3、 可擴(kuò)展性（Extensibility）容易添加新的功能. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 4、 靈活性（Flexibility）代碼修改平穩(wěn)地發(fā)生. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 5、 可插入性（Pluggability）容易將一個類抽出去，同時將另一個有同樣接口的類加入進(jìn)來. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 6、 分析真實(shí)項(xiàng)目,如何做的詳細(xì)設(shè)計,給我們哪些啟示,我們可以學(xué)習(xí)到什么 7、 分析我們在項(xiàng)目之中是那些原因?qū)е铝藳]有實(shí)現(xiàn)這些目標(biāo). 內(nèi)容二：案例- 某項(xiàng)目認(rèn)證管理模塊設(shè)計案例 1、 某省移動項(xiàng)目,必須考慮支持多種設(shè)備廠商 2、 初始設(shè)計的問題分析 3、 應(yīng)用何種模式解決問題 |
|
第三單元 靈活性設(shè)計基本原則/模式/實(shí)踐 |
內(nèi)容一：靈活設(shè)計的基本原則 1、 發(fā)現(xiàn)和封裝變化的原則 2、 找出應(yīng)用中可能需要變化之處,把它們獨(dú)立出來,不要和那些不需要變化的代碼交織在一起. 3、抽象穩(wěn)定接口（抽象類），針對接口編程,而不是針對實(shí)現(xiàn)編程 4、 分離變化維度，單一職責(zé)原則 5、動態(tài)綁定還是靜態(tài)綁定，多用組合,少用繼承 6、 創(chuàng)建與使用分離，創(chuàng)建有變化也要封裝 7、 結(jié)合多個案例項(xiàng)目進(jìn)行分析,怎樣發(fā)現(xiàn)和封裝變化,如何通過具體的手段來進(jìn)行適應(yīng)這些變化 內(nèi)容二：靈活性設(shè)計的最佳實(shí)踐 1、 多態(tài)(polymorphism)和針對接口的編程 2、 數(shù)據(jù)驅(qū)動(Data-Driven Design) 3、 元數(shù)據(jù)驅(qū)動設(shè)計 4、 反射驅(qū)動(Meta-data or Reflective ) 5、 解釋器驅(qū)動 6、 腳本引擎技術(shù) 7、 結(jié)合多個案例項(xiàng)目進(jìn)行分析,怎樣發(fā)現(xiàn)和封裝變化,如何通過具體的手段來進(jìn)行適應(yīng)這些變化 內(nèi)容三：案例---結(jié)合案例分析軟件設(shè)計原則/模式 1、 某項(xiàng)目系統(tǒng)的演變，以及設(shè)計原則的應(yīng)用效果，通過項(xiàng)目的演化分析這些核心設(shè)計原則的應(yīng)用場景 2、 通過一個大型實(shí)例，傳遞Clean Code，設(shè)計原則等，包括DIY原則，Tell Don't Ask原則，Soild原則（Single Responsibility原則，Open Closed原則，Liskov Substitution原則，Interface Segregation原則，Dependency Inversion原則）。 3、 案例分析-設(shè)計原則的應(yīng)用 |
|
第四單元 軟件設(shè)計腐化 |
內(nèi)容一：設(shè)計腐化與技術(shù)債務(wù) 1、設(shè)計腐化的途經(jīng) 2、 總結(jié)常見的設(shè)計腐化途經(jīng)，原因及克服方法 3、 技術(shù)債務(wù)概述 4、 軟件債務(wù)對軟件系統(tǒng)的危害 5、 軟件債務(wù)對軟件開發(fā)人員的危害 6、 技術(shù)債務(wù)與破窗效應(yīng) 7、 技術(shù)債務(wù)的解決之道 8、 通過案例分析,如何解決技術(shù)債務(wù) 內(nèi)容二：技術(shù)債務(wù)監(jiān)控 1、 軟件腐化監(jiān)控 2、 國際著名某電信研發(fā)中心監(jiān)控工具 內(nèi)容三：軟件腐化與希波克拉底宣言 1、 First, Do No Harm. 首先，做到不傷害！— Hippocrates 希波克拉底 2、 Proxy代理模式與軟件修改方案 3、 decorator模式與遺留軟件修改 4、 案例分析—如果維護(hù)遺留系統(tǒng)而不是遺留系統(tǒng)變爛 內(nèi)容四：案例- 演示系統(tǒng)軟件腐化的過程 1、 某電信研發(fā)中心項(xiàng)目系統(tǒng) 2、 初始設(shè)計的問題分析 3、 故障單管理系統(tǒng) 4、 流程審核的改變 5、 故障單類型的增加 6、 傳統(tǒng)設(shè)計的問題與如何通過代碼進(jìn)行演化 7、 通過該案例分析,對比有時是因?yàn)槿藛T的設(shè)計技能導(dǎo)致加速軟件的腐化 8、 通過該案例分析，講師加入項(xiàng)目之后，將進(jìn)行哪些重構(gòu) |
|
第五單元 演化式設(shè)計 |
內(nèi)容一：演化式設(shè)計(Emergent Design) 1、 演化式設(shè)計 Emergent Design 2、 演化設(shè)計--重構(gòu)帶來了一種新的構(gòu)設(shè)計方法，稱為反思性設(shè)計(Reflective Design)。除了創(chuàng)建一種設(shè)計并用代碼實(shí)現(xiàn)它之外，你現(xiàn)在還可以分析已有代碼的設(shè)計并改善它。尋求改進(jìn)的一種最好的方法是通過代碼嗅覺(code smells). 3、 在詳細(xì)設(shè)計之中,如何對發(fā)現(xiàn)問題的設(shè)計進(jìn)行重構(gòu) 4、 很多公司習(xí)慣做大量的預(yù)習(xí)設(shè)計，這被證明是風(fēng)險很高的做法。好的架構(gòu)和設(shè)計是演進(jìn)出來的，通過這個環(huán)節(jié)了解演進(jìn)式設(shè)計的方法，包括演進(jìn)式設(shè)計的方法、工具、模式等內(nèi)容。包括如何計劃重構(gòu)活動以實(shí)現(xiàn)架構(gòu)演進(jìn)，如何從設(shè)計方法、技術(shù)債務(wù)、復(fù)雜性等角度看架構(gòu)演進(jìn) 5、 案例分析, 根據(jù)課程介紹的壞癥狀,進(jìn)行重構(gòu)合理的設(shè)計 內(nèi)容二：設(shè)計的新認(rèn)識—源代碼就是設(shè)計 1、 傳統(tǒng)代碼認(rèn)識的誤區(qū) 2、 設(shè)計與施工分離的誤區(qū) 3、 源代碼就是設(shè)計 4、 分析真實(shí)項(xiàng)目代碼, 認(rèn)識代碼的重要性.垃圾代碼的危害 內(nèi)容三：拙劣設(shè)計的壞癥狀和重構(gòu) 1、 拙劣設(shè)計概述 2、 拙劣設(shè)計常見癥狀以及如何發(fā)現(xiàn)和治療 3、 在詳細(xì)設(shè)計之中,如何對發(fā)現(xiàn)問題的設(shè)計進(jìn)行重構(gòu) 4、 代碼壞味道概述 5、 常見的重構(gòu)設(shè)計方式 6、 重構(gòu)到設(shè)計模式 7、 案例分析-對實(shí)際項(xiàng)目的案例進(jìn)行代碼分析和重構(gòu) 8、 案例分析, 根據(jù)課程介紹的壞癥狀,進(jìn)行實(shí)際項(xiàng)目重構(gòu)的設(shè)計 內(nèi)容四：案例---某零售項(xiàng)目系統(tǒng)分析 1、 零售租賃管理系統(tǒng) 2、 第一版本設(shè)計和評審 3、 故障單類型的增加 4、 傳統(tǒng)設(shè)計的問題與如何通過代碼進(jìn)行演化 |
|
第六單元 關(guān)注人- 設(shè)計師與技能的思考 |
內(nèi)容一：設(shè)計師與設(shè)計技能 1、 某研發(fā)團(tuán)隊(duì)5年前引入敏捷的失敗教訓(xùn)-能力比方法重要，但改變方法比改變能力簡單多了 2、 無論什么道什么術(shù)，什么方法或思想，離開了人都是虛妄。優(yōu)秀的設(shè)計來自優(yōu)秀的設(shè)計師，因此應(yīng)該首先是尊重個體的主動和創(chuàng)造性，提高個體工作技能，而不是應(yīng)用了一種流程，消滅了個體的活力。首先關(guān)注人，才能真敏捷。 3、 案例分析, 某研發(fā)中心引入敏捷的實(shí)戰(zhàn)分析，什么才是真正的敏捷。 內(nèi)容二：設(shè)計師能力模型 1、 設(shè)計能力金字塔 2、 軟件設(shè)計價值觀 3、 軟件設(shè)計原則 4、 軟件設(shè)計模式 5、 軟件設(shè)計最佳實(shí)踐 6、 通過某研發(fā)中心的設(shè)計師能力模型分析，設(shè)計能力提升計劃 |
|
第七單元 軟件設(shè)計復(fù)用性 |
內(nèi)容一：軟件復(fù)用設(shè)計 1、 在詳細(xì)設(shè)計之中,分析發(fā)現(xiàn)共同的行為的抽象和共同的機(jī)制來實(shí)現(xiàn) 2、 軟件通用服務(wù)組件的設(shè)計 3、 復(fù)用已有的東西，比自己編寫更容易。如果不容易，大家就不會去復(fù)用。 4、 軟件復(fù)用的管理策略 5、 對象級別復(fù)用 6、 模塊級別復(fù)用 7、 架構(gòu)層次復(fù)用 8、 軟件復(fù)用之道 9、 案例分析復(fù)用的設(shè)計之道 內(nèi)容二：某電信項(xiàng)目案例-異常處理框架設(shè)計 1、 系統(tǒng)的異常處理策略 2、 設(shè)計一個通用異常處理子系統(tǒng) 3、 分析如何應(yīng)用設(shè)計模式在該案例 4、 分析通過應(yīng)用設(shè)計模式,帶來了哪些好處(表現(xiàn)在軟件的靈活性) 5、 分析如何轉(zhuǎn)換為Framework 6、 典型案例分析：該框架已經(jīng)在多個大型項(xiàng)目之中應(yīng)用 |
|
第八單元 軟件設(shè)計案例分析 |
內(nèi)容一：大型軟件項(xiàng)目設(shè)計案例分析-案例分析結(jié)合以上章節(jié) 1、 某電信核心系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 2、 某電力系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 3、 某Web互聯(lián)網(wǎng)電子商務(wù)系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 4、 某稅務(wù)系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 |
|
第一單元 軟件設(shè)計目標(biāo)-靈活性/可插入性/可擴(kuò)展 內(nèi)容一：擁抱需求變化---設(shè)計師必須面對的 1、 不管你在何處工作,構(gòu)建些什么,用何種語言,在軟件開發(fā)上,一直最痛苦的事情是什么? 或者什么是你開發(fā)之中最討厭的問題是什么?---需求變更 2、 殺死一個程序員不需要刀，只要需求變3次就好了!! 3、 軟件不斷變更法則:真實(shí)世界中使用的程序必須進(jìn)行變更,否則它在環(huán)境中的作用就會越來越小. 4、 需求改變的態(tài)度-拒絕變化無用，積極心態(tài)面對變化 5、 而敏捷對預(yù)測未來的方式是全新的，強(qiáng)調(diào)通過提高團(tuán)隊(duì)的能力、設(shè)計的彈性和流程的靈活性來適應(yīng)變化。這種思路對軟件開發(fā)也是很大的沖擊。 6、 軟件設(shè)計的目標(biāo)-靈活性，因?yàn)樵黾右粋€功能特性的成本并不單單是為這些功能編碼所花費(fèi)時間的成本，還應(yīng)該包括特性擴(kuò)展的障礙成本。現(xiàn)在我們遇到的最大障礙是現(xiàn)在系統(tǒng)的混亂，難以擴(kuò)展。 7、 案例分析—通過案例分析需要變化的根源，以及各種情況 |
|
第二單元 如何設(shè)計才能實(shí)現(xiàn)靈活性 內(nèi)容一：軟件設(shè)計的靈活性 1、 什么是好的設(shè)計和衡量的手段,世界大師的觀點(diǎn)(Robert C Martin , Peter Code,` James Shor) 2、 一個好的系統(tǒng)設(shè)計應(yīng)該有如下的性質(zhì)：可擴(kuò)展性、靈活性、可插入性。－Peter Code [CODE99] 3、 可擴(kuò)展性（Extensibility）容易添加新的功能. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 4、 靈活性（Flexibility）代碼修改平穩(wěn)地發(fā)生. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 5、 可插入性（Pluggability）容易將一個類抽出去，同時將另一個有同樣接口的類加入進(jìn)來. 結(jié)合案例,通過那些手段如何實(shí)現(xiàn)該目標(biāo) 6、 分析真實(shí)項(xiàng)目,如何做的詳細(xì)設(shè)計,給我們哪些啟示,我們可以學(xué)習(xí)到什么 7、 分析我們在項(xiàng)目之中是那些原因?qū)е铝藳]有實(shí)現(xiàn)這些目標(biāo). 內(nèi)容二：案例- 某項(xiàng)目認(rèn)證管理模塊設(shè)計案例 1、 某省移動項(xiàng)目,必須考慮支持多種設(shè)備廠商 2、 初始設(shè)計的問題分析 3、 應(yīng)用何種模式解決問題 |
|
第三單元 靈活性設(shè)計基本原則/模式/實(shí)踐 內(nèi)容一：靈活設(shè)計的基本原則 1、 發(fā)現(xiàn)和封裝變化的原則 2、 找出應(yīng)用中可能需要變化之處,把它們獨(dú)立出來,不要和那些不需要變化的代碼交織在一起. 3、抽象穩(wěn)定接口（抽象類），針對接口編程,而不是針對實(shí)現(xiàn)編程 4、 分離變化維度，單一職責(zé)原則 5、動態(tài)綁定還是靜態(tài)綁定，多用組合,少用繼承 6、 創(chuàng)建與使用分離，創(chuàng)建有變化也要封裝 7、 結(jié)合多個案例項(xiàng)目進(jìn)行分析,怎樣發(fā)現(xiàn)和封裝變化,如何通過具體的手段來進(jìn)行適應(yīng)這些變化 內(nèi)容二：靈活性設(shè)計的最佳實(shí)踐 1、 多態(tài)(polymorphism)和針對接口的編程 2、 數(shù)據(jù)驅(qū)動(Data-Driven Design) 3、 元數(shù)據(jù)驅(qū)動設(shè)計 4、 反射驅(qū)動(Meta-data or Reflective ) 5、 解釋器驅(qū)動 6、 腳本引擎技術(shù) 7、 結(jié)合多個案例項(xiàng)目進(jìn)行分析,怎樣發(fā)現(xiàn)和封裝變化,如何通過具體的手段來進(jìn)行適應(yīng)這些變化 內(nèi)容三：案例---結(jié)合案例分析軟件設(shè)計原則/模式 1、 某項(xiàng)目系統(tǒng)的演變，以及設(shè)計原則的應(yīng)用效果，通過項(xiàng)目的演化分析這些核心設(shè)計原則的應(yīng)用場景 2、 通過一個大型實(shí)例，傳遞Clean Code，設(shè)計原則等，包括DIY原則，Tell Don't Ask原則，Soild原則（Single Responsibility原則，Open Closed原則，Liskov Substitution原則，Interface Segregation原則，Dependency Inversion原則）。 3、 案例分析-設(shè)計原則的應(yīng)用 |
|
第四單元 軟件設(shè)計腐化 內(nèi)容一：設(shè)計腐化與技術(shù)債務(wù) 1、設(shè)計腐化的途經(jīng) 2、 總結(jié)常見的設(shè)計腐化途經(jīng)，原因及克服方法 3、 技術(shù)債務(wù)概述 4、 軟件債務(wù)對軟件系統(tǒng)的危害 5、 軟件債務(wù)對軟件開發(fā)人員的危害 6、 技術(shù)債務(wù)與破窗效應(yīng) 7、 技術(shù)債務(wù)的解決之道 8、 通過案例分析,如何解決技術(shù)債務(wù) 內(nèi)容二：技術(shù)債務(wù)監(jiān)控 1、 軟件腐化監(jiān)控 2、 國際著名某電信研發(fā)中心監(jiān)控工具 內(nèi)容三：軟件腐化與希波克拉底宣言 1、 First, Do No Harm. 首先，做到不傷害！— Hippocrates 希波克拉底 2、 Proxy代理模式與軟件修改方案 3、 decorator模式與遺留軟件修改 4、 案例分析—如果維護(hù)遺留系統(tǒng)而不是遺留系統(tǒng)變爛 內(nèi)容四：案例- 演示系統(tǒng)軟件腐化的過程 1、 某電信研發(fā)中心項(xiàng)目系統(tǒng) 2、 初始設(shè)計的問題分析 3、 故障單管理系統(tǒng) 4、 流程審核的改變 5、 故障單類型的增加 6、 傳統(tǒng)設(shè)計的問題與如何通過代碼進(jìn)行演化 7、 通過該案例分析,對比有時是因?yàn)槿藛T的設(shè)計技能導(dǎo)致加速軟件的腐化 8、 通過該案例分析，講師加入項(xiàng)目之后，將進(jìn)行哪些重構(gòu) |
|
第五單元 演化式設(shè)計 內(nèi)容一：演化式設(shè)計(Emergent Design) 1、 演化式設(shè)計 Emergent Design 2、 演化設(shè)計--重構(gòu)帶來了一種新的構(gòu)設(shè)計方法，稱為反思性設(shè)計(Reflective Design)。除了創(chuàng)建一種設(shè)計并用代碼實(shí)現(xiàn)它之外，你現(xiàn)在還可以分析已有代碼的設(shè)計并改善它。尋求改進(jìn)的一種最好的方法是通過代碼嗅覺(code smells). 3、 在詳細(xì)設(shè)計之中,如何對發(fā)現(xiàn)問題的設(shè)計進(jìn)行重構(gòu) 4、 很多公司習(xí)慣做大量的預(yù)習(xí)設(shè)計，這被證明是風(fēng)險很高的做法。好的架構(gòu)和設(shè)計是演進(jìn)出來的，通過這個環(huán)節(jié)了解演進(jìn)式設(shè)計的方法，包括演進(jìn)式設(shè)計的方法、工具、模式等內(nèi)容。包括如何計劃重構(gòu)活動以實(shí)現(xiàn)架構(gòu)演進(jìn)，如何從設(shè)計方法、技術(shù)債務(wù)、復(fù)雜性等角度看架構(gòu)演進(jìn) 5、 案例分析, 根據(jù)課程介紹的壞癥狀,進(jìn)行重構(gòu)合理的設(shè)計 內(nèi)容二：設(shè)計的新認(rèn)識—源代碼就是設(shè)計 1、 傳統(tǒng)代碼認(rèn)識的誤區(qū) 2、 設(shè)計與施工分離的誤區(qū) 3、 源代碼就是設(shè)計 4、 分析真實(shí)項(xiàng)目代碼, 認(rèn)識代碼的重要性.垃圾代碼的危害 內(nèi)容三：拙劣設(shè)計的壞癥狀和重構(gòu) 1、 拙劣設(shè)計概述 2、 拙劣設(shè)計常見癥狀以及如何發(fā)現(xiàn)和治療 3、 在詳細(xì)設(shè)計之中,如何對發(fā)現(xiàn)問題的設(shè)計進(jìn)行重構(gòu) 4、 代碼壞味道概述 5、 常見的重構(gòu)設(shè)計方式 6、 重構(gòu)到設(shè)計模式 7、 案例分析-對實(shí)際項(xiàng)目的案例進(jìn)行代碼分析和重構(gòu) 8、 案例分析, 根據(jù)課程介紹的壞癥狀,進(jìn)行實(shí)際項(xiàng)目重構(gòu)的設(shè)計 內(nèi)容四：案例---某零售項(xiàng)目系統(tǒng)分析 1、 零售租賃管理系統(tǒng) 2、 第一版本設(shè)計和評審 3、 故障單類型的增加 4、 傳統(tǒng)設(shè)計的問題與如何通過代碼進(jìn)行演化 |
|
第六單元 關(guān)注人- 設(shè)計師與技能的思考 內(nèi)容一：設(shè)計師與設(shè)計技能 1、 某研發(fā)團(tuán)隊(duì)5年前引入敏捷的失敗教訓(xùn)-能力比方法重要，但改變方法比改變能力簡單多了 2、 無論什么道什么術(shù)，什么方法或思想，離開了人都是虛妄。優(yōu)秀的設(shè)計來自優(yōu)秀的設(shè)計師，因此應(yīng)該首先是尊重個體的主動和創(chuàng)造性，提高個體工作技能，而不是應(yīng)用了一種流程，消滅了個體的活力。首先關(guān)注人，才能真敏捷。 3、 案例分析, 某研發(fā)中心引入敏捷的實(shí)戰(zhàn)分析，什么才是真正的敏捷。 內(nèi)容二：設(shè)計師能力模型 1、 設(shè)計能力金字塔 2、 軟件設(shè)計價值觀 3、 軟件設(shè)計原則 4、 軟件設(shè)計模式 5、 軟件設(shè)計最佳實(shí)踐 6、 通過某研發(fā)中心的設(shè)計師能力模型分析，設(shè)計能力提升計劃 |
|
第七單元 軟件設(shè)計復(fù)用性 內(nèi)容一：軟件復(fù)用設(shè)計 1、 在詳細(xì)設(shè)計之中,分析發(fā)現(xiàn)共同的行為的抽象和共同的機(jī)制來實(shí)現(xiàn) 2、 軟件通用服務(wù)組件的設(shè)計 3、 復(fù)用已有的東西，比自己編寫更容易。如果不容易，大家就不會去復(fù)用。 4、 軟件復(fù)用的管理策略 5、 對象級別復(fù)用 6、 模塊級別復(fù)用 7、 架構(gòu)層次復(fù)用 8、 軟件復(fù)用之道 9、 案例分析復(fù)用的設(shè)計之道 內(nèi)容二：某電信項(xiàng)目案例-異常處理框架設(shè)計 1、 系統(tǒng)的異常處理策略 2、 設(shè)計一個通用異常處理子系統(tǒng) 3、 分析如何應(yīng)用設(shè)計模式在該案例 4、 分析通過應(yīng)用設(shè)計模式,帶來了哪些好處(表現(xiàn)在軟件的靈活性) 5、 分析如何轉(zhuǎn)換為Framework 6、 典型案例分析：該框架已經(jīng)在多個大型項(xiàng)目之中應(yīng)用 |
|
第八單元 軟件設(shè)計案例分析 內(nèi)容一：大型軟件項(xiàng)目設(shè)計案例分析-案例分析結(jié)合以上章節(jié) 1、 某電信核心系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 2、 某電力系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 3、 某Web互聯(lián)網(wǎng)電子商務(wù)系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 4、 某稅務(wù)系統(tǒng)設(shè)計最佳實(shí)踐和案例分析 |
近期公開課推薦
