第一篇: 編程是一種態(tài)度-------價值觀
第1單元 代碼就是債務
內(nèi)容一:代碼是債務
1.代碼的認識---代碼就是債務
2.代碼是債務,越少越好
3.你擁有的代碼越多,添加新內(nèi)容所要付出的成本就越高
4.通過案例分析讓代碼庫盡可能小的方法:
5.通過國際研發(fā)中心電信計費系統(tǒng)演示代碼是債務的思想,10多年國外研發(fā)團隊設計與研發(fā)第一版本,目前幾百人在維護
通過項目演示通過重構如何減少了一半的代碼,維護的人員的減少
項目的失敗可能歸咎于各種各樣的原因。一些項目因糟糕的需求而失敗,另一些則由于錢和時間超支了,還有少數(shù)單純是因為糟糕的管理所致。如果我們探究其根本原因,是否會發(fā)現(xiàn)所有項目失敗的罪魁禍首是糟糕的代碼呢?
Bob大叔堅信糟糕的代碼所帶來的成本之大足夠讓一個項目失敗。
內(nèi)容二 軟件界要以新視角看待代碼
1.傳統(tǒng)的軟件工程對代碼的錯誤認識
2.代碼的兩面性,代碼的靜態(tài)結構和運行時行為
3.客戶和管理者往往僅僅關注代碼的運行時的行為
4.溫伯格認為的主管必須關注代碼
5.軟件設計與代碼的關系—真正好的設計是在編碼階段一步一步而形成的,通過案例分析,設計如何根據(jù)代碼進行演化
6.編程真的是簡單的勞動嗎?
7.通過多家項目案例進行分析,傳統(tǒng)思想對代碼的種種誤解,我們提出了從3種新的角度來觀察代碼,
a)從管理者的角度,我們僅僅觀察代碼的運行時行為,導致代碼的靜態(tài)結構混亂的根源。這就是代碼的冰山原理,大量垃圾代碼隱藏在冰山之下。
b)設計師的角度認為只要有好的設計,軟件質(zhì)量就可以保證。其實我們認為代碼是真正唯一可以精確描述的設計文檔。
c)程序員的視角,編程真的很難,通過某一個項目案例分析,20多人一周的工作量就為幾行代碼問題
第2單元編程價值觀 內(nèi)容一:編程價值觀
1.編程的方法學
2.什么是好的代碼,我們卻認為“Good code is not bad code !”
3.編程價值觀---溝通,簡單,靈活
4.價值觀決定行為
5.優(yōu)秀代碼的評價標準, 什么是高質(zhì)量編碼? 特征是什么?
6.軟件代碼的可讀性
7.代碼的可擴展性
8.糟糕代碼的特征
9.劣質(zhì)代碼的代價
10.大師評價整潔代碼的標準
11.通過大量項目案例分析,什么是好的代碼,對好代碼新的認識
第二篇: 編程是一種技藝-------實踐篇
第3單元 高質(zhì)量函數(shù)(該內(nèi)容較多,根據(jù)實際情況調(diào)整) 內(nèi)容一:高質(zhì)量函數(shù)/過程
1.為什么需要函數(shù)
2.函數(shù)復雜度度量
3.函數(shù)圈復雜度以及度量
4.函數(shù)抽象層次-單一抽象層次原則SLAP(Single Level of Abstrction Principle)
5.函數(shù)實現(xiàn)模式之—組合函數(shù)(Composed Method)
6.萬惡之源—函數(shù)過長
7.函數(shù)的單一職責
8.函數(shù)第一原則:是要短小,函數(shù)第二原則:是還要短小,函數(shù)第三原則:是必須短小
9.函數(shù)重構之道—抽取方法(Extract Method)和抽取對象函數(shù)
10.函數(shù)命名—怎樣取好的函數(shù)名
11.通過大量項目代碼分析,函數(shù)的遇到的各種問題,如何編程高質(zhì)量函數(shù)
內(nèi)容二:函數(shù)易理解與溝通
1.函數(shù)主體流
2.函數(shù)的異常處理
3.函數(shù)主題流程簡化方法1-助手方法
4.助手方法的應用場景
5.助手方法的效果
6.函數(shù)主題流程簡化方法2-函數(shù)對象(MethodObject)
7.通過真實項目代碼進行分析,如果提高代碼的可讀性
內(nèi)容三:函數(shù)靈活/易可擴展---函數(shù)接縫
1.歷史遺留代碼維護問題
2.某電信研發(fā)中心的維護問題—開發(fā)維護的效率問題。
3.增加一個功能特性的成本并不單單是為這些功能編碼所花費時間的成本,還應該包括特性擴展的障礙成本。
4.代碼的可維護成本分析—通過大量案例分析
a)確定需要修改哪些部分有多難
b)必要的改動有多少
c)實現(xiàn)改動對系統(tǒng)其他部分的影響有多大
5.如何實現(xiàn)代碼的易擴展—函數(shù)接縫
6.接縫(seam),指程序中的一些特殊的點,在這些點上你無需做任何修改就可以達到改動程序行為的目的
7.通過案例分析,如何實現(xiàn)函數(shù)的靈活/易擴展。
內(nèi)容四:利用多態(tài)解決復雜表達式
1.面向?qū)ο蠖鄳B(tài)技術的新認識
2.減少使用if語句,重構到多態(tài)
3.以State/Strategy取代類型代碼
4.引入Null Object
5.以Command替換條件調(diào)度程序
6.轉(zhuǎn)移聚集操作到Visitor
7.轉(zhuǎn)移裝飾功能到Decorator
8.通過大量項目代碼演示多態(tài)可以解決的編程問題
內(nèi)容五:函數(shù)的錯誤處理和異常管理
1.函數(shù)的錯誤處理
2.使用異常而非返回碼
3.依賴磁鐵(Dependeny magent)
4.主體流-明確表達控制流的主體
5.異常流-盡可能清晰地表達異??刂屏?,而不干擾對主體流的表達
6.標準的異常處理9種方法
7.通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理
第三篇: 編程是一種習慣-------管理篇
第4單元 代碼重構 內(nèi)容一:代碼重構
1.重構必然性
2.破窗效應與技術債務
3.實際重構遇到的4大問題
4.介紹常見的重構技術
5.重構到模式的目錄
6.通過多個案例分析,重構面臨的問題和解決之道
第5單元 修改遺留系統(tǒng)代碼 內(nèi)容一:修改遺留項目代碼
1.必須修改遺留的代碼起因
2.遺留代碼修改危險事項
3.如何對依賴代碼做測試
4.依賴代碼的感知與分離
5.依賴代碼修改的接縫技術
6.修改依賴代碼的工具
7.降低風險的措施
8.接依賴技術
9.通過多個大型項目案例分析,如何修改遺留代碼,分析如何解耦
內(nèi)容二:拒絕退化-如何修改遺留系統(tǒng),而不破壞現(xiàn)有系統(tǒng)結構
1.拒絕退化—“首先不要傷害”
2.Sprout Method
3.Sprout Class
4.Wrap Method
5.Wrap Method
6.通過案例分析,如何修改遺留代碼,而不破壞現(xiàn)有系統(tǒng)代碼結構
第6單元 代碼質(zhì)量體系佳實踐 內(nèi)容一:代碼質(zhì)量管理4個現(xiàn)代化
1.代碼管理的4個現(xiàn)代化
a)質(zhì)量量化(如何設置質(zhì)量指標)
b)工具化(如何尋找合適的工具
c)自動化(把流程自動化,忘記流程)
d)持續(xù)優(yōu)化(反思與優(yōu)化)
2.多家電信研發(fā)中心,如何實現(xiàn)4個代碼現(xiàn)代化
內(nèi)容二:代碼靜態(tài)分析工具
1.代碼靜態(tài)分析工具概述
2.以Java語言代碼靜態(tài)分析工具為例介紹,該內(nèi)容的思想仍然適合其他語言
a)Sonar集成平臺
b)CheckStyle:用于編碼標準
c)PMD 的 CPD:幫助發(fā)現(xiàn)代碼重復
d)Coverlipse:測量代碼覆蓋率
e)JDepend:提供依賴項分析
f)Metric:有效地查出復雜度
g)其他語言相關代碼靜態(tài)分析工具
3.通過案例演示工具在項目之中的應用
內(nèi)容三:代碼評審
代碼結構分析、代碼質(zhì)量度量、代碼覆蓋率分析方法,代碼審查的形式、技術、技巧和流程,在代碼評審環(huán)節(jié)有效發(fā)現(xiàn)代碼隱藏問題,代碼評審具體方法和審核的具體內(nèi)容,審核效果分析,代碼評審工作的組織結構設計,組織內(nèi)人員工作安排;
1.代碼評審前期準備
2.代碼評審的代碼量
3.代碼評審的檢查表
4.代碼評審的總結與學習
內(nèi)容四:代碼質(zhì)量管理體系
1.結合國內(nèi)多家研發(fā)中心的代碼管理經(jīng)驗分享
2.代碼質(zhì)量體系的建立 |