一、"技術鄙視鏈？"

如果你是一個技術人，相信都知道技術圈有個相互的鄙視鏈，這個鏈條從技術人自己認知的角度在以業務價值為中心嵌套的一層一層的環，就像洋蔥，具體的描述這里不贅述了，

出門左拐隨便抓住一個人問一下，這種偏自嘲類的觀點，有點類似"程式員的穿著必須是格子衫"、"你們只會和電腦打交道"這種自嘲，開心一下，無可厚非，但是在玩笑之外，一個合格的技術人的內心要時刻謹記自己在一個企業內的價值所在，并不斷的通過技術提升來擴大價值，才可以在當下的環境中，個人價值與企業價值形成正向回圈，那我們此次就聊一聊，前端職能如何在不同的業務場景中落地價值，

二、"技術人，你有價值嗎？"

說到業務價值，有一個關鍵詞，就是"特定的業務背景"，有人會說，技術就是技術，是通用的，為什么要把業務的概念引入到技術價值中呢？我對這個問題的回答也相當簡單：技術本身沒有業務屬性，但是技術人所處的業務環境，從而決定了技術人此時此刻應該為環境提供什么型別的價值輸出，

對于前端領域的崗位職責，如前文（《“前端”工匠系列：合格的工匠，究竟該搞什么（一）》），“它的崗位角色更應該關注’采集和呈現‘兩個部分”，這種職能定位就決定了它在具體業務場景中的價值定位，

首先，從粗粒度進行大維度的劃分，B端和C端來先劃分一刀，國內外從崗位招聘、崗位定位到OKR制定、績效評估，都要先從端型別來做最起碼的區分，原因是B端和C端對于前端技術堆疊、技術深度及輸出價值的要求都是不一樣的，甚至B端的研發人員對于原生、多端等研發領域并不熟悉，如果有崗位的調整，會有一段比較長的技術切換期的，根據人員軟素質的不同，這段時間從1個月到一個季度不等，

B端研發是什么？

B端通常指“Business端研發”，但當前很多企業對B端研發的崗位職能描述也包括了A端（即業務管理員Administrator）的研發，這樣囊括也是有道理的，A端和B端的共同特點是大部分業務都是“以PC瀏覽器為運行時環境，基于Web技術堆疊的企業級后臺管理系統”來運作、賦能具體場景，

至于B端研發人員的技術價值，根據業務領域不同，可以切為企業級應用（如飛書、騰訊檔案）、商業化解決方案（toB、toG的業務，比如一些企安類業務和商業化業務）、業務后臺管理（輔助C端業務邏輯的管理后臺）等細分方向，前者用于商業化變現，所以這些后臺專案對用戶體驗有一定程度的要求，其他的B端業務對體驗和性能的要求都是相對較低的，

C端研發是什么？

C端也稱為“客戶端（Client）研發”，從技術崗位要求維度可以細分為端側研發（IOS、安卓、鴻蒙）、H5研發、小程式研發等，

很明顯，維度劃分的依據是代碼運行容器，那么存不存在“一次開發，多處運行”的研發方案呢？這就產生了多端研發這個崗位角色，對應的技術堆疊是React Native、Flutter、Taro等為代表的解決方案，由于各自對多端的實作方案不同，導致了各自有各自的優劣勢，具體的選型，要研發團隊根據業務背景以業務屬性（是否對特殊端側有傾向）、團隊成本、維護成本、研發效率、社區活躍度、未來技術堆疊的持久性等維度來做最合適的技術選型，

因為C端的輸出直接面對用戶，而且用戶量級大，因此C端頁面對于設計、互動、業務可用性、用戶體驗是否良好等專項指標都有很高的要求，因此，在技術型企業，一些企業對于其中的每個專項都會有一批人在做專門的優化提升處理，

以下分研發階段對C端研發的關注點進行簡述，

• 設計階段：研發人員需要對設計稿件、UI切圖的合理性更加關注；
• 研發階段：研發人員需要有更頻繁、更合理、更清晰的代碼注釋；
• 提測階段：提測前，研發人員需要保證用例冒煙質量，提測后，研發人員更加關注千行代碼bug率這種質量指標；
• 上線階段：研發人員需要保證上線流程的切實無人化、自動化和日志詳細程度，因此，CI/CD的上線流程中每個階段的處理腳本都必須完全嚴謹和可用；
• 上線后：研發人員需要通過監控、告警和日志平臺，對線上代碼在用戶設備端的運行狀況進行監控，如果出現例外運行，研發人員需要及時被告警平臺告知、根據SOP對線上故障進行合理處理及時止損，修復后bugfix上線；

