大家好，我卡頌。

最近我們技術群發生個事兒，我覺得還挺有代表性的。有時候，技術問題的最優解并不是從技術考慮。

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

事情起因

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

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

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

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

想一想，如果是你，會怎么實現這個功能呢？

功能實現

這位同學的做法是 —— 梳理現有業務邏輯中的組件層級，從特定的層級里拿數據。

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

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

那么他會按div -> h1這樣的層級結構取標題數據。具體實現還涉及很多hack的方法。

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

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

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

問題

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

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

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

實際上有時候，技術問題的最優解并不是從技術考慮。就像遇到產品的不合理需求，我們首先思考的，不應該是“如何實現他”，而是“從哪個角度把需求懟回去”。

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

• 調研一下主流打點上報庫的實現邏輯。
• 調研完畢后和領導溝通。
• 溝通好后讓領導拉個會，會上把你的方案跟大家同步一下，讓大家知道上報方案如何實現。
• 各個業務同學認領自己那部分的打點上報需求，遇到技術問題和你溝通，你輔助解決。

總結

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

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

業務同學會說：我根本不知道打點這回事兒啊。

到時候你就欲哭無淚了。

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