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