作者：京東零售 劉偉東
此文為系列文章第一篇，為淺嘗輒止的引入，目的是為了讓前端從業人員及非從業但是對此領域感興趣的人對於”前端“是幹什麼的這個話題有個無門檻的瞭解。
“前端職能是什麼”
說起"前端"，維基百科對這個技術角色的定位是“前端（英語：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端日誌來說，更多的是對現場故障的復現、處理及跟進，如果演算法策略對使用者日誌有需要，只需要在一定時間內採用處理任務對使用者日誌進行一次處理，把輸出的標籤、行為特徵等關鍵資料儲存就可以，基礎的使用者日誌還是應該被存檔或清除釋放資源供給更有價值的最新日誌來使用。
綜上所述，實時監控和非實時監控分別應對兩種場景：實時對應“業務可用性、線上執行時異常”等使用訴求，非實時對應“效能指標、使用者日誌查詢、使用者行為復現”等使用訴求。
“後續”
之後會繼續講述一些有關"使用者體驗、效率提升、頁面搭建"相關的話題。