大家好，我卡颂。
最近我们技术群发生个事儿，我觉得还挺有代表性的。有时候，技术问题的最优解并不是从技术考虑。
对于工作时间不长的程序员，这篇文章可能对你有帮助。
事情起因
事情起因是一位同学在群里问：“怎么获取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方法。
问题
这么实现，当前项目确实没问题。但有个很现实的问题：随着业务不断迭代，如果哪天组件结构变了，按以往结构获取数据就会失败，难道我还得跟着业务一起改打点上报代码么？
一个打点上报功能硬生生开发成了爬虫功能。
但是，这位同学并不觉得这有问题。从他的回答看，他的思想是 —— 技术问题就应该交给技术解决。
实际上有时候，技术问题的最优解并不是从技术考虑。就像遇到产品的不合理需求，我们首先思考的，不应该是“如何实现他”，而是“从哪个角度把需求怼回去”。
就本文的例子来说，一种合理的解决方式是：
- 调研一下主流打点上报库的实现逻辑。
- 调研完毕后和领导沟通。
- 沟通好后让领导拉个会，会上把你的方案跟大家同步一下，让大家知道上报方案如何实现。
- 各个业务同学认领自己那部分的打点上报需求，遇到技术问题和你沟通，你辅助解决。
总结
作为搞通用服务的同学，要接近业务，又不能让自己陷入业务。
回到本文的例子，如果你替业务同学实现了业务逻辑打点上报还不知会他们。未来业务需求变化导致代码变化后，打点上报有误，这是谁的锅呢？
业务同学会说：我根本不知道打点这回事儿啊。
到时候你就欲哭无泪了。
所以，明确自己的工作职责，做好向上管理，不是所有技术问题都得靠技术解决。
