代碼整潔之道 軟件高質(zhì)量代碼體系最佳實踐

開課地點：	北京
授課時間：	3天
授課顧問：	劉捷
開課時間：	2014-09-27
市場報價：	6800
購買價格：	5440
課程排期	開課城市 開課日期 授課周期   北京 2014-09-27 3天
審核時間：	我要報名2014-09-22 15:23:08

　　

 

　　課程內(nèi)容

　　第一篇： 編程是一種態(tài)度-------價值觀

　　第1單元 代碼就是債務(wù)

　　內(nèi)容一：代碼是債務(wù)

　　1. 代碼的認識---代碼就是債務(wù)

　　2. 代碼是債務(wù)，越少越好

　　3. 你擁有的代碼越多，添加新內(nèi)容所要付出的成本就越高

　　4. 通過案例分析讓代碼庫盡可能小的方法：

　　5. 通過國際研發(fā)中心電信計費系統(tǒng)演示代碼是債務(wù)的思想，10多年國外研發(fā)團隊設(shè)計與研發(fā)第一版本，目前幾百人在維護

　　通過項目演示通過重構(gòu)如何減少了一半的代碼，維護的人員的減少

　　項目的失敗可能歸咎于各種各樣的原因。一些項目因糟糕的需求而失敗，另一些則由于錢和時間超支了，還有少數(shù)單純是因為糟糕的管理所致。如果我們探究其根本原因，是否會發(fā)現(xiàn)所有項目失敗的罪魁禍?zhǔn)资窃愀獾拇�碼呢?

　　Bob大叔堅信糟糕的代碼所帶來的成本之大足夠讓一個項目失敗。

　　內(nèi)容二軟件界要以新視角看待代碼

　　1. 傳統(tǒng)的軟件工程對代碼的錯誤認識

　　2. 代碼的兩面性，代碼的靜態(tài)結(jié)構(gòu)和運行時行為

　　3. 客戶和管理者往往僅僅關(guān)注代碼的運行時的行為

　　4. 溫伯格認為的主管必須關(guān)注代碼

　　5. 軟件設(shè)計與代碼的關(guān)系—真正好的設(shè)計是在編碼階段一步一步而形成的,通過案例分析，設(shè)計如何根據(jù)代碼進行演化

　　6. 編程真的是簡單的勞動嗎?

　　7. 通過多家項目案例進行分析，傳統(tǒng)思想對代碼的種種誤解，我們提出了從3種新的角度來觀察代碼，

　　1) 從管理者的角度，我們僅僅觀察代碼的運行時行為，導(dǎo)致代碼的靜態(tài)結(jié)構(gòu)混亂的根源。這就是代碼的冰山原理，大量垃圾代碼隱藏在冰山之下。

　　2) 設(shè)計師的角度認為只要有好的設(shè)計，軟件質(zhì)量就可以保證。其實我們認為代碼是真正唯一可以精確描述的設(shè)計文檔。

　　3) 程序員的視角，編程真的很難，通過某一個項目案例分析，20多人一周的工作量就為幾行代碼問題

　　第2單元編程價值觀

　　內(nèi)容一：編程價值觀

　　1. 編程的方法學(xué)

　　2. 什么是好的代碼，我們卻認為“Good code is not bad code !”

　　3. 編程價值觀---溝通,簡單,靈活

　　4. 價值觀決定行為

　　5. 優(yōu)秀代碼的評價標(biāo)準(zhǔn)

　　什么是高質(zhì)量編碼? 特征是什么?

　　6. 軟件代碼的可讀性

　　7. 代碼的可擴展性

　　8. 糟糕代碼的特征

　　9. 劣質(zhì)代碼的代價

　　10. 大師評價整潔代碼的標(biāo)準(zhǔn)

　　11. 通過大量項目案例分析，什么是好的代碼，對好代碼新的認識

　　第二篇： 編程是一種技藝-------實踐篇

　　第3單元 高質(zhì)量函數(shù)

　　內(nèi)容一：高質(zhì)量函數(shù)/過程

　　1. 為什么需要函數(shù)

　　2. 函數(shù)復(fù)雜度度量

　　3. 函數(shù)圈復(fù)雜度以及度量

　　4. 函數(shù)抽象層次-單一抽象層次原則SLAP(Single Level of Abstrction Principle)

　　5. 函數(shù)實現(xiàn)模式之—組合函數(shù)(Composed Method)

　　6. 萬惡之源—函數(shù)過長

　　7. 函數(shù)的單一職責(zé)

