個人經歷
大家好,我叫付小波,2017年加入京東,現擔任全渠道生態部前端架構師。我負責過ToC和ToB多個業務,近幾年主要專注于B端應用開發。以下是我的主要經歷:
- 2017年:負責主站虛擬交易業務研發,搭建首個虛擬交易類小程序;
- 2019年:從C端轉向B端系統,負責萬家系統;
- 2021年:作為前端主負責人,主導線下系統重構;
- 2022年:作為前端研發一號位,從0到1搭建B商城三個端;
- 2023年至今:擔任WEB前端主責人,主導京麥商家系統重構。
從C端到B端的技術轉型
2017年,我作為一名新入職的WEB前端工程師,開始接觸移動端項目。在此之前,我對移動端開發框架在項目實戰中的經驗相對較少。當時,移動端領域正處于快速發展階段,尤其是微信小程序的火爆,前端技術棧也在迅速演變,如小程序和React Native等新技術對我來說都是挑戰,同時還需要適配不同的移動設備和進行性能優化。
我負責的第一個項目是開發一個虛擬交易類的小程序。為此,我通過查找官網資料、觀看視頻教程、閱讀開源代碼以及與團隊內部交流等方式進行學習。在公司內部沒有現成流程和案例可供參考的情況下,我獨自摸索了小程序的申請注冊、開發部署以及交易鏈路聯調等全流程,最終按期順利完成了開發和上線。
在C端產品開發過程中,我深刻體會到用戶體驗至關重要。通過保持UI組件的一致性、提升用戶操作的連貫性、適當使用動畫效果、優化性能以減少用戶等待時間,以及兼顧多端設備的適配等多種手段,不僅顯著提升了用戶體驗,也積累了寶貴的經驗。
2019年,公司進行組織變革時,我有幸接觸到B端業務系統。京東零售有自營、POP、線下等多種業務模式,涉及POP商家、門店、供應商、運營、采銷等多個角色,同時包含商品管理、訂單管理、庫存管理、客戶關系管理(CRM)、財務管理、促銷等復雜功能模塊,一些B端系統菜單數據量多達500+。部分模塊之間存在相互依賴,增加了系統的復雜性。這給我帶來了巨大的挑戰。憑借近兩年的移動端開發經驗和之前的WEB開發經驗,我迎接新的挑戰,轉向B端業務系統研發。
通過實際項目案例和行業調研,從多個維度對比了C端和B端的區別,幫助我在不同項目中做出更優的技術選擇和方案設計,如下表:
C端產品與B端產品差異對照表 | |||
維度 | C端 | B端 | 一句話總結 |
用戶群體 | 主要是普通消費者,這些用戶的技術背景相對較弱,更關注產品的易用性和體驗。 | 主要是企業用戶、商家、門店、采銷/運營人員等,他們對系統功能和穩定性有更高的要求,通常具備一定的專業背景。 | 了解你的用戶,才能做出合適的產品。 |
產品特點 | C端易用、體驗優先、跨端適配 | 功能性: 強調功能的完備性和復雜性,支持多種業務流程。穩定性: 系統需要高穩定性和高可用性,能處理大量數據。效率優先: 界面設計注重信息展示和操作效率,用戶操作路徑短。 | C端重體驗,B端重功能。 |
設計與交互 | 視覺設計: 更加注重視覺效果,色彩豐富,動畫效果明顯。交互設計: 強調用戶體驗,操作簡單,交互流暢。 | 信息密度: 界面信息密度大,需要展示大量數據和操作選項。交互設計: 強調操作效率和準確性,界面布局緊湊,功能入口清晰。 | C端設計吸引眼球,B端設計提升效率。 |
技術棧 | C端跨端技術、適配不同移動設備 | B端微應用化,表單、表格、圖表等復雜組件 | 工具不同,目標一致:解決用戶痛點,提升研發效率。 |
我采取了統一的開發框架、穩定的底座、標準統一的交互規范等一些列措施,逐步攻克了B端研發的一些難題。在技術選型過程中,綜合考慮了系統的穩定性、性能、可維護性和擴展性,選擇Vue和TypeScript,配合微前端框架,將復雜系統拆分為多個獨立的小模塊,提升了系統的可擴展性和可維護性。
前端工程師如何應對業務變化
無論是C端還是B端研發,都會面臨業務隨時可能發生變化的情況。特別是B端,我們團隊負責的商家系統需要支持POP、VC等幾十種業務模式。B商城和線下系統也涉及多種模式和身份。舉個具體例子,商家系統的入駐功能有幾十種模式,每種模式包含7種類型,涉及多達上百個組件。再比如發品頁有9大場景,組件數量多達上百個,配置模板數量超過大幾百個。業務規則的變化對我們的技術方案設計和抽象能力帶來了巨大的挑戰。
為了應對業務變化,我會花時間了解業務需求,包括產品定位、目標用戶和市場趨勢等。通過參加業務部門會議、閱讀相關文檔以及與產品經理溝通來實現。這有助于更好地理解業務流程,并為技術決策提供更全面的視角。在實際的方案設計中,我會思考將功能進行合理抽象:哪些功能應該抽象為原子能力,哪些應抽象為水平業務組件或垂直業務組件,哪些應模板化,從而將通用的業務流程標準化、產品化。我總結了前端分層復用模型(如下圖1所示):以面向UI、配置化方式,提升研發效率和質量。
圖1:前端分層復用模型
另外產品功能上線后,通過持續監控和收集用戶之聲,及時發現問題和主動了解用戶的真實反饋,從用戶的角度出發,與業務和產品一起,思考如何優化產品的易用性和功能性,通過持續優化和迭代完善產品功能和體驗,直到達成業務目標。
前端進階之路心得分享
在B端業務這種復雜的研發里,我慢慢改變了自己的想法。一開始,我就想著怎么快點把功能做出來,但后來我明白,光快不行,還得讓代碼寫得規范、好讀、好維護。所以,現在會在團隊內要求按照最佳實踐和編碼規范來寫代碼。
以前,我做一個功能就完事了,但現在會想著怎么讓設計更模塊化,這樣不僅能讓代碼更好復用,以后維護起來也更容易。除了實現功能,我還會想怎么讓整體性能更好,比如頁面加載得更快,響應時間更短,還有怎么優化資源的加載和渲染,這樣不管網絡和設備怎么樣,用戶都能有個好的體驗。而且,現在不只是想著怎么實現功能,還會參與到產品交互設計的討論中,希望能讓用戶愛上使用產品的感覺。
我的關注點也從單一的頁面擴展到了整個系統的架構,想著怎么搭建一個既好擴展又好維護的前端架構。為了系統更穩定,現在更注重預防問題,而不是等問題出現后再去解決。我會通過代碼審查和測試、主動打點上報等手段,提前找出并解決問題。還有,我現在不只是改進一個小點,而是想著怎么讓整個系統都更優化,性能更可靠。也不再只是找短期的解決辦法,而是會做長期的技術規劃,確保項目能持續發展。當然,團隊協作也很重要。我現在會更多地和產品、設計、后端等團隊溝通交流,確保項目能順利進行,同時也會分享自己的知識和經驗,和大家一起進步。
無論是做C端研發還是B端研發,我認為最重要的三件事是:技術風險管控、全局視角、用戶體驗至上,下面將重點介紹這三件事。
技術風險管控:從解決問題到預防問題。
在B端業務中,系統的復雜性和業務邏輯的多樣性使技術風險管理變得尤為重要。通過從治理到預防,實現防治結合,規范業務應用研發和交付標準,完善業務監控與告警機制,確保及時發現和處理異常情況,從而確保系統的高質量交付。
我們通過梳理監控范圍,制定業務監控指標,收集接口層、邏輯層和視圖層的錯誤類型,設計錯誤上報格式規范。為了確保錯誤信息能夠被及時、準確地上報,我們設計了一套包括錯誤類型、錯誤描述、發生時間、用戶信息和設備信息的錯誤上報格式規范。統一的錯誤上報格式確保所有錯誤信息都能被及時、準確地記錄和處理。
在技術實施方案上,我們基于公司內部監控平臺,通過打點上報和全局攔截上報的方式,實時監控系統運行情況,收集和分析錯誤信息。通過不斷調試和優化報警閾值,當系統運行出現異常情況時,及時發送報警通知,確保相關人員能夠迅速處理問題。此外,我們定期審查系統運行情況、監控數據及用戶反饋,發現潛在問題和風險,及時進行處理和優化并補齊監控盲區。
集約式管理:從單一技術到全局視角,B端系統的核心策略
系統的復雜性和業務邏輯的多樣性,使得傳統的開發和管理模式難以滿足快速迭代和高質量交付的需求。為了解決多端多場景建設過程中出現的技術規范不一致、質量無法保障、資產無法復用與精細管理、部署成本過高、多團隊協同效率與安全低的問題,集約式管理應運而生,通過集中化的開發和管理模式,解決了許多傳統開發模式中的痛點。集約式管理在商家系統、B商城、線下系統的WEB端、H5、小程序有很好的落地實踐。
圖2:前端開發模式
解決的問題
1.開發效率低:傳統開發模式下,各個團隊獨立開發,重復造輪子,效率低下。集約式管理通過腳手架和工程化工具,提升了開發效率。
2.系統不穩定:由于缺乏統一的技術規范和標準,系統的穩定性和可維護性較差。集約式管理通過統一的調度配置管理中心,提升了系統的穩定性和可維護性。
3.管理成本高:將復雜系統/應用拆分微應用/微模塊后,帶來的副作用用是多倉庫管理成本增加。通過工具管理跨倉庫的依賴升級,通過 CI/CD 工具實現統一管理和集成,實現自動化構建和部署。
集約式管理的優勢
1.統一標準和規范:通過集約式管理,可以制定統一的技術標準和規范,提升系統的可維護性和可擴展性。
2.提高開發效率:通過腳手架和工程化工具,減少了重復勞動,提升了開發效率。
3.提升系統穩定性:通過統一的調度配置管理中心,提升了系統的穩定性和可維護性。
4.降低開發成本:通過集約化管理,減少了重復開發和資源浪費,降低了開發成本。
5.高效管理:通過集中化的管理模式,可以更高效地管理系統和團隊,提升整體的開發效率和質量。
當然,集約式管理的弊端也是有的,像初期成本高,集約式管理在初期需要投入大量的資源和時間進行技術選型、工具開發和標準制定,成本較高。靈活性降低,集約式管理通過統一標準和規范,對每一個源碼工程的開發、構建、上線部署全程管控,這可能會降低部分團隊的靈活性,影響個性化需求的實現,我們通過開放一定的配置化能力解決個性化的需求。
在項目實踐中的集約式管理,是通過前端工具集中了開發框架、原子組件、核心庫、環境配置、工程構建、自動配置等開發要素在Framework工程中,依托coding平臺的開放接口能力,進行集中統一的配置開發要素,約束各個子應用/模塊開發、構建、部署,以節約、約束、高效為導向,從而達到降低開發成本、高效管理。
Framework基座能力建設,在集約式管理中是關鍵的一環。通過構建統一的基座,提供標準化的開發和運行環境,提升系統的穩定性和可維護性。通過構建商家微應用和微模塊技術體系,實現系統的模塊化和組件化,提升系統的可擴展性和可維護性。包括運行容器、研發工程鏈路和DUCC數據服務等。集約式管理通過統一的調度配置管理中心,實現對系統的集中管理和監控,提升系統的穩定性和可維護性。通過強管控,確保各個子應用和模塊的開發和運行符合統一的標準和規范。
用戶體驗至上:從專注代碼實現轉變為關注用戶體驗
京東一直以來都把客戶放在最重要的位置,我們的企業文化就是“客戶為先”?,F在,我們更要從只關心代碼怎么寫,轉變成更加關心用戶用著感覺怎么樣。也就是說,東西能用還不夠,還得讓用戶愛上使用產品的感覺。
說到用戶體驗,簡單來說,就是要把用戶的需求、感受和滿意度放在心頭。一個好東西,不僅得實用、好用,還得讓用戶覺得爽。想象一下,你用的東西不僅功能全,而且用著還特順手,那感覺多棒!
要做到這點,我們得換個思路。以前我們可能更關心東西能不能用,現在我們要多想想用戶會怎么用,他們想要什么。這就像是,以前我們只管做飯,現在還得考慮吃飯的人口味如何,愛吃什么。所以,從設計到用戶體驗,我們得時刻想著用戶,關注他們使用的每一個小細節。比如,頁面怎么布局,顏色怎么搭,字體怎么選,還有用戶怎么和我們的產品互動,這些都得考慮。
當然,用戶體驗不是一個人就能搞定的,得靠大家齊心協力。不管你是負責什么的,都得關心用戶體驗,一起努力讓產品更貼近用戶,讓用戶愛上我們的產品。
最后,用戶體驗這個領域一直在變,我們也得跟著學,看看有什么新的設計理念,或者更酷更便捷的交互方式。總之,我們要以用戶為中心,做出既實用又讓用戶愛不釋手的產品。
未來展望:持續學習與創新
無論是業務研發還是基礎技術研發,我們的核心目標都是通過技術解決用戶痛點并實現價值的最大化。展望未來,我們致力于在業務研發領域持續推動技術創新,秉承價值驅動的理念,堅持長期主義,以打造卓越的B端平臺產品為己任。為此,我們將進一步深入探索業務需求,并運用先進的技術手段,旨在提升業務效率和優化用戶體驗。
從前端的角度來看,研發效率的瓶頸主要集中在視圖設計、邏輯編寫、接口聯調以及測試驗證等環節。伴隨著人工智能的出現,將會出現更智能的開發工具、全新的開發平臺,這將顯著提高研發效率和質量。
結束語
目前,我們憑借統一的技術架構和方案,為B端業務系統及研發人員提供了堅實的支撐。我們已按照既定標準,沉淀出通用的前端技術能力,這些能力深入滲透到商家系統、B商城、線下系統等核心B端業務領域,從而確保了商家用戶、運營及采銷團隊享有連貫且優質的體驗。
技術的發展是一個不斷探索與實踐的旅程。在此過程中,我們既要不斷學習新技術,也要持續優化和提升現有技術能力。通過分享我個人的成長經歷和技術實踐,我希望能為在技術道路上探索的同仁們提供些許啟示與助力。
不論您是初入職場的前端工程師,還是經驗豐富的技術大咖,只要您懷揣對技術的熱情和對未來的憧憬,我們都熱切期盼您加入我們的團隊。
加入我們吧
在京東,我們注重團隊合作和技術創新。我們鼓勵每個團隊成員分享自己的技術經驗和心得,通過技術交流和討論,共同解決問題和挑戰。我們還定期組織技術培訓和分享會,幫助團隊成員不斷提升技術水平和能力。
審核編輯 黃宇
-
前端
+關注
關注
1文章
192瀏覽量
17752 -
京東
+關注
關注
2文章
999瀏覽量
48500
發布評論請先 登錄
相關推薦
評論