課程簡介
軟件質(zhì)量,不但依賴于架構(gòu),設(shè)計以及項目管理,而且與代碼質(zhì)量緊密相關(guān).這一點,無論你使用什么開發(fā)技術(shù),都不得不承認. 代碼是程序員溝通最直接的手段，代碼是技術(shù)交流的手段，代碼是需求交流的途徑。重視代碼，回歸本源，曾經(jīng)我們遠離代碼，談架構(gòu)設(shè)計，談UML,談開發(fā)流程。如今我們落地,找回軟件的本源，徹徹底底看清代碼、深入思考代碼。那些一流的研發(fā)中心非常重視代碼,Facebook就有經(jīng)典的Code wins arguments（代碼贏得爭論）。在Facebook 做 code review時間大約占50%，管理者對代碼質(zhì)量負有一定責任 。甚至代碼質(zhì)量高于一切：Facebook Code review是重點KPI考核的對象，實行連坐制，如果因為代碼質(zhì)量問題，那么產(chǎn)生的KPI責任包括領(lǐng)導30％、程序員50％、審核人員20％。 課程可講2-5天。
目標收益
該課程適應于各個階段的技術(shù)人員.初級工程師能夠透過大師的眼睛來看待編程,了解編程的價值觀和原則;具有豐富經(jīng)驗的設(shè)計師和架構(gòu)師可以通過實現(xiàn)模式進行反思,探究成功實踐背后的意義.把價值觀,原則和開發(fā)實踐結(jié)合;管理者通過學習業(yè)界著名研發(fā)中心的管理經(jīng)驗和失敗的教訓,來制定自己公司的代碼管理策略.質(zhì)量管理相關(guān)人員學習如何定制代碼質(zhì)量指標，通過哪些工具進行監(jiān)控，怎樣管理代碼質(zhì)量。
培訓對象
各類軟件企業(yè)和研發(fā)中心的程序員、軟件設(shè)計師、架構(gòu)師, 項目經(jīng)理,質(zhì)量部門員工。
課程大綱
|
第一篇： 編程是一種態(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)所有項目失敗的罪魁禍首是糟糕的代碼呢？ 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種新的角度來觀察代碼， a)從管理者的角度，我們僅僅觀察代碼的運行時行為，導致代碼的靜態(tài)結(jié)構(gòu)混亂的根源。這就是代碼的冰山原理，大量垃圾代碼隱藏在冰山之下。 b)設(shè)計師的角度認為只要有好的設(shè)計，軟件質(zhì)量就可以保證。其實我們認為代碼是真正唯一可以精確描述的設(shè)計文檔。 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ù)重構(gòu)之道—抽取方法(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)技術(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.函數(shù)的錯誤處理 2.使用異常而非返回碼 3.依賴磁鐵（Dependeny magent） 4.主體流-明確表達控制流的主體 5.異常流-盡可能清晰地表達異?？刂屏?，而不干擾對主體流的表達 6.標準的異常處理9種方法 7.通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理 |
| 第4單元--高質(zhì)量函數(shù) |
內(nèi)容一：函數(shù)10個一 1.每個變量只用于單一用途 2.每一個行代碼只表達一件事 3.一個循環(huán)只做一件事 4.單一抽象層次原則 5.代碼組織得一次只做一件事情 6.函數(shù)體內(nèi)只關(guān)注一種變化的原因（動機） 7.函數(shù)應該遵守單一職責 8.函數(shù)圈復雜應該小于一十 9.函數(shù)第一原則是必須要短小 10.編寫函數(shù)時必須一心一意，專注，懷有謙卑的心態(tài) 8.通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理 |
| 第5單元 高質(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è)計----職責分配 1.單一職責原則 2.RDD-職責驅(qū)動的面向?qū)ο笤O(shè)計方法 3.上帝類，代碼之中的大量的上帝類 4.通過案例分析，如何進行設(shè)計高質(zhì)量類和重構(gòu) 內(nèi)容三：面向?qū)ο蟮木幊?br/>1.上帝類/過大的類--違反單一職責 2.依戀情結(jié)-一個方法視乎過于強調(diào)處理其他類的數(shù)據(jù)，而不是處理自己的數(shù)據(jù) 3.發(fā)散式改變 4.散彈式修改 5.消息鏈 6.中間人 7.不當?shù)木o密性 案例—通過電信項目介紹OOP |
| 第6單元 單元測試與代碼可測試性 |
內(nèi)容一：單元測試 11.單元測試基本知識 12.單元測試框架提供了什么功能 13.好的測試是什么樣子的 14.為什么要寫單元測試，為什么不寫單元測試 15.為什么要寫"好"的單元測試 16.通過案例分析單元測試的基本概念，以及如何評價好的單元測試，單元測試為價值。 內(nèi)容二：編寫可測試代碼 1.如何編寫可信賴的測試 2.如何編寫可維護性的測試 3.如何編寫可讀的測試 4.測試代碼的重構(gòu) 5.通過大量真實項目案例分析如何編寫可測試性代碼 |
|
第三篇： 編程是一種習慣-------管理篇 第7單元 代碼質(zhì)量度量規(guī)則 |
內(nèi)容一：軟件代碼可維護性4個分類標準 1.代碼內(nèi)部質(zhì)量的核心標準 2.可分析性（ANALYZABILITY：找到錯誤在代碼中的位置或者軟件中必須修改的部分容易程度 3.可修改性（CHANGEABILITY）：即要完成一個修改需要的工作量 4.穩(wěn)定性（STABILITY）：即修改之后出問題的程度 5.可測試性（TESTABILITY）：即能夠驗證修改的結(jié)果 內(nèi)容二：軟件代碼質(zhì)量 1.ANALYZABILITY = VG + STMT + AVGS + COMF 2.CHANGEABILITY = PARA + LVAR + VOCF + GOTO 3.STABILITY = NBCALLING + RETU + DRCT_CALLS + PARA 4.TESTABILITY = DRCT_CALLS + LEVL + PATH + PARA |
| 第8單元 修改遺留系統(tǒng)代碼與重構(gòu) |
內(nèi)容一：修改遺留項目代碼 1.必須修改遺留的代碼起因 2.遺留代碼修改危險事項 3.如何對依賴代碼做測試 4.依賴代碼的感知與分離 5.依賴代碼修改的接縫技術(shù) 6.修改依賴代碼的工具 7.降低風險的措施 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) 內(nèi)容三：代碼重構(gòu) 1.重構(gòu)必然性 2.破窗效應與技術(shù)債務(wù) 3.實際重構(gòu)遇到的4大問題 4.介紹常見的重構(gòu)技術(shù) 5.重構(gòu)到模式的目錄 6.通過多個案例分析，重構(gòu)面臨的問題和解決之道 |
| 第9 AEP自動化錯誤預防 |
內(nèi)容一：自動化預防-AEP 1.Automated Error Prevention（簡稱AEP），是指通過整個軟件開發(fā)周期中自動地預防錯誤來提高產(chǎn)品質(zhì)量 2.自動化錯誤預防五大法則 3.應用行業(yè)最佳實踐來防止普遍錯誤并建立全方位的錯誤預防基礎(chǔ)---案例分析 4.按需要修改實踐來預防特殊的錯誤 5.確保每個小組正確地，始終如一地貫徹執(zhí)行AEP 6.循環(huán)漸進地采用每一個實踐 7.利用統(tǒng)計來穩(wěn)定每一個過程，讓它發(fā)揮價值 8.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 內(nèi)容二：BugDetective 1.BugDetective概述 2.BugDetective規(guī)則 3.Parasoft公司旗下產(chǎn)品C++Test BugDetective分析技術(shù)，該技術(shù)使用了幾種分析技巧，包括模擬應用程序執(zhí)行路徑，以識別可能觸發(fā)運行時缺陷的路徑。檢測到的缺陷包括，使用未初始化的內(nèi)存、引用空指針、除數(shù)為零、內(nèi)存和資源泄漏。 9.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 |
| 第10單元 代碼質(zhì)量體系最佳實踐 |
內(nèi)容一：代碼質(zhì)量管理4個現(xiàn)代化 1.代碼管理的4個現(xiàn)代化 a)質(zhì)量量化（如何設(shè)置質(zhì)量指標） b)工具化（如何尋找合適的工具 c)自動化（把流程自動化，忘記流程） d)持續(xù)優(yōu)化（反思與優(yōu)化） 2.多家電信研發(fā)中心，如何實現(xiàn)4個代碼現(xiàn)代化 內(nèi)容二：代碼靜態(tài)分析 1.程序靜態(tài)分析（Program Static Analysis）是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術(shù)對程序代碼進行掃描，驗證代碼是否滿足規(guī)范性、安全性、可靠性、可維護性等指標的一種代碼分析技術(shù)。 2.程序靜態(tài)分析（Program Static Analysis）可以幫助軟件開發(fā)人員、質(zhì)量保證人員查找代碼中存在的結(jié)構(gòu)性錯誤、安全漏洞等問題，從而保證軟件的整體質(zhì)量 3.靜態(tài)分析的特點 4.常用靜態(tài)分析技術(shù) 5.靜態(tài)分析實現(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)其他語言相關(guān)代碼靜態(tài)分析工具 3.通過案例演示工具在項目之中的應用 內(nèi)容四：代碼評審 代碼結(jié)構(gòu)分析、代碼質(zhì)量度量、代碼覆蓋率分析方法，代碼審查的形式、技術(shù)、技巧和流程，在代碼評審環(huán)節(jié)有效發(fā)現(xiàn)代碼隱藏問題，代碼評審具體方法和審核的具體內(nèi)容，審核效果分析，代碼評審工作的組織結(jié)構(gòu)設(shè)計，組織內(nèi)人員工作安排； 1.代碼評審前期準備 2.代碼評審的代碼量 3.代碼評審的檢查表 4.代碼評審的總結(jié)與學習 內(nèi)容五：代碼質(zhì)量管理體系 1.結(jié)合國內(nèi)多家研發(fā)中心的代碼管理經(jīng)驗分享 2.代碼質(zhì)量體系的建立 |
|
第一篇： 編程是一種態(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)所有項目失敗的罪魁禍首是糟糕的代碼呢？ 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種新的角度來觀察代碼， a)從管理者的角度，我們僅僅觀察代碼的運行時行為，導致代碼的靜態(tài)結(jié)構(gòu)混亂的根源。這就是代碼的冰山原理，大量垃圾代碼隱藏在冰山之下。 b)設(shè)計師的角度認為只要有好的設(shè)計，軟件質(zhì)量就可以保證。其實我們認為代碼是真正唯一可以精確描述的設(shè)計文檔。 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ù)重構(gòu)之道—抽取方法(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)技術(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.函數(shù)的錯誤處理 2.使用異常而非返回碼 3.依賴磁鐵（Dependeny magent） 4.主體流-明確表達控制流的主體 5.異常流-盡可能清晰地表達異?？刂屏鳎桓蓴_對主體流的表達 6.標準的異常處理9種方法 7.通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理 |
|
第4單元--高質(zhì)量函數(shù) 內(nèi)容一：函數(shù)10個一 1.每個變量只用于單一用途 2.每一個行代碼只表達一件事 3.一個循環(huán)只做一件事 4.單一抽象層次原則 5.代碼組織得一次只做一件事情 6.函數(shù)體內(nèi)只關(guān)注一種變化的原因（動機） 7.函數(shù)應該遵守單一職責 8.函數(shù)圈復雜應該小于一十 9.函數(shù)第一原則是必須要短小 10.編寫函數(shù)時必須一心一意，專注，懷有謙卑的心態(tài) 8.通過大量真實案例的代碼進行分析函數(shù)的錯誤處理和異常處理 |
|
第5單元 高質(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è)計----職責分配 1.單一職責原則 2.RDD-職責驅(qū)動的面向?qū)ο笤O(shè)計方法 3.上帝類，代碼之中的大量的上帝類 4.通過案例分析，如何進行設(shè)計高質(zhì)量類和重構(gòu) 內(nèi)容三：面向?qū)ο蟮木幊?br/>1.上帝類/過大的類--違反單一職責 2.依戀情結(jié)-一個方法視乎過于強調(diào)處理其他類的數(shù)據(jù)，而不是處理自己的數(shù)據(jù) 3.發(fā)散式改變 4.散彈式修改 5.消息鏈 6.中間人 7.不當?shù)木o密性 案例—通過電信項目介紹OOP |
|
第6單元 單元測試與代碼可測試性 內(nèi)容一：單元測試 11.單元測試基本知識 12.單元測試框架提供了什么功能 13.好的測試是什么樣子的 14.為什么要寫單元測試，為什么不寫單元測試 15.為什么要寫"好"的單元測試 16.通過案例分析單元測試的基本概念，以及如何評價好的單元測試，單元測試為價值。 內(nèi)容二：編寫可測試代碼 1.如何編寫可信賴的測試 2.如何編寫可維護性的測試 3.如何編寫可讀的測試 4.測試代碼的重構(gòu) 5.通過大量真實項目案例分析如何編寫可測試性代碼 |
|
第三篇： 編程是一種習慣-------管理篇 第7單元 代碼質(zhì)量度量規(guī)則 內(nèi)容一：軟件代碼可維護性4個分類標準 1.代碼內(nèi)部質(zhì)量的核心標準 2.可分析性（ANALYZABILITY：找到錯誤在代碼中的位置或者軟件中必須修改的部分容易程度 3.可修改性（CHANGEABILITY）：即要完成一個修改需要的工作量 4.穩(wěn)定性（STABILITY）：即修改之后出問題的程度 5.可測試性（TESTABILITY）：即能夠驗證修改的結(jié)果 內(nèi)容二：軟件代碼質(zhì)量 1.ANALYZABILITY = VG + STMT + AVGS + COMF 2.CHANGEABILITY = PARA + LVAR + VOCF + GOTO 3.STABILITY = NBCALLING + RETU + DRCT_CALLS + PARA 4.TESTABILITY = DRCT_CALLS + LEVL + PATH + PARA |
|
第8單元 修改遺留系統(tǒng)代碼與重構(gòu) 內(nèi)容一：修改遺留項目代碼 1.必須修改遺留的代碼起因 2.遺留代碼修改危險事項 3.如何對依賴代碼做測試 4.依賴代碼的感知與分離 5.依賴代碼修改的接縫技術(shù) 6.修改依賴代碼的工具 7.降低風險的措施 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) 內(nèi)容三：代碼重構(gòu) 1.重構(gòu)必然性 2.破窗效應與技術(shù)債務(wù) 3.實際重構(gòu)遇到的4大問題 4.介紹常見的重構(gòu)技術(shù) 5.重構(gòu)到模式的目錄 6.通過多個案例分析，重構(gòu)面臨的問題和解決之道 |
|
第9 AEP自動化錯誤預防 內(nèi)容一：自動化預防-AEP 1.Automated Error Prevention（簡稱AEP），是指通過整個軟件開發(fā)周期中自動地預防錯誤來提高產(chǎn)品質(zhì)量 2.自動化錯誤預防五大法則 3.應用行業(yè)最佳實踐來防止普遍錯誤并建立全方位的錯誤預防基礎(chǔ)---案例分析 4.按需要修改實踐來預防特殊的錯誤 5.確保每個小組正確地，始終如一地貫徹執(zhí)行AEP 6.循環(huán)漸進地采用每一個實踐 7.利用統(tǒng)計來穩(wěn)定每一個過程，讓它發(fā)揮價值 8.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 內(nèi)容二：BugDetective 1.BugDetective概述 2.BugDetective規(guī)則 3.Parasoft公司旗下產(chǎn)品C++Test BugDetective分析技術(shù)，該技術(shù)使用了幾種分析技巧，包括模擬應用程序執(zhí)行路徑，以識別可能觸發(fā)運行時缺陷的路徑。檢測到的缺陷包括，使用未初始化的內(nèi)存、引用空指針、除數(shù)為零、內(nèi)存和資源泄漏。 9.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 |
|
第10單元 代碼質(zhì)量體系最佳實踐 內(nèi)容一：代碼質(zhì)量管理4個現(xiàn)代化 1.代碼管理的4個現(xiàn)代化 a)質(zhì)量量化（如何設(shè)置質(zhì)量指標） b)工具化（如何尋找合適的工具 c)自動化（把流程自動化，忘記流程） d)持續(xù)優(yōu)化（反思與優(yōu)化） 2.多家電信研發(fā)中心，如何實現(xiàn)4個代碼現(xiàn)代化 內(nèi)容二：代碼靜態(tài)分析 1.程序靜態(tài)分析（Program Static Analysis）是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術(shù)對程序代碼進行掃描，驗證代碼是否滿足規(guī)范性、安全性、可靠性、可維護性等指標的一種代碼分析技術(shù)。 2.程序靜態(tài)分析（Program Static Analysis）可以幫助軟件開發(fā)人員、質(zhì)量保證人員查找代碼中存在的結(jié)構(gòu)性錯誤、安全漏洞等問題，從而保證軟件的整體質(zhì)量 3.靜態(tài)分析的特點 4.常用靜態(tài)分析技術(shù) 5.靜態(tài)分析實現(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)其他語言相關(guān)代碼靜態(tài)分析工具 3.通過案例演示工具在項目之中的應用 內(nèi)容四：代碼評審 代碼結(jié)構(gòu)分析、代碼質(zhì)量度量、代碼覆蓋率分析方法，代碼審查的形式、技術(shù)、技巧和流程，在代碼評審環(huán)節(jié)有效發(fā)現(xiàn)代碼隱藏問題，代碼評審具體方法和審核的具體內(nèi)容，審核效果分析，代碼評審工作的組織結(jié)構(gòu)設(shè)計，組織內(nèi)人員工作安排； 1.代碼評審前期準備 2.代碼評審的代碼量 3.代碼評審的檢查表 4.代碼評審的總結(jié)與學習 內(nèi)容五：代碼質(zhì)量管理體系 1.結(jié)合國內(nèi)多家研發(fā)中心的代碼管理經(jīng)驗分享 2.代碼質(zhì)量體系的建立 |
近期公開課推薦
