大家好，我卡颂。
最近我们技术群发生个事儿，我觉得还挺有代表性的。有时候，技术问题的最优解并不是从技术考虑。
对于工作时间不长的程序员，这篇文章可能对你有帮助。
事情起因是一位同学在群里问：“怎么获取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方法。
这么实现，当前项目确实没问题。但有个很现实的问题：随着业务不断迭代，如果哪天组件结构变了，按以往结构获取数据就会失败，难道我还得跟着业务一起改打点上报代码么？
一个打点上报功能硬生生开发成了爬虫功能。
但是，这位同学并不觉得这有问题。从他的回答看，他的思想是 —— 技术问题就应该交给技术解决。
实际上有时候，技术问题的最优解并不是从技术考虑。就像遇到产品的不合理需求，我们首先思考的，不应该是“如何实现他”，而是“从哪个角度把需求怼回去”。
就本文的例子来说，一种合理的解决方式是：
作为搞通用服务的同学，要接近业务，又不能让自己陷入业务。
回到本文的例子，如果你替业务同学实现了业务逻辑打点上报还不知会他们。未来业务需求变化导致代码变化后，打点上报有误，这是谁的锅呢？
业务同学会说：我根本不知道打点这回事儿啊。
到时候你就欲哭无泪了。
所以，明确自己的工作职责，做好向上管理，不是所有技术问题都得靠技术解决。
本文链接：http://www.28at.com/showinfo-26-60998-0.html有时候，技术问题的最优解并不是从技术考虑
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 我愿称之为开源界最好用的行为验证码
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号