一、"技術鄙視鏈？"

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

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

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

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

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

首先，從粗粒度進行大維度的劃分，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，只有讓自己的技術孵化落地到具體的業務場景中，你的技術價值才能得以體現。

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

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

來源：京東雲開發者社群

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