　　8. 函數(shù)第一原則:是要短小,函數(shù)第二原則:是還要短小,函數(shù)第三原則:是必須短小

　　9. 函數(shù)重構(gòu)之道—抽取方法(Extract Method)和抽取對象函數(shù)

　　10. 函數(shù)命名—怎樣取好的函數(shù)名

　　11. 通過大量項目代碼分析,函數(shù)的遇到的各種問題,如何編程高質(zhì)量函數(shù)

　　內(nèi)容二：函數(shù)易理解與溝通

　　1. 函數(shù)主體流

　　2. 函數(shù)的異常處理

　　3. 函數(shù)主題流程簡化方法1-助手方法

　　4. 助手方法的應(yīng)用場景

　　5. 助手方法的效果

　　6. 函數(shù)主題流程簡化方法2-函數(shù)對象(MethodObject)

　　7. 通過真實項目代碼進行分析，如果提高代碼的可讀性

　　內(nèi)容三：函數(shù)靈活/易可擴展---函數(shù)接縫

　　1. 歷史遺留代碼維護問題

　　2. 某電信研發(fā)中心的維護問題—開發(fā)維護的效率問題。

　　3. 增加一個功能特性的成本并不單單是為這些功能編碼所花費時間的成本，還應(yīng)該包括特性擴展的障礙成本。

　　4. 代碼的可維護成本分析—通過大量案例分析

　　1) 確定需要修改哪些部分有多難

　　2) 必要的改動有多少

　　3) 實現(xiàn)改動對系統(tǒng)其他部分的影響有多大

　　5. 如何實現(xiàn)代碼的易擴展—函數(shù)接縫

　　6. 接縫(seam)，指程序中的一些特殊的點，在這些點上你無需做任何修改就可以達到改動程序行為的目的

　　7. 通過案例分析，如何實現(xiàn)函數(shù)的靈活/易擴展。

　　內(nèi)容四：函數(shù)參數(shù)

　　1. 函數(shù)參數(shù)過長

　　2. 最理想的參數(shù)數(shù)量是零,其次是一,再次是二,有足夠的理由才能使用三個以上參數(shù).

　　3. 函數(shù)參數(shù)重構(gòu)之道-引入?yún)��?shù)對象(introduce parameter object

　　4. 函數(shù)參數(shù)的順序.

　　5. 不要把程序參數(shù)當(dāng)做工作變量/臨時變量

　　6. 函數(shù)參數(shù)模式-collecting parameter

　　7. 函數(shù)返回值

　　8. 通過大量項目代碼是函數(shù)參數(shù)問題

　　9. 演示函參數(shù)的重構(gòu)

　　內(nèi)容五：變量

　　1. “一旦了解在程序設(shè)計中如何使用變量，他就掌握了程序設(shè)計的精華。”-Dijkstra

　　2. 為什么需要變量—變量的引入的理由

　　3. 單一變量用途

　　4. 變量與方法

　　5. 變量作用域

　　6. 變量聲明與初始化

　　7. 通過案例分析， 函數(shù)的變量如何處理與控制。

　　內(nèi)容六：函數(shù)代碼重復(fù)

　　1. 重復(fù)的危害

　　2. 強加的重復(fù)/無意的重復(fù)/無耐心的重復(fù)/開發(fā)者之間的重復(fù)

　　3. 不要重復(fù)自己DRY—Don't Repeat Yourself Principle

　　4. Make It Easy to Reuse(讓復(fù)用變得容易)

　　5. 魔法數(shù)(Magic number)

　　6. 重復(fù)性代碼(Duplicated Code)

　　7. 接口不同的相似類(Alternative

　　Classes with Different Interfaces)

　　8. 系統(tǒng)分離關(guān)注點

　　9. 系統(tǒng)架構(gòu)的基礎(chǔ)通用服務(wù)組件

　　10. 通過某項目代碼是介紹重復(fù)編碼問題

　　11. 演示研發(fā)過程之中的常見重復(fù)問題，以及如何解決

　　內(nèi)容七：條件表達式

　　1. 復(fù)雜表達式的簡化

　　2. IF/ELSE語句應(yīng)該如何編寫

　　3. Switch/Case語句應(yīng)該如何編寫

　　4. 復(fù)雜條件表示式的危害

　　5. 過分深層的縮進，或者“嵌套”，已經(jīng)困擾了計算機界達25年之久，并且至今仍然是產(chǎn)生混亂代碼的罪魁禍?zhǔn)字��?/p>

