大家好，我卡頌。

最近我們技術(shù)群發(fā)生個事兒，我覺得還挺有代表性的。有時候，技術(shù)問題的最優(yōu)解并不是從技術(shù)考慮。

對于工作時間不長的程序員，這篇文章可能對你有幫助。

事情起因

事情起因是一位同學在群里問：“怎么獲取react element對應(yīng)dom中的文本？”

為什么想獲取文本內(nèi)容呢，原來他是想做「交互的打點上報功能」。

他希望這個打點上報功能是完全自動化、業(yè)務(wù)無感知的。但這里存在一個悖論：如果打點上報是“業(yè)務(wù)無感知的”，那打點功能肯定要和業(yè)務(wù)解耦。既然和業(yè)務(wù)解耦，就無法記錄“業(yè)務(wù)的完整操作鏈路”。

那么類似“用戶點擊了一個按鈕，我想知道這個按鈕是否在對話框中，如果在，取出對話框的標題上報”就無法實現(xiàn)。

想一想，如果是你，會怎么實現(xiàn)這個功能呢？

功能實現(xiàn)

這位同學的做法是 —— 梳理現(xiàn)有業(yè)務(wù)邏輯中的組件層級，從特定的層級里拿數(shù)據(jù)。

比如Modal組件的標題渲染成HTML是：

<div>
  <h1>這里是標題</h1>
</div>

那么他會按div -> h1這樣的層級結(jié)構(gòu)取標題數(shù)據(jù)。具體實現(xiàn)還涉及很多hack的方法。

比如，組件沒有掛載時如何獲取數(shù)據(jù)？他通過把組件掛載在一個離屏DOM上，再分析他：

function analyzeCpn(node: ReactNode) {
  const div = document.createElement('div');
  const root = reactDOM.createRoot(div);
  flushSync(() => root.render(node));
  // ...分析 div.innerHTML
}

再比如，如何根據(jù)DOM不同，增加一些特殊的屬性呢？可以覆寫jsx、React.createElement方法。

問題

這么實現(xiàn)，當前項目確實沒問題。但有個很現(xiàn)實的問題：隨著業(yè)務(wù)不斷迭代，如果哪天組件結(jié)構(gòu)變了，按以往結(jié)構(gòu)獲取數(shù)據(jù)就會失敗，難道我還得跟著業(yè)務(wù)一起改打點上報代碼么？

一個打點上報功能硬生生開發(fā)成了爬蟲功能。

但是，這位同學并不覺得這有問題。從他的回答看，他的思想是 —— 技術(shù)問題就應(yīng)該交給技術(shù)解決。

實際上有時候，技術(shù)問題的最優(yōu)解并不是從技術(shù)考慮。就像遇到產(chǎn)品的不合理需求，我們首先思考的，不應(yīng)該是“如何實現(xiàn)他”，而是“從哪個角度把需求懟回去”。

就本文的例子來說，一種合理的解決方式是：

• 調(diào)研一下主流打點上報庫的實現(xiàn)邏輯。
• 調(diào)研完畢后和領(lǐng)導(dǎo)溝通。
• 溝通好后讓領(lǐng)導(dǎo)拉個會，會上把你的方案跟大家同步一下，讓大家知道上報方案如何實現(xiàn)。
• 各個業(yè)務(wù)同學認領(lǐng)自己那部分的打點上報需求，遇到技術(shù)問題和你溝通，你輔助解決。

總結(jié)

作為搞通用服務(wù)的同學，要接近業(yè)務(wù)，又不能讓自己陷入業(yè)務(wù)。

回到本文的例子，如果你替業(yè)務(wù)同學實現(xiàn)了業(yè)務(wù)邏輯打點上報還不知會他們。未來業(yè)務(wù)需求變化導(dǎo)致代碼變化后，打點上報有誤，這是誰的鍋呢？

業(yè)務(wù)同學會說：我根本不知道打點這回事兒啊。

到時候你就欲哭無淚了。

所以，明確自己的工作職責，做好向上管理，不是所有技術(shù)問題都得靠技術(shù)解決。