1. 項(xiàng)目概述從“能跑就行”到“優(yōu)雅可靠”的思維躍遷“程序設(shè)計(jì)方法學(xué)”這七個(gè)字聽(tīng)起來(lái)有點(diǎn)學(xué)院派甚至有點(diǎn)老生常談。很多剛?cè)胄械呐笥芽赡軙?huì)覺(jué)得這不就是教人怎么寫(xiě)代碼嗎我學(xué)個(gè)Python語(yǔ)法看幾個(gè)框架教程不就能干活了我最初也是這么想的直到自己負(fù)責(zé)的項(xiàng)目代碼膨脹到幾萬(wàn)行改一處bug引發(fā)三處崩潰或者看著同事寫(xiě)出的“天書(shū)”般的邏輯而束手無(wú)策時(shí)才痛徹地意識(shí)到語(yǔ)法只是磚瓦方法學(xué)才是建筑藍(lán)圖。它關(guān)乎的遠(yuǎn)不止是讓程序“跑起來(lái)”而是如何讓它跑得健壯、高效、易于理解和維護(hù)尤其是在多人協(xié)作和長(zhǎng)期演進(jìn)的復(fù)雜場(chǎng)景下。簡(jiǎn)單來(lái)說(shuō)程序設(shè)計(jì)方法學(xué)是一套指導(dǎo)我們?nèi)绾蜗到y(tǒng)化、工程化地進(jìn)行軟件構(gòu)造的思維框架和原則集合。它不綁定于任何特定語(yǔ)言Java、Go、Python都適用而是高于語(yǔ)言的“元知識(shí)”。今天我們不談枯燥的理論定義而是從一個(gè)一線開(kāi)發(fā)者的視角拆解那些真正在項(xiàng)目中救過(guò)我命、提升過(guò)我效率的核心方法學(xué)實(shí)踐。無(wú)論你是正在被混亂代碼困擾的初級(jí)工程師還是希望帶領(lǐng)團(tuán)隊(duì)提升工程效能的技術(shù)負(fù)責(zé)人相信這些從實(shí)戰(zhàn)中摔打出來(lái)的經(jīng)驗(yàn)都能給你帶來(lái)直接的啟發(fā)。2. 核心思維轉(zhuǎn)變從面向過(guò)程到抽象與建模2.1 理解“抽象”是第一生產(chǎn)力新手寫(xiě)代碼往往是“面向過(guò)程”的線性思維用戶點(diǎn)擊按鈕A我就去查數(shù)據(jù)庫(kù)B然后計(jì)算C最后渲染頁(yè)面D。代碼就像一篇流水賬所有步驟都攤在主流程里。這種方法在小腳本里沒(méi)問(wèn)題但一旦邏輯復(fù)雜代碼就會(huì)變成“意大利面條”牽一發(fā)而動(dòng)全身。方法學(xué)教我們的第一課就是抽象。抽象的本質(zhì)是隱藏復(fù)雜度暴露簡(jiǎn)潔的接口。比如我們不需要關(guān)心數(shù)據(jù)庫(kù)連接池是如何管理連接的只需要調(diào)用userRepository.findById(id)我們也不需關(guān)心郵件是如何發(fā)送的只需調(diào)用emailService.sendWelcomeEmail(user)。一個(gè)實(shí)操心法當(dāng)一段代碼被注釋描述為“這里負(fù)責(zé)處理XX邏輯”時(shí)這段代碼就應(yīng)該被抽象成一個(gè)獨(dú)立的函數(shù)或類。例如你發(fā)現(xiàn)寫(xiě)了十幾行代碼來(lái)計(jì)算訂單折扣旁邊注釋著“// 計(jì)算最終價(jià)格”。這時(shí)立刻停下來(lái)將這段代碼抽成一個(gè)函數(shù)calculateFinalPrice(order)。這樣做的好處立竿見(jiàn)影主流程變得清晰閱讀代碼的人一眼就能看懂業(yè)務(wù)步驟。復(fù)用與測(cè)試折扣計(jì)算邏輯被隔離可以單獨(dú)測(cè)試也方便在其他地方復(fù)用。修改隔離未來(lái)折扣規(guī)則變化你只需要修改這一個(gè)函數(shù)而不用擔(dān)心動(dòng)到其他無(wú)關(guān)邏輯。2.2 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD的樸素應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)聽(tīng)起來(lái)高大上但其核心思想非常實(shí)用讓軟件的結(jié)構(gòu)反映真實(shí)業(yè)務(wù)的概念和邏輯。我們不需要完全照搬DDD的所有復(fù)雜概念聚合根、值對(duì)象、領(lǐng)域服務(wù)等但可以汲取其精華。實(shí)操步驟從梳理“名詞”和“動(dòng)詞”開(kāi)始。找出核心名詞在需求文檔或會(huì)議中反復(fù)出現(xiàn)的名詞往往是潛在的領(lǐng)域?qū)ο?。例如在電商系統(tǒng)中“訂單”、“商品”、“庫(kù)存”、“用戶”、“支付單”就是核心領(lǐng)域?qū)ο?。定義對(duì)象的職責(zé)為每個(gè)領(lǐng)域?qū)ο竺鞔_它“有什么數(shù)據(jù)”屬性和“能做什么”方法。關(guān)鍵原則是“信息專家模式”將操作數(shù)據(jù)的方法放在擁有這些數(shù)據(jù)的對(duì)象內(nèi)部。例如Order對(duì)象應(yīng)該有一個(gè)calculateTotalAmount()方法而不是由一個(gè)外部的OrderCalculator類來(lái)操作Order的內(nèi)部數(shù)據(jù)。建立對(duì)象間的關(guān)聯(lián)用引用對(duì)象ID或直接引用而非重復(fù)數(shù)據(jù)來(lái)表達(dá)關(guān)系。比如Order中包含userId和一系列OrderItem而不是把用戶姓名、商品詳情都復(fù)制過(guò)來(lái)。這樣做出來(lái)的代碼業(yè)務(wù)人員也能看懂大概因?yàn)樾g(shù)語(yǔ)是一致的。當(dāng)產(chǎn)品經(jīng)理說(shuō)“這里要修改訂單的狀態(tài)流轉(zhuǎn)”你就能直接找到Order類下的status字段和相關(guān)狀態(tài)變更方法。3. 設(shè)計(jì)原則寫(xiě)出“長(zhǎng)壽”代碼的基石掌握了抽象思維后需要一些更具體的原則來(lái)指導(dǎo)日常的編碼決策。下面這幾個(gè)原則是我認(rèn)為性價(jià)比最高、最常使用的。3.1 SOLID原則不只是五個(gè)字母SOLID是五個(gè)設(shè)計(jì)原則的首字母縮寫(xiě)是構(gòu)建靈活、可維護(hù)系統(tǒng)的關(guān)鍵。S (單一職責(zé)原則)一個(gè)類或模塊只應(yīng)有一個(gè)引起它變化的原因。這是最重要的原則。判斷方法試著用一句話描述這個(gè)類的職責(zé)如果句中出現(xiàn)了“和”、“以及”、“除了…還…”那它很可能違反了單一職責(zé)。注意這里的“職責(zé)”是指“變化的原因”。例如一個(gè)ReportGenerator類如果它既負(fù)責(zé)從數(shù)據(jù)庫(kù)取數(shù)據(jù)又負(fù)責(zé)生成PDF格式還負(fù)責(zé)發(fā)送郵件。那么未來(lái)數(shù)據(jù)庫(kù) schema 變化、PDF庫(kù)升級(jí)、郵件協(xié)議變更都會(huì)導(dǎo)致修改這個(gè)類。應(yīng)該拆分為DataFetcher、PdfFormatter、EmailSender三個(gè)類。O (開(kāi)閉原則)對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。意思是當(dāng)需要添加新功能時(shí)應(yīng)盡量通過(guò)添加新代碼擴(kuò)展來(lái)實(shí)現(xiàn)而非修改已有的、運(yùn)行穩(wěn)定的舊代碼。實(shí)戰(zhàn)技巧多使用策略模式、模板方法模式。例如不同的支付方式微信、支付寶、銀行卡不應(yīng)該用一堆if-else在同一個(gè)方法里判斷而是定義一個(gè)PaymentStrategy接口每種支付方式實(shí)現(xiàn)該接口。新增支付方式時(shí)只需新建一個(gè)實(shí)現(xiàn)類核心支付流程代碼無(wú)需改動(dòng)。L (里氏替換原則)子類必須能夠替換掉它們的父類而不影響程序的正確性。這要求子類不要重寫(xiě)父類已實(shí)現(xiàn)的方法來(lái)改變其行為除非是抽象方法。簡(jiǎn)單說(shuō)繼承是為了“擴(kuò)展”行為而不是“改變”或“縮小”行為。I (接口隔離原則)客戶端不應(yīng)被迫依賴于它不使用的接口。與其創(chuàng)建一個(gè)龐大的、包含很多方法的接口不如拆分成多個(gè)小而專一的接口。例子不要設(shè)計(jì)一個(gè)Animal接口里面有eat(),fly(),swim()方法然后讓Dog類實(shí)現(xiàn)fly()并拋出一個(gè)異常。應(yīng)該拆分成Eater、Flyer、Swimmer等接口讓類按需實(shí)現(xiàn)。D (依賴倒置原則)高層模塊不應(yīng)依賴低層模塊二者都應(yīng)依賴于抽象。抽象不應(yīng)依賴于細(xì)節(jié)細(xì)節(jié)應(yīng)依賴于抽象。直白解釋你的業(yè)務(wù)邏輯高層不應(yīng)該直接new一個(gè)具體的數(shù)據(jù)庫(kù)操作類低層。而應(yīng)該依賴于一個(gè)Repository接口抽象。具體用MySQL還是PostgreSQL的實(shí)現(xiàn)細(xì)節(jié)通過(guò)依賴注入如構(gòu)造函數(shù)傳入來(lái)提供。這使得更換數(shù)據(jù)庫(kù)底層時(shí)業(yè)務(wù)邏輯代碼紋絲不動(dòng)。3.2 DRY、KISS、YAGNI保持代碼清爽的日常準(zhǔn)則DRY (Don‘t Repeat Yourself)不要重復(fù)你自己。這是最基本的準(zhǔn)則。重復(fù)的代碼是維護(hù)的噩夢(mèng)。一旦發(fā)現(xiàn)相同或相似的代碼片段出現(xiàn)兩次以上立即考慮抽象。但要注意“偶然重復(fù)”和“本質(zhì)重復(fù)”的區(qū)別不要過(guò)度抽象。KISS (Keep It Simple, Stupid)保持簡(jiǎn)單、傻瓜式。用最簡(jiǎn)單直接的方式解決問(wèn)題。不要為了展示技術(shù)而使用復(fù)雜的設(shè)計(jì)模式或奇技淫巧。簡(jiǎn)單的代碼更容易被理解和維護(hù)。YAGNI (You Ain’t Gonna Need It)你將來(lái)不會(huì)需要它。在確有必要之前不要添加額外的功能或抽象。過(guò)度設(shè)計(jì)是很多項(xiàng)目變得臃腫的根源。專注于當(dāng)前明確的需求。4. 設(shè)計(jì)模式解決特定問(wèn)題的工具箱設(shè)計(jì)模式是前輩總結(jié)的、針對(duì)特定場(chǎng)景的優(yōu)雅解決方案。不要為了用模式而用模式但當(dāng)你在設(shè)計(jì)中遇到某些“臭味”時(shí)模式可能就是解藥。4.1 創(chuàng)建型模式如何優(yōu)雅地“造對(duì)象”工廠模式當(dāng)你創(chuàng)建對(duì)象的過(guò)程比較復(fù)雜需要配置、依賴其他服務(wù)或者你想集中管理對(duì)象的創(chuàng)建邏輯時(shí)使用。比如根據(jù)配置文件創(chuàng)建不同的數(shù)據(jù)庫(kù)連接實(shí)例。// 簡(jiǎn)單工廠示例 public class PaymentFactory { public static Payment createPayment(String type) { switch (type) { case wechat: return new WechatPayment(); case alipay: return new AlipayPayment(); default: throw new IllegalArgumentException(Unsupported payment type); } } }注意簡(jiǎn)單工廠在類型增多時(shí)switch會(huì)膨脹?？梢钥紤]使用“反射”或“注冊(cè)表”模式來(lái)改進(jìn)實(shí)現(xiàn)真正的開(kāi)閉原則。建造者模式適用于構(gòu)造一個(gè)屬性很多、且部分屬性可選、構(gòu)造過(guò)程復(fù)雜的對(duì)象。它能避免構(gòu)造方法參數(shù)列表過(guò)長(zhǎng)伸縮構(gòu)造函數(shù)模式也比 setter 方法構(gòu)造更安全可以保證必填屬性在構(gòu)建期間被設(shè)置。// 建造者模式示例 User user new User.Builder() .name(張三) .email(zhangsanexample.com) .age(25) // 可選 .build(); // 在build()方法內(nèi)校驗(yàn)必填字段4.2 結(jié)構(gòu)型模式如何組合類和對(duì)象適配器模式當(dāng)你想使用一個(gè)已有的類但其接口不符合你的需求時(shí)就像一個(gè)歐標(biāo)插頭需要個(gè)轉(zhuǎn)換器才能插進(jìn)國(guó)標(biāo)插座。在系統(tǒng)集成、復(fù)用舊代碼時(shí)非常常用。裝飾器模式動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)相比繼承更加靈活。Java I/O 流庫(kù)就是經(jīng)典例子BufferedInputStream裝飾FileInputStream。4.3 行為型模式對(duì)象間如何通信與合作策略模式定義一系列算法將它們封裝起來(lái)并且使它們可以相互替換。前面支付方式的例子就是策略模式的典型應(yīng)用。它消除了龐大的條件判斷語(yǔ)句。觀察者模式定義對(duì)象間的一種一對(duì)多的依賴關(guān)系當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。事件驅(qū)動(dòng)系統(tǒng)、消息訂閱/發(fā)布都是這一思想的體現(xiàn)。模板方法模式在一個(gè)方法中定義一個(gè)算法的骨架而將一些步驟延遲到子類中實(shí)現(xiàn)。使得子類可以在不改變算法結(jié)構(gòu)的情況下重新定義算法的某些特定步驟。例如一個(gè)數(shù)據(jù)導(dǎo)出流程固定步驟為準(zhǔn)備數(shù)據(jù) - 格式化數(shù)據(jù) - 寫(xiě)入輸出流。其中“格式化數(shù)據(jù)”這一步可以由子類實(shí)現(xiàn)為CSV格式化或Excel格式化。5. 代碼整潔之道可讀性即正義方法學(xué)最終要落地到一行行代碼上。整潔的代碼是高效協(xié)作的基礎(chǔ)。5.1 命名是頭等大事糟糕的命名是代碼的“第一殺手”。好的命名應(yīng)該見(jiàn)名知意getUserById比getData好一萬(wàn)倍。使用領(lǐng)域術(shù)語(yǔ)用Inventory庫(kù)存而不是StockList。避免誤導(dǎo)一個(gè)叫accountList的變量如果它實(shí)際上是Set類型就會(huì)誤導(dǎo)他人。函數(shù)名用動(dòng)詞短語(yǔ)sendEmail(),calculateTotal(),validateInput()。布爾變量/函數(shù)用 is, has, can 開(kāi)頭isValid,hasPermission,canExecute。5.2 函數(shù)設(shè)計(jì)的黃金法則短小一個(gè)函數(shù)最好控制在20行以內(nèi)一眼能看完。如果太長(zhǎng)說(shuō)明它可能做了太多事違反了單一職責(zé)。只做一件事這是單一職責(zé)原則在函數(shù)層面的體現(xiàn)。判斷標(biāo)準(zhǔn)如果你不能再為這個(gè)函數(shù)提取出另一個(gè)有意義的函數(shù)那它就只做了一件事。參數(shù)要少最理想的參數(shù)數(shù)量是0零元函數(shù)其次是1一元函數(shù)再次是2二元函數(shù)應(yīng)盡量避免3個(gè)及以上參數(shù)。參數(shù)過(guò)多會(huì)極大增加理解和測(cè)試的難度。過(guò)多參數(shù)時(shí)考慮將它們封裝成一個(gè)對(duì)象參數(shù)對(duì)象模式。無(wú)副作用函數(shù)應(yīng)該只做其名字宣稱的事情。一個(gè)叫g(shù)etUserInfo的函數(shù)就不應(yīng)該在里面偷偷修改用戶狀態(tài)或者發(fā)送郵件。副作用是滋生隱蔽bug的溫床。5.3 注釋的藝術(shù)好的代碼 好的注釋不要用注釋來(lái)為糟糕的代碼辯解而應(yīng)該重寫(xiě)代碼。注釋?xiě)?yīng)該解釋“為什么這么做”意圖、原因而不是“做了什么”代碼本身已經(jīng)說(shuō)明了。好的注釋法律信息、對(duì)復(fù)雜算法的解釋、警示如// 此處因第三方API限制必須延遲500ms。壞的注釋冗余注釋i; // i加1、廢話注釋、過(guò)時(shí)的注釋代碼改了注釋沒(méi)改比沒(méi)注釋更可怕。6. 重構(gòu)讓代碼隨時(shí)間進(jìn)化而非腐化沒(méi)有一開(kāi)始就完美的設(shè)計(jì)代碼會(huì)隨著需求增長(zhǎng)而腐化。重構(gòu)是在不改變軟件外部行為的前提下改善其內(nèi)部結(jié)構(gòu)的過(guò)程。它不是項(xiàng)目后期的一次性大掃除而應(yīng)該成為日常開(kāi)發(fā)的一部分。6.1 何時(shí)重構(gòu)聞到“壞味道”時(shí)重復(fù)代碼最經(jīng)典的味道違反DRY原則。過(guò)長(zhǎng)函數(shù)/過(guò)大類一個(gè)函數(shù)幾百行一個(gè)類幾十個(gè)方法難以理解。過(guò)長(zhǎng)的參數(shù)列表函數(shù)調(diào)用時(shí)參數(shù)一大堆。發(fā)散式變化一個(gè)類因?yàn)椴煌脑蛟诓煌姆较蛏媳恍薷?。霰彈式修改改一個(gè)小功能卻需要修改分散在多個(gè)類中的許多小地方。依戀情結(jié)一個(gè)函數(shù)過(guò)度訪問(wèn)另一個(gè)對(duì)象的數(shù)據(jù)而不是調(diào)用該對(duì)象的方法。數(shù)據(jù)泥團(tuán)總是成群結(jié)隊(duì)出現(xiàn)的相同數(shù)據(jù)項(xiàng)如幾個(gè)總是一起傳遞的參數(shù)應(yīng)該將它們封裝成一個(gè)對(duì)象?；绢愋推珗?zhí)過(guò)度使用基本類型int, string來(lái)表示概念應(yīng)該用對(duì)象來(lái)包裝如Money類代替floatEmailAddress類代替string。6.2 安全重構(gòu)的“小步快跑”策略重構(gòu)最怕引入新bug。必須保證安全。確保有可靠的測(cè)試套件這是安全重構(gòu)的前提。沒(méi)有測(cè)試重構(gòu)就像在黑暗中挪動(dòng)家具。小步前進(jìn)頻繁測(cè)試每次只做一個(gè)微小的、語(yǔ)義保持不變的改動(dòng)然后立即運(yùn)行測(cè)試。例如先重命名一個(gè)變量測(cè)試再提取一個(gè)方法測(cè)試。利用IDE的重構(gòu)工具現(xiàn)代IDE如IntelliJ IDEA, VS Code的重命名、提取方法/變量、內(nèi)聯(lián)等重構(gòu)功能非常強(qiáng)大且安全優(yōu)先使用。常用重構(gòu)手法提取函數(shù)將一段代碼放入一個(gè)獨(dú)立函數(shù)中。內(nèi)聯(lián)函數(shù)將一個(gè)函數(shù)調(diào)用點(diǎn)替換為函數(shù)本體然后移除該函數(shù)與提取相反。提取變量將一個(gè)復(fù)雜表達(dá)式的結(jié)果放入一個(gè)臨時(shí)變量。以查詢?nèi)〈R時(shí)變量將一個(gè)表達(dá)式提取到一個(gè)函數(shù)中。引入?yún)?shù)對(duì)象將過(guò)長(zhǎng)的參數(shù)列表封裝成一個(gè)對(duì)象。分解條件表達(dá)式將復(fù)雜的條件判斷邏輯提取成函數(shù)。7. 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)TDD讓設(shè)計(jì)更清晰的安全網(wǎng)TDD不是單純的測(cè)試技術(shù)而是一種設(shè)計(jì)方法。其核心循環(huán)是“紅-綠-重構(gòu)”紅先寫(xiě)一個(gè)非常小的、必定會(huì)失敗的測(cè)試描述你想要的功能。綠用最快、最簡(jiǎn)單的方式編寫(xiě)代碼讓這個(gè)測(cè)試通過(guò)不關(guān)心代碼質(zhì)量。重構(gòu)在測(cè)試通過(guò)的保護(hù)下優(yōu)化剛剛寫(xiě)的代碼消除重復(fù)改善設(shè)計(jì)。TDD帶來(lái)的好處遠(yuǎn)超測(cè)試本身更好的設(shè)計(jì)因?yàn)槟惚仨毾葟恼{(diào)用者的角度寫(xiě)測(cè)試思考接口這自然催生了更清晰、更松耦合的API。勇氣擁有完整的測(cè)試套件你就有信心進(jìn)行大規(guī)模重構(gòu)。即時(shí)反饋代碼寫(xiě)完測(cè)試即過(guò)功能即完成。活的文檔測(cè)試用例本身就是如何使用代碼的最佳文檔。實(shí)操心得剛開(kāi)始實(shí)踐TDD會(huì)覺(jué)得很慢不習(xí)慣?？梢詮囊恍┬」δ堋⒐ぞ哳愰_(kāi)始嘗試。關(guān)鍵是理解其“通過(guò)測(cè)試來(lái)驅(qū)動(dòng)設(shè)計(jì)”的內(nèi)核而不是機(jī)械地遵循步驟。當(dāng)它成為習(xí)慣后你會(huì)發(fā)現(xiàn)代碼質(zhì)量有質(zhì)的提升。8. 常見(jiàn)問(wèn)題與避坑指南8.1 過(guò)度設(shè)計(jì) vs. 設(shè)計(jì)不足這是初學(xué)者最容易陷入的困境。設(shè)計(jì)不足欠設(shè)計(jì)一開(kāi)始只圖快不考慮擴(kuò)展用最簡(jiǎn)單的過(guò)程式代碼堆砌功能。結(jié)果項(xiàng)目稍大就陷入“泥潭”添加任何新功能都舉步維艱bug頻出。癥狀上帝類一個(gè)類做所有事、霰彈式修改、高度耦合。過(guò)度設(shè)計(jì)過(guò)設(shè)計(jì)在需求還不明確、變化方向未知時(shí)就引入大量抽象層、設(shè)計(jì)模式構(gòu)建了極其“靈活”但復(fù)雜的框架。結(jié)果大部分抽象永遠(yuǎn)用不上代碼難以理解維護(hù)成本高昂。癥狀為不存在的需求創(chuàng)建接口、濫用設(shè)計(jì)模式導(dǎo)致簡(jiǎn)單問(wèn)題復(fù)雜化。平衡之道遵循YAGNI和KISS原則。為當(dāng)前的需求做設(shè)計(jì)同時(shí)為明顯、可預(yù)見(jiàn)的擴(kuò)展點(diǎn)留出余地。如何判斷“可預(yù)見(jiàn)的擴(kuò)展點(diǎn)”這依賴于你對(duì)業(yè)務(wù)領(lǐng)域的理解。例如做支付功能雖然目前只接微信支付但幾乎可以肯定未來(lái)會(huì)接支付寶那么使用策略模式來(lái)設(shè)計(jì)支付接口就是合理的預(yù)見(jiàn)而非過(guò)度設(shè)計(jì)。8.2 如何說(shuō)服團(tuán)隊(duì)或自己接受方法學(xué)“現(xiàn)在項(xiàng)目緊沒(méi)時(shí)間搞這些‘虛’的?！边@是最常見(jiàn)的阻力。用數(shù)據(jù)說(shuō)話記錄下因?yàn)榇a混亂導(dǎo)致的bug修復(fù)時(shí)間、溝通成本、新功能開(kāi)發(fā)效率。對(duì)比在應(yīng)用了良好設(shè)計(jì)比如清晰模塊劃分后類似功能的開(kāi)發(fā)效率。量化其收益。從小處著手展示效果不要試圖一次性重構(gòu)整個(gè)系統(tǒng)。挑一個(gè)最讓人頭疼、經(jīng)常出問(wèn)題的模塊用方法學(xué)進(jìn)行局部重構(gòu)。讓團(tuán)隊(duì)成員親眼看到重構(gòu)后代碼的可讀性、可測(cè)試性和穩(wěn)定性提升。將其融入開(kāi)發(fā)流程在代碼審查Code Review中將設(shè)計(jì)原則如單一職責(zé)、命名規(guī)范作為審查要點(diǎn)。在定義“完成”Definition of Done時(shí)加入“代碼經(jīng)過(guò)重構(gòu)符合基礎(chǔ)規(guī)范”這一條。以身作則自己先寫(xiě)出整潔、規(guī)范的代碼成為榜樣。別人在閱讀和使用你的代碼時(shí)感到輕松愉快自然會(huì)開(kāi)始模仿。8.3 面對(duì)遺留系統(tǒng)屎山代碼怎么辦這是最現(xiàn)實(shí)的挑戰(zhàn)。不可能推倒重來(lái)。停止讓它變得更糟在修改或添加新功能時(shí)嚴(yán)格遵守“童子軍軍規(guī)”讓營(yíng)地比你到來(lái)時(shí)更干凈。即使只是改一行代碼也順便把變量名改好一點(diǎn)把過(guò)長(zhǎng)的函數(shù)拆一小段。繪制地圖先理解系統(tǒng)。畫(huà)出關(guān)鍵的數(shù)據(jù)流和模塊依賴圖找到最核心、最混亂的部分。建立防護(hù)帶為核心模塊編寫(xiě) characterization tests表征測(cè)試。這種測(cè)試不是為了驗(yàn)證正確性而是為了捕獲當(dāng)前系統(tǒng)的行為。當(dāng)你重構(gòu)時(shí)這些測(cè)試能告訴你是否意外改變了系統(tǒng)行為。分而治之找到系統(tǒng)中的一個(gè)接縫一個(gè)相對(duì)獨(dú)立、依賴清晰的模塊將其用適配器模式包裝起來(lái)讓新代碼依賴于這個(gè)清晰的接口而不是混亂的內(nèi)部。然后逐步將這個(gè)模塊內(nèi)部重構(gòu)干凈。耐心與漸進(jìn)重構(gòu)遺留系統(tǒng)是持久戰(zhàn)需要耐心。每次修改一點(diǎn)點(diǎn)積少成多。程序設(shè)計(jì)方法學(xué)不是銀彈不能解決所有問(wèn)題但它提供了在軟件復(fù)雜性戰(zhàn)爭(zhēng)中最重要的武器清晰的思維和經(jīng)過(guò)驗(yàn)證的最佳實(shí)踐。它不會(huì)讓你一夜之間成為架構(gòu)師但能讓你寫(xiě)出的每一行代碼都更可靠、更專業(yè)讓你在應(yīng)對(duì)需求變化時(shí)更加從容。真正的掌握不在于背誦了多少原則和模式而在于在每天的編碼、評(píng)審、重構(gòu)中不斷地思考、權(quán)衡和應(yīng)用。從今天起嘗試在下一個(gè)函數(shù)、下一個(gè)類中應(yīng)用一條你學(xué)到的原則你會(huì)發(fā)現(xiàn)寫(xiě)出易于維護(hù)的代碼本身就是一種享受。