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