此文為系列文章第一篇，為淺嘗輒止的引入，目的是為了讓前端從業人員及非從業但是對此領域感興趣的人對於”前端“是乾什麼的這個話題有個無門檻的瞭解。 ...
作者：京東零售 劉偉東
此文為系列文章第一篇，為淺嘗輒止的引入，目的是為了讓前端從業人員及非從業但是對此領域感興趣的人對於”前端“是乾什麼的這個話題有個無門檻的瞭解。
“前端職能是什麼”
說起"前端"，維基百科對這個技術角色的定位是“前端（英語：front-end）和後端（英語：back-end）是描述進程開始和結束的通用辭彙。 前端作用於採集輸入信息，後端進行處理。 電腦程式的界面樣式，視覺呈現屬於前端。”對於當下服務於互聯網各企業的前端研發人員來說，這個崗位定義是很清晰的。前端是個對於後端的相對概念，它的崗位角色更應該關註“採集和呈現”兩個部分。
從以上的概念來看，前端研發的正常職責是通過編碼工作對數據及業務邏輯進行展示，用戶通過操作界面（或其他交付方式）與系統進行交互，最後用戶的交互信息可以按照功能邏輯的預期傳輸到後端服務遞交給業務後端及更下游的演算法層處理。
“編碼工作包括什麼呢？”
前端研發人員工作對接的上游干係人包括產品和UI設計，必要輸入有產品文檔和UI設計稿件，下游干係人為後端研發人員，必要的輸出為一整套界面交互及邏輯處理實現代碼。
產品要向研發團隊輸出PRD（產品需求文檔Prodcut Requirement Document的簡稱）來對此次產品或者迭代的具體的功能細節進行詳細的描述，通過需求評審會議的方式與研發人員和設計人員進行“語言的互通轉換及翻譯”工作，得以把所有的產品邏輯向不同專業人員表達清晰，這是一切需求交付最重要的環節。對於新增的或者複雜的需求，需要有交互設計人員與產品人員共同輸出交互設計稿件，從另外一個維度對產品需求邏輯進行闡述，對於前端研發人員對於需求理解的清晰程度來看，交互設計稿件的嚴謹和質量十分重要。
UI設計人員需要根據產品需求文檔和交互設計稿件對界面的UI風格、色系及動效等素材進行設計畫製作，向研發人員輸出UI設計稿件，此項工作需要前端研發、產品和設計人員進行多輪溝通以便敲定所有元素細節。UI設計稿件的設計質量和對產品邏輯的描述精細度，直接對前端研發人員的編碼設計方式和效率產生影響，前端研發人員必須對UI設計稿件有足夠的重視，避免在實現過程中反覆與產品和設計人員對設計稿件的細節進行確認甚至重新設計。如果這種情況出現，勢必對項目的排期產生影響。最後，前端研發的界面輸出要通過UI設計人員的驗收測試才算完成界面編碼工作。
與後端研發人員的對接是研發工作中的重中之重，最終，一整套前後端研發人員公認的經過冒煙用例自測的代碼包才是此階段的合格產出物。介面規範、約定習慣以及默契度較高的對接伙伴，都是業界不斷在研發調試、聯合調試以及提測冒煙過程中提效降本的思路。“一切都是人的事”“約定大於習慣”這些對軟實力、流程的嚴謹程度都提出了要求。
研發流程中最後的步驟是UAT驗收後上線。上線一定要採用“流水線自動化”的方式才行，也就是大家常說的“CI/CD”。只有這樣做，才能保證主幹版本代碼與線上代碼版本完全保證一致，不會因為人為把自己本地代碼編譯打包後發佈到線上，導致主幹分支成為擺設；所有上線相關的合併、編譯、打包、發佈等核心流程都是流水線自動跑事先部署在流水線各個節點的腳本，才能避免人為操作“失誤”導致的線上問題。
“上線了？”
上線是個很值得探討的話題，因為對於研發來說，只有上了線並且發揮了預期或者超預期的業務價值的代碼，才算是對企業、對社會有一點點貢獻，個人的價值才能在工作中得以體現。上線完成就是研發工作的結束嗎？對於很多研發團隊來說，這就是最後一步了。但是，研發流程僅僅止步於此，是不符合“合格”這個標準的。一套代碼，只有在上線後，才開始受到真正用戶的親測使用，研發人員的產出物才算是“生命開始”。產品功能在用戶的使用中“表現是否符合預期”、“是否有邊界異常”、“是否存在打不開頁面的情況”、“是否存在顯示異常的情況”，諸如此類的問題，都應該是產研需要關註的話題。
因此，研發人員需要預先在代碼包中預留與線上真實用戶“交流”的抓手，通過分析用戶在“可用性和性能”做出可以提升用戶體驗的改進措施，例如，“特殊邏輯自定義埋點上報”、“邊界兜底監控”、“系統運行時監控”等，只有做到了這些，才能說對一個用戶功能的真正上線，後續也才有精細化運營的可能。可是，對於很多研發人來說，“上線即需求的終點”、“線上問題由業務反饋”、“有客訴嗎？”都是研發普遍存在的心理。
那如何通過“預先”的方式建立與用戶之前的溝通通道呢？因為此文為前端領域文章，所以我們此次只說前端部分。
“與用戶交流”
有效的交流是需要以有效的信息為載體的。對於技術實現來說，就是對核心代碼塊進行合理的代碼埋點。當特殊用戶行為發生時，當代碼處理邏輯走向了一個非正常的處理單元時，當發生了代碼處理邏輯沒有覆蓋到的情形時，埋點上報代碼就會觸發執行，向中心化的埋點服務發送消息。技術人員通過對此次用戶行為觸發的埋點信息的分析，從而得到用戶在瀏覽或操作頁面過程中的“正常或異常”情況的“現場復現”，當然，這種復現可以是數據信息，也可以是截圖或視頻回溯，具體要用什麼方式來複現用戶行為，要以“有效”為目標，綜合考慮“用戶流量成本、研發成本、性能影響以及存儲成本”等因素來最終選型。
“實時 OR T+1”
對於業務前端用戶行為及觸發邏輯的監控，有實時監控和非同步監控兩種。
在實時關註用戶行為、實時分析等場景里，需要使用實時監控，這個“實時”，一般到秒級就夠用了，一些業務使用分鐘級也是可以的，具體看業務的需要。對於實時監控，上報行為是從每一臺用戶的設備上觸發並上報的，應用於大體量業務來說，這個數據量的採集、上報、收集、存儲、分析和報表的生成，都是相當耗費資源的。為了降本提效，埋點服務首先會對用戶數據按照特殊的規則（比如正態分佈）進行一層比例的抽樣，降低分析及報表生成過程中對資源和人力的消耗。
在用戶端日誌查詢、特殊邊界場景復現、日誌排查定位故障等場景，“實時”就不是必要的，這種場景下一般採用T+1查詢，但是又引入了大量級日誌的存儲周期的話題，一般企業應用級的用戶日誌保存14天就完全夠用了，因為對於C端日誌來說，更多的是對現場故障的復現、處理及跟進，如果演算法策略對用戶日誌有需要，只需要在一定時間內採用處理任務對用戶日誌進行一次處理，把輸出的標簽、行為特征等關鍵數據存儲就可以，基礎的用戶日誌還是應該被存檔或清除釋放資源供給更有價值的最新日誌來使用。
綜上所述，實時監控和非實時監控分別應對兩種場景：實時對應“業務可用性、線上運行時異常”等使用訴求，非實時對應“性能指標、用戶日誌查詢、用戶行為復現”等使用訴求。
“後續”
之後會繼續講述一些有關"用戶體驗、效率提升、頁面搭建"相關的話題。