以上只是簡單論述了B端業務和技術對研發人員基本素質要求的差異，基于以上的業務背景，以下分別從技術角度、人力資源角度及團隊能力設計的角度進行闡述怎么做好相應的作業，

三、"B端，怎么做好？"

如果你在做業務交付類的B端研發作業，做好業務支持后，想辦法通過"低代碼"或者"零代碼"的方式進行更加高效、高質量的交付，

具體的實作方案有很多，比如AntDesign、FusionDesign以及很多商業化的Design們，實作思路就是基于業務場景，建立一套通用的、可復用的物料組件，在業務交付的時候，只需要對物料進行拼裝組建即可，有些想樂高積木，但是這種Design們對于應用場景的要求是比較高的，如果你想用這種方案（尤其是業務場景比較復雜，只能用低代碼方案），就要進一步思考物料間的資料通信、UI通信等問題，甚至需要隨著業務物料的發展去迭代DSL決議引擎，

對于前端人員來說，啟用初期的搭建的效率反倒是降低的，但如果用起來，用的越久，沉淀的物料就會越豐富、與場景的匹配度越高，交付效率也越高，但從成本的角度，一部分研發成本也會轉嫁到后端服務的封裝度提升、合理性提升，整個的業務交付就會向搭建驅動的角度傾斜，綜合成本的降低需要結合整體研發交付的維度來考量，但如何考量、考量口徑是否合理、是否可落地，每個研發團隊就要"八仙過海，各顯神通"了，

但是B端業務交付的低代碼方案的選型，從人力的角度，只要做好資料和代碼安全處理，采用“搭建+外包”的方式是完全可以應對的，

如果你在做商業化的B端產品的研發，那就要更加偏向產品訴求，不斷的與產品、客戶進行溝通調研，甚至要去現場溝通去發現用戶使用產品程序中遇到的真物體驗和功能問題，從而不斷做好產品迭代和優化，"低代碼"和"零代碼"的提效方案只能作為產品范訓的工具，但具體能不能用起來，就要自己評估了，

四、"C端，怎么做好？"

如果你在做C端產品的交付，那你應該關注研發流程的順暢度和合理性，研發環境、測驗環境、預備發布環境以及線上環境的代碼隔離、資料隔離、發布隔離是否良好，堅決避免環境污染導致業務例外或者作業量激增；

你應該關注UI設計稿件的還原度、動效效果是否順滑、頁面加載效率是否良好、Crash率是否達標、埋點是否正常上報，

這里值得提一下的是埋點這個事兒，對于C端業務，需要有專門的作業來處理埋點作業，埋點作業的質量直接影響到功能需求上線后業務是否可以拿到正確的用戶資料，進而做出業務的運營策略調整，所以，埋點質量這個作業的成本投入是必須的，也是應該受到研發團隊重視的，否則，就會出現，明明功能沒問題，也沒有客訴，但是，業務因為拿到了錯誤的用戶行為資料而不自知，卻先入為主的認為自己的策略太"哇塞"或者太"喔去"的結果，如果根據錯誤的埋點做出了錯誤的決策但是不自知，對于業務價值的影響是巨大的，更加嚴重的事，很久以后你發現錯了，最佳業務的時機，早就白駒過隙，飛逝而去了，

如果你在做C端基建作業，恭喜你，你可能已經離很多研發人員羨慕的架構師的崗位很近了，

你需要關注技術堆疊的選型、物料及組件建設、活動搭建平臺、設計智能交付、多端編譯、渲染引擎等離業務更遠但離技術更近的話題，每一項都充滿了挑戰，每一項達成都能給你更多的成就感，但是，因為離業務更遠，就要避免"自嗨"的情形出現，你要少一些年度規劃，多一些技術用戶的痛點調研行程的季度規劃和OKR，只有讓自己的技術范訓落地到具體的業務場景中，你的技術價值才能得以體現，

五、"價值，價值，還是價值"

請各位技術人時刻謹記，如果你的代碼不上線、如果你的代碼沒有經受住用戶的使用考研、如果你沒有關注代碼上線后的質量和功能的相關告警、如果你不關注業務和用戶行為資料，那你的作業價值就會大打折扣，甚至，沒有價值，因為，你和一樣作業方式的那個誰，對于業務的正常運轉來說，沒有區別，

來源：京東云開發者社區

作者：京東零售 劉偉東（未經授權請勿轉載）

標籤：其他

上一篇：Express實戰個人訂閱號實作網站登錄

下一篇：返回列表