6月iOS設備好評榜：第一蟬聯榜首近一年
作為安兔兔各種榜單里變化最小的那個，2023年6月的iOS好評榜和上個月相比沒有任何排名上的變化，僅僅是部分設備好評率的下降，長年累月的用戶評價和逐漸退出市場的老款機器讓這
大家好，我卡頌。
最近我們技術群發生個事兒，我覺得還挺有代表性的。有時候，技術問題的最優解并不是從技術考慮。
對于工作時間不長的程序員，這篇文章可能對你有幫助。
事情起因是一位同學在群里問：“怎么獲取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://m.www897cc.com/showinfo-26-60998-0.html有時候，技術問題的最優解并不是從技術考慮
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 我愿稱之為開源界最好用的行為驗證碼
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號