　　6. 復(fù)雜表達式重構(gòu)之道—引入解釋變量/分解條件/抽取方法計算條件

　　7. 表驅(qū)動法-多級嵌套IF語句的必然之道

　　8. 表驅(qū)動法使用總則

　　9. 某保險項目表驅(qū)動法應(yīng)用案例分析

　　10. 通過大量項目代碼演示條件表達式編碼問題

　　11. 復(fù)雜表達式的注意事項,如何解決

　　內(nèi)容八：利用多態(tài)解決復(fù)雜表達式

　　1. 面向?qū)ο蠖鄳B(tài)技術(shù)的新認識

　　2. 減少使用if語句,重構(gòu)到多態(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. 盡管組織直線代碼是一個相當(dāng)簡單的任務(wù)，代碼結(jié)構(gòu)上的不合理會對代碼的質(zhì)量，正確性，可讀性和可維護性帶來影響。

　　2. 把函數(shù)代碼分成“段落”

　　3. 選擇一個有意義的順序，始終一致的使用它

　　4. 應(yīng)該把代碼組織得一次只做一件事情

　　5. 組織直線型代碼。嵌套可以，但是不應(yīng)該交疊

　　6. 系統(tǒng)應(yīng)該由許多短小的函數(shù)而不是少量巨大的大函數(shù)組成!

　　7. 系統(tǒng)應(yīng)該由許多短小的類而不是少量巨大的大類組成!

　　8. 把子程序提取另一個程序，不會降低整個程序的復(fù)雜度，只是把決策點轉(zhuǎn)移到其他地方。

　　9. 但是可以降低你在同一時間必須關(guān)注的復(fù)雜度水平。重點是要降低你需要在頭腦中同時考慮的項目的數(shù)量，所以一個給定子程序的復(fù)雜度是有價值的。

　　10. 通過大量真實案例的代碼進行分析函數(shù)的代碼的組織技術(shù)

　　內(nèi)容十：函數(shù)的錯誤處理和異常管理

　　1. 函數(shù)的錯誤處理

　　2. 使用異常而非返回碼

　　3. 依賴磁鐵(Dependeny magent)

　　4. 主體流-明確表達控制流的主體

　　5. 異常流-盡可能清晰地表達異常控制流，而不干擾對主體流的表達

　　6. 標(biāo)準(zhǔn)的異常處理9種方法

　　7. 通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理

　　第4單元 高質(zhì)量類

　　內(nèi)容一：高質(zhì)量類

　　1. 類的基礎(chǔ):抽象數(shù)據(jù)類

　　2. 需要用到ADT的場景

　　3. 使用ADT的益處

　　4. 基本類型依賴壞味道

　　5. 數(shù)據(jù)泥團壞味道

　　6. 案例—通過電信項目介紹數(shù)據(jù)的抽象

　　7. 通過大量項目代碼演示數(shù)據(jù)抽象類型解決的問題

　　內(nèi)容二：面向?qū)ο笤O(shè)計----職責(zé)分配

　　1. 單一職責(zé)原則

　　2. RDD-職責(zé)驅(qū)動的面向?qū)ο笤O(shè)計方法

　　3. 上帝類，代碼之中的大量的上帝類

　　4. 通過案例分析，如何進行設(shè)計高質(zhì)量類和重構(gòu)

　　內(nèi)容三：面向?qū)ο蟮木幊?/p>

　　1. 上帝類/過大的類--違反單一職責(zé)

　　2. 依戀情結(jié)-一個方法視乎過于強調(diào)處理其他類的數(shù)據(jù)，而不是處理自己的數(shù)據(jù)

　　3. 發(fā)散式改變

　　4. 散彈式修改

　　5. 消息鏈

　　6. 中間人

　　7. 不當(dāng)?shù)木o密性

　　8. 案例—通過電信項目介紹OOP

　　第5單元 單元測試與代碼可測試性

　　內(nèi)容一：單元測試

　　1. 單元測試基本知識

　　2. 單元測試框架提供了什么功能

　　3. 好的測試是什么樣子的

　　4. 為什么要寫單元測試，為什么不寫單元測試

　　5. 為什么要寫"好"的單元測試

　　6. 通過案例分析單元測試的基本概念，以及如何評價好的單元測試，單元測試為價值。

　　內(nèi)容二：編寫可測試代碼

　　1. 如何編寫可信賴的測試

　　2. 如何編寫可維護性的測試

　　3. 如何編寫可讀的測試

　　4. 測試代碼的重構(gòu)

　　5. 通過大量真實項目案例分析如何編寫可測試性代碼

　　第三篇： 編程是一種習(xí)慣-------管理篇

　　第6單元 代碼重構(gòu)

　　內(nèi)容一：代碼重構(gòu)

　　1. 重構(gòu)必然性

　　2. 破窗效應(yīng)與技術(shù)債務(wù)

　　3. 實際重構(gòu)遇到的4大問題

　　4. 介紹常見的重構(gòu)技術(shù)

　　5. 重構(gòu)到模式的目錄

　　6. 通過多個案例分析，重構(gòu)面臨的問題和解決之道

　　第7單元 修改遺留系統(tǒng)代碼

　　內(nèi)容一：修改遺留項目代碼

　　1. 必須修改遺留的代碼起因

　　2. 遺留代碼修改危險事項

　　3. 如何對依賴代碼做測試

　　4. 依賴代碼的感知與分離

　　5. 依賴代碼修改的接縫技術(shù)

　　6. 修改依賴代碼的工具

　　7. 降低風(fēng)險的措施

　　8. 接依賴技術(shù)

　　9. 通過多個大型項目案例分析，如何修改遺留代碼，分析如何解耦

　　內(nèi)容二：拒絕退化-如何修改遺留系統(tǒng)，而不破壞現(xiàn)有系統(tǒng)結(jié)構(gòu)

　　1. 拒絕退化—“首先不要傷害”

　　2. Sprout Method

　　3. Sprout Class

　　4. Wrap Method

　　5. Wrap Method

　　6. 通過案例分析，如何修改遺留代碼，而不破壞現(xiàn)有系統(tǒng)代碼結(jié)構(gòu)

　　第8單元 代碼質(zhì)量體系最佳實踐

　　內(nèi)容一：代碼質(zhì)量管理4個現(xiàn)代化

　　1. 代碼管理的4個現(xiàn)代化

　　1) 質(zhì)量量化(如何設(shè)置質(zhì)量指標(biāo))

　　2) 工具化(如何尋找合適的工具

　　3) 自動化(把流程自動化，忘記流程)

　　4) 持續(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)容的思想仍然適合其他語言

　　1) Sonar集成平臺

　　2) CheckStyle：用于編碼標(biāo)準(zhǔn)

　　3) PMD 的 CPD：幫助發(fā)現(xiàn)代碼重復(fù)

　　4) Coverlipse：測量代碼覆蓋率

　　5) JDepend：提供依賴項分析

　　6) Metric：有效地查出復(fù)雜度

　　7) 其他語言相關(guān)代碼靜態(tài)分析工具

　　3. 通過案例演示工具在項目之中的應(yīng)用

　　內(nèi)容三：代碼評審

　　代碼結(jié)構(gòu)分析、代碼質(zhì)量度量、代碼覆蓋率分析方法，代碼審查的形式、技術(shù)、技巧和流程，在代碼評審環(huán)節(jié)有效發(fā)現(xiàn)代碼隱藏問題，代碼評審具體方法和審核的具體內(nèi)容，審核效果分析，代碼評審工作的組織結(jié)構(gòu)設(shè)計，組織內(nèi)人員工作安排;

　　1. 代碼評審前期準(zhǔn)備

　　2. 代碼評審的代碼量

　　3. 代碼評審的檢查表

　　4. 代碼評審的總結(jié)與學(xué)習(xí)

　　內(nèi)容四：代碼質(zhì)量管理體系

　　1. 結(jié)合國內(nèi)多家研發(fā)中心的代碼管理經(jīng)驗分享

　　2. 代碼質(zhì)量體系的建立

　　師資力量

　　劉捷

　　曾任職BEA(中國)資深軟件架構(gòu)師

　　曾任職BEA(中國)資深軟件架構(gòu)師，十余年的企業(yè)軟件架構(gòu)、開發(fā)和管理經(jīng)驗, 側(cè)重于企業(yè)應(yīng)用軟件架構(gòu)設(shè)計.主要負責(zé)客戶大型項目的架構(gòu)設(shè)計和研發(fā)。

　　作為技術(shù)專家保證項目的成功實施，運行和維護。參加過全國/全省多個大型的計算機應(yīng)用項目，擅長的領(lǐng)域包括電信，金融、稅務(wù),大型互聯(lián)網(wǎng)web2.0應(yīng)用等。此前就職于IBM，任軟件架構(gòu)師。 在此之前曾任日本東京一家軟件企業(yè)的資深技術(shù)顧問。