1. 老代碼引發(fā)的思考為什么我們需要重新審視開發(fā)思路那天整理舊項(xiàng)目時(shí)我翻出了五年前寫的一段業(yè)務(wù)邏輯代碼。當(dāng)時(shí)為了趕進(jìn)度我直接按照產(chǎn)品文檔的要求把每個(gè)功能點(diǎn)都實(shí)現(xiàn)了出來。現(xiàn)在回頭看那些代碼就像是用膠帶粘起來的積木——雖然能用但牽一發(fā)而動(dòng)全身。最典型的是一個(gè)訂單狀態(tài)流轉(zhuǎn)的功能我寫了將近800行的if-else嵌套現(xiàn)在要加個(gè)新狀態(tài)得把整個(gè)文件重寫一遍。這讓我意識(shí)到很多開發(fā)者包括當(dāng)年的我常犯的一個(gè)錯(cuò)誤拿到需求就急著寫具體實(shí)現(xiàn)。我們太關(guān)注怎么做而忽略了更重要的為什么要這樣做。就像建房子先打地基一樣寫代碼前應(yīng)該先理清業(yè)務(wù)邏輯的本質(zhì)。提示下次接到新需求時(shí)試著先問三個(gè)問題這個(gè)功能的核心目標(biāo)是什么它與現(xiàn)有系統(tǒng)的關(guān)系如何未來可能有哪些變化2. 抽象思維的四個(gè)層次從業(yè)務(wù)到代碼的完整路徑2.1 第一層業(yè)務(wù)概念抽象最近接手的一個(gè)電商優(yōu)惠券系統(tǒng)就是個(gè)好例子。產(chǎn)品經(jīng)理最初的需求文檔里提到了滿減券、折扣券、贈(zèng)品券等十幾種類型。如果直接照搬這些具體類型去建模代碼很快就會(huì)變得難以維護(hù)。我的做法是找出所有券類型的共性都有有效期、使用條件、優(yōu)惠效果識(shí)別變化點(diǎn)條件判斷邏輯如滿X元和優(yōu)惠計(jì)算方式如減Y元建立核心抽象Coupon券基類、Condition條件接口、DiscountStrategy優(yōu)惠策略接口interface ICondition { isSatisfied(order: Order): boolean; } interface IDiscountStrategy { applyDiscount(order: Order): void; } abstract class Coupon { constructor( public conditions: ICondition[], public strategy: IDiscountStrategy ) {} validate(order: Order) { return this.conditions.every(cond cond.isSatisfied(order)); } apply(order: Order) { if (this.validate(order)) { this.strategy.applyDiscount(order); } } }2.2 第二層流程控制抽象在開發(fā)一個(gè)文件導(dǎo)入功能時(shí)我發(fā)現(xiàn)雖然文件格式CSV/Excel/JSON不同但處理流程高度一致驗(yàn)證→解析→轉(zhuǎn)換→存儲(chǔ)。于是設(shè)計(jì)了這樣的流程控制器abstract class FileProcessor { async process(file: File) { await this.validate(file); const data await this.parse(file); const entities this.transform(data); return this.save(entities); } abstract validate(file: File): Promisevoid; abstract parse(file: File): PromiseRawData; abstract transform(data: RawData): Entity[]; abstract save(entities: Entity[]): Promisevoid; }這樣新增格式時(shí)只需繼承這個(gè)基類實(shí)現(xiàn)四個(gè)方法無需改動(dòng)現(xiàn)有流程代碼。2.3 第三層設(shè)計(jì)模式的應(yīng)用在消息通知系統(tǒng)中我最初為每種通知類型郵件、短信、站內(nèi)信寫了獨(dú)立的方法。當(dāng)需要支持新渠道如企業(yè)微信時(shí)發(fā)現(xiàn)要修改多處發(fā)送邏輯。用策略模式重構(gòu)后interface NotificationStrategy { send(user: User, message: string): Promisevoid; } class NotificationService { private strategies new Mapstring, NotificationStrategy(); register(type: string, strategy: NotificationStrategy) { this.strategies.set(type, strategy); } async notify(user: User, type: string, message: string) { const strategy this.strategies.get(type); if (!strategy) throw new Error(Unsupported type: ${type}); return strategy.send(user, message); } } // 使用 service.register(email, new EmailStrategy()); service.register(sms, new SMSStrategy()); // 新增渠道只需添加實(shí)現(xiàn)類并注冊(cè)2.4 第四層領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐在供應(yīng)鏈系統(tǒng)中我嘗試用DDD劃分邊界。比如將庫存這個(gè)概念從簡(jiǎn)單的數(shù)據(jù)庫表升級(jí)為獨(dú)立的領(lǐng)域模型class Inventory { private items: Mapstring, InventoryItem new Map(); constructor(private repository: InventoryRepository) {} async load(sku: string) { this.items.set(sku, await this.repository.findBySku(sku)); } allocate(order: Order): AllocationResult { // 復(fù)雜的庫存分配邏輯 // 包含業(yè)務(wù)規(guī)則先進(jìn)先出、批次追蹤等 } getStockLevel(sku: string): number { return this.items.get(sku)?.quantity || 0; } }這樣將業(yè)務(wù)規(guī)則封裝在領(lǐng)域?qū)ο髢?nèi)避免業(yè)務(wù)邏輯泄漏到應(yīng)用層。3. 從抽象到實(shí)現(xiàn)的五個(gè)實(shí)操技巧3.1 白板設(shè)計(jì)法我團(tuán)隊(duì)現(xiàn)在有個(gè)規(guī)矩任何新功能開發(fā)前必須先在白板上畫清楚核心實(shí)體及其關(guān)系關(guān)鍵業(yè)務(wù)流程可能的變化點(diǎn)最近設(shè)計(jì)支付系統(tǒng)時(shí)我們花了整整兩天在白板前討論最終確定了這樣的架構(gòu)[支付網(wǎng)關(guān)] ←→ [支付處理器] ←→ [交易核心] ↑ ↑ [風(fēng)控系統(tǒng)] [會(huì)計(jì)系統(tǒng)]這個(gè)過程中發(fā)現(xiàn)了三個(gè)重要問題退款流程需要特殊風(fēng)控規(guī)則跨境支付涉及多幣種會(huì)計(jì)處理需要支持異步通知重試機(jī)制提前發(fā)現(xiàn)這些問題節(jié)省了至少兩周的返工時(shí)間。3.2 契約先行開發(fā)在微服務(wù)項(xiàng)目中我習(xí)慣先用OpenAPI定義接口契約paths: /orders: post: requestBody: content: application/json: schema: $ref: #/components/schemas/OrderRequest responses: 201: description: Created content: application/json: schema: $ref: #/components/schemas/OrderResponse components: schemas: OrderRequest: type: object properties: items: type: array items: $ref: #/components/schemas/OrderItem # 其他定義...這樣做的好處前端可以并行開發(fā)mock數(shù)據(jù)明確接口邊界避免后期扯皮自動(dòng)生成類型定義和文檔3.3 測(cè)試驅(qū)動(dòng)抽象寫測(cè)試能倒逼出好的抽象。比如最近開發(fā)配置管理系統(tǒng)時(shí)我這樣開始describe(FeatureToggle, () { it(should return false for undefined feature, () { const toggle new FeatureToggle({}); expect(toggle.isEnabled(new-ui)).toBe(false); }); it(should respect environment-specific override, () { const toggle new FeatureToggle({ new-ui: { default: false, staging: true } }); expect(toggle.isEnabled(new-ui, staging)).toBe(true); }); });這個(gè)測(cè)試促使我設(shè)計(jì)出這樣的實(shí)現(xiàn)class FeatureToggle { constructor(private config: FeatureConfig) {} isEnabled(feature: string, env: string default): boolean { const featureConfig this.config[feature]; if (!featureConfig) return false; return featureConfig[env] ?? featureConfig.default ?? false; } }3.4 可視化建模工具復(fù)雜業(yè)務(wù)系統(tǒng)建議使用PlantUML等工具建模。這是我們最近物流系統(tǒng)的狀態(tài)圖示例startuml state 待攬收 as pending state 運(yùn)輸中 as shipping state 已簽收 as delivered state 異常 as exception [*] -- pending pending -- shipping: 攬收成功 shipping -- delivered: 客戶簽收 shipping -- exception: 運(yùn)輸異常 exception -- shipping: 問題解決 enduml這種可視化表達(dá)幫助團(tuán)隊(duì)達(dá)成共識(shí)也更容易發(fā)現(xiàn)狀態(tài)機(jī)設(shè)計(jì)缺陷。3.5 重構(gòu)雷達(dá)機(jī)制我們建立了代碼壞味道雷達(dá)圖定期評(píng)估重復(fù)代碼率方法復(fù)雜度類職責(zé)數(shù)量依賴關(guān)系深度當(dāng)某個(gè)指標(biāo)超標(biāo)時(shí)立即安排重構(gòu)。比如最近發(fā)現(xiàn)訂單處理器類的process方法超過了100行立即拆分為OrderValidatorOrderCalculatorOrderNotifier每個(gè)類專注單一職責(zé)代碼可讀性大幅提升。4. 常見陷阱與解決方案4.1 過度抽象問題去年我設(shè)計(jì)過一個(gè)萬能表單渲染器試圖用一套配置支持所有業(yè)務(wù)表單。結(jié)果配置復(fù)雜度反而超過了直接寫組件{ fields: [ { type: nested, conditions: [ {field: userType, operator: equals, value: vip} ], fields: [ {name: vipCode, component: Input, rules: [required]} ] } ] }教訓(xùn)是抽象應(yīng)該遵循三次法則——當(dāng)?shù)谌斡龅较嗨菩枨髸r(shí)再抽象。4.2 領(lǐng)域模型貧血癥早期我常寫出這樣的貧血模型class Order { public items: OrderItem[]; public status: string; // 只有g(shù)etter/setter } class OrderService { calculateTotal(order: Order) { // 計(jì)算邏輯放在service里 } }改進(jìn)后的充血模型class Order { private items: OrderItem[]; private status: OrderStatus; get total(): number { return this.items.reduce((sum, item) sum item.price * item.quantity, 0); } markAsPaid() { if (this.status ! pending) { throw new Error(Invalid status transition); } this.status paid; } }4.3 抽象泄漏問題有次設(shè)計(jì)緩存層時(shí)底層Redis的異常直接拋給了業(yè)務(wù)代碼class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { // Redis連接錯(cuò)誤直接暴露 throw err; } } }正確的做法是封裝領(lǐng)域異常class ProductService { async getProduct(id: string) { try { return await cache.get(product:${id}); } catch (err) { throw new ProductRepositoryError(Failed to access product, err); } } }4.4 過早優(yōu)化陷阱我曾為了性能設(shè)計(jì)過極度抽象的查詢構(gòu)建器const query new QueryBuilder() .select(id, name) .from(Product) .where( new ConditionGroup(AND, [ new Condition(price, , 100), new Condition(stock, , 0) ]) ) .build();后來發(fā)現(xiàn)95%的查詢都很簡(jiǎn)單復(fù)雜查詢直接寫SQL更清晰性能瓶頸其實(shí)在索引設(shè)計(jì)現(xiàn)在遵循YAGNI原則除非確有需要否則保持簡(jiǎn)單。5. 個(gè)人工具箱分享5.1 抽象思維訓(xùn)練法我每周會(huì)做這樣的練習(xí)選一個(gè)日常事物如咖啡機(jī)列出其主要功能識(shí)別變化點(diǎn)咖啡種類、杯型等設(shè)計(jì)抽象接口想象未來可能的擴(kuò)展例如電梯系統(tǒng)的抽象練習(xí)interface ElevatorController { requestFloor(floor: number): void; getCurrentFloor(): number; getDirection(): up | down | idle; } interface SchedulingStrategy { nextFloor(requests: number[], current: number): number; }5.2 代碼評(píng)審檢查清單在我的團(tuán)隊(duì)PR模板中包含這些抽象相關(guān)檢查項(xiàng)[ ] 是否存在重復(fù)邏輯[ ] 新增代碼是否適合現(xiàn)有抽象[ ] 是否需要?jiǎng)?chuàng)建新的抽象[ ] 領(lǐng)域知識(shí)是否泄漏到應(yīng)用層[ ] 接口設(shè)計(jì)是否遵循ISP原則5.3 架構(gòu)決策記錄(ADR)我們用markdown記錄重要抽象決策# 2023-05-01 支付網(wǎng)關(guān)抽象方案 ## 狀態(tài) 已采納 ## 背景 現(xiàn)有支付對(duì)接方式支付寶、微信支付直接耦合在訂單服務(wù)中 ## 決策 引入支付網(wǎng)關(guān)抽象層┌─────────────┐ ┌──────────────┐ │ 訂單服務(wù) │───────?│ 支付網(wǎng)關(guān) │ └─────────────┘ └──────────────┘ ▲ ┌───────────────┴───────────────┐ │ │ ┌──────────────┐ ┌──────────────┐ │ 支付寶適配器 │ │ 微信支付適配器│ └──────────────┘ └──────────────┘## 影響 - 正面新增支付渠道只需實(shí)現(xiàn)適配器 - 負(fù)面增加一次調(diào)用跳轉(zhuǎn)5.4 可視化抽象工具鏈我的常用工具組合Miro用于業(yè)務(wù)流程抽象Draw.io繪制架構(gòu)圖TypeScript Playground快速驗(yàn)證接口設(shè)計(jì)Jest通過測(cè)試驅(qū)動(dòng)抽象Postman模擬接口契約5.5 持續(xù)學(xué)習(xí)資源推薦這些資源重塑了我的抽象思維《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》Eric Evans《設(shè)計(jì)模式》GoF《重構(gòu)》Martin Fowler《整潔架構(gòu)》Robert C. Martin《程序員修煉之道》最后分享一個(gè)真實(shí)案例去年重構(gòu)的報(bào)表生成系統(tǒng)通過抽象出數(shù)據(jù)源→轉(zhuǎn)換→渲染的管道模式將新增報(bào)表類型的開發(fā)時(shí)間從3天縮短到2小時(shí)。這讓我深刻體會(huì)到好的抽象不是增加復(fù)雜度而是把復(fù)雜性裝進(jìn)合適的盒子里讓使用者只需關(guān)心自己那部分。