“前端”工匠系列（二）：合格的工匠，怎么做好價值落地

此文為系列文章第一篇，為淺嘗輒止的引入，目的是為了讓前端從業(yè)人員及非從業(yè)但是對此領(lǐng)域感興趣的人對于”前端“是干什么的這個話題有個無門檻的了解。

“前端職能是什么”

說起"前端"，維基百科對這個技術(shù)角色的定位是“前端（英語：front-end）和后端（英語：back-end）是描述進程開始和結(jié)束的通用詞匯。 前端作用于采集輸入信息，后端進行處理。 計算機程序的界面樣式，視覺呈現(xiàn)屬于前端。”對于當(dāng)下服務(wù)于互聯(lián)網(wǎng)各企業(yè)的前端研發(fā)人員來說，這個崗位定義是很清晰的。前端是個對于后端的相對概念，它的崗位角色更應(yīng)該關(guān)注“采集和呈現(xiàn)”兩個部分。

從以上的概念來看，前端研發(fā)的正常職責(zé)是通過編碼工作對數(shù)據(jù)及業(yè)務(wù)邏輯進行展示，用戶通過操作界面（或其他交付方式）與系統(tǒng)進行交互，最后用戶的交互信息可以按照功能邏輯的預(yù)期傳輸?shù)胶蠖朔?wù)遞交給業(yè)務(wù)后端及更下游的算法層處理。

?

“編碼工作包括什么呢？”

前端研發(fā)人員工作對接的上游干系人包括產(chǎn)品和UI設(shè)計，必要輸入有產(chǎn)品文檔和UI設(shè)計稿件，下游干系人為后端研發(fā)人員，必要的輸出為一整套界面交互及邏輯處理實現(xiàn)代碼。

產(chǎn)品要向研發(fā)團隊輸出PRD（產(chǎn)品需求文檔Prodcut Requirement Document的簡稱）來對此次產(chǎn)品或者迭代的具體的功能細節(jié)進行詳細的描述，通過需求評審會議的方式與研發(fā)人員和設(shè)計人員進行“語言的互通轉(zhuǎn)換及翻譯”工作，得以把所有的產(chǎn)品邏輯向不同專業(yè)人員表達清晰，這是一切需求交付最重要的環(huán)節(jié)。對于新增的或者復(fù)雜的需求，需要有交互設(shè)計人員與產(chǎn)品人員共同輸出交互設(shè)計稿件，從另外一個維度對產(chǎn)品需求邏輯進行闡述，對于前端研發(fā)人員對于需求理解的清晰程度來看，交互設(shè)計稿件的嚴(yán)謹(jǐn)和質(zhì)量十分重要。

UI設(shè)計人員需要根據(jù)產(chǎn)品需求文檔和交互設(shè)計稿件對界面的UI風(fēng)格、色系及動效等素材進行設(shè)計畫制作，向研發(fā)人員輸出UI設(shè)計稿件，此項工作需要前端研發(fā)、產(chǎn)品和設(shè)計人員進行多輪溝通以便敲定所有元素細節(jié)。UI設(shè)計稿件的設(shè)計質(zhì)量和對產(chǎn)品邏輯的描述精細度，直接對前端研發(fā)人員的編碼設(shè)計方式和效率產(chǎn)生影響，前端研發(fā)人員必須對UI設(shè)計稿件有足夠的重視，避免在實現(xiàn)過程中反復(fù)與產(chǎn)品和設(shè)計人員對設(shè)計稿件的細節(jié)進行確認甚至重新設(shè)計。如果這種情況出現(xiàn)，勢必對項目的排期產(chǎn)生影響。最后，前端研發(fā)的界面輸出要通過UI設(shè)計人員的驗收測試才算完成界面編碼工作。

與后端研發(fā)人員的對接是研發(fā)工作中的重中之重，最終，一整套前后端研發(fā)人員公認的經(jīng)過冒煙用例自測的代碼包才是此階段的合格產(chǎn)出物。接口規(guī)范、約定習(xí)慣以及默契度較高的對接伙伴，都是業(yè)界不斷在研發(fā)調(diào)試、聯(lián)合調(diào)試以及提測冒煙過程中提效降本的思路。“一切都是人的事”“約定大于習(xí)慣”這些對軟實力、流程的嚴(yán)謹(jǐn)程度都提出了要求。

研發(fā)流程中最后的步驟是UAT驗收后上線。上線一定要采用“流水線自動化”的方式才行，也就是大家常說的“CI/CD”。只有這樣做，才能保證主干版本代碼與線上代碼版本完全保證一致，不會因為人為把自己本地代碼編譯打包后發(fā)布到線上，導(dǎo)致主干分支成為擺設(shè)；所有上線相關(guān)的合并、編譯、打包、發(fā)布等核心流程都是流水線自動跑事先部署在流水線各個節(jié)點的腳本，才能避免人為操作“失誤”導(dǎo)致的線上問題。

“上線了？”

上線是個很值得探討的話題，因為對于研發(fā)來說，只有上了線并且發(fā)揮了預(yù)期或者超預(yù)期的業(yè)務(wù)價值的代碼，才算是對企業(yè)、對社會有一點點貢獻，個人的價值才能在工作中得以體現(xiàn)。上線完成就是研發(fā)工作的結(jié)束嗎？對于很多研發(fā)團隊來說，這就是最后一步了。但是，研發(fā)流程僅僅止步于此，是不符合“合格”這個標(biāo)準(zhǔn)的。一套代碼，只有在上線后，才開始受到真正用戶的親測使用，研發(fā)人員的產(chǎn)出物才算是“生命開始”。產(chǎn)品功能在用戶的使用中“表現(xiàn)是否符合預(yù)期”、“是否有邊界異常”、“是否存在打不開頁面的情況”、“是否存在顯示異常的情況”，諸如此類的問題，都應(yīng)該是產(chǎn)研需要關(guān)注的話題。

因此，研發(fā)人員需要預(yù)先在代碼包中預(yù)留與線上真實用戶“交流”的抓手，通過分析用戶在“可用性和性能”做出可以提升用戶體驗的改進措施，例如，“特殊邏輯自定義埋點上報”、“邊界兜底監(jiān)控”、“系統(tǒng)運行時監(jiān)控”等，只有做到了這些，才能說對一個用戶功能的真正上線，后續(xù)也才有精細化運營的可能。可是，對于很多研發(fā)人來說，“上線即需求的終點”、“線上問題由業(yè)務(wù)反饋”、“有客訴嗎？”都是研發(fā)普遍存在的心理。

那如何通過“預(yù)先”的方式建立與用戶之前的溝通通道呢？因為此文為前端領(lǐng)域文章，所以我們此次只說前端部分。

“與用戶交流”

有效的交流是需要以有效的信息為載體的。對于技術(shù)實現(xiàn)來說，就是對核心代碼塊進行合理的代碼埋點。當(dāng)特殊用戶行為發(fā)生時，當(dāng)代碼處理邏輯走向了一個非正常的處理單元時，當(dāng)發(fā)生了代碼處理邏輯沒有覆蓋到的情形時，埋點上報代碼就會觸發(fā)執(zhí)行，向中心化的埋點服務(wù)發(fā)送消息。技術(shù)人員通過對此次用戶行為觸發(fā)的埋點信息的分析，從而得到用戶在瀏覽或操作頁面過程中的“正常或異常”情況的“現(xiàn)場復(fù)現(xiàn)”，當(dāng)然，這種復(fù)現(xiàn)可以是數(shù)據(jù)信息，也可以是截圖或視頻回溯，具體要用什么方式來復(fù)現(xiàn)用戶行為，要以“有效”為目標(biāo)，綜合考慮“用戶流量成本、研發(fā)成本、性能影響以及存儲成本”等因素來最終選型。

“實時 OR T+1”

對于業(yè)務(wù)前端用戶行為及觸發(fā)邏輯的監(jiān)控，有實時監(jiān)控和異步監(jiān)控兩種。

在實時關(guān)注用戶行為、實時分析等場景里，需要使用實時監(jiān)控，這個“實時”，一般到秒級就夠用了，一些業(yè)務(wù)使用分鐘級也是可以的，具體看業(yè)務(wù)的需要。對于實時監(jiān)控，上報行為是從每一臺用戶的設(shè)備上觸發(fā)并上報的，應(yīng)用于大體量業(yè)務(wù)來說，這個數(shù)據(jù)量的采集、上報、收集、存儲、分析和報表的生成，都是相當(dāng)耗費資源的。為了降本提效，埋點服務(wù)首先會對用戶數(shù)據(jù)按照特殊的規(guī)則（比如正態(tài)分布）進行一層比例的抽樣，降低分析及報表生成過程中對資源和人力的消耗。

在用戶端日志查詢、特殊邊界場景復(fù)現(xiàn)、日志排查定位故障等場景，“實時”就不是必要的，這種場景下一般采用T+1查詢，但是又引入了大量級日志的存儲周期的話題，一般企業(yè)應(yīng)用級的用戶日志保存14天就完全夠用了，因為對于C端日志來說，更多的是對現(xiàn)場故障的復(fù)現(xiàn)、處理及跟進，如果算法策略對用戶日志有需要，只需要在一定時間內(nèi)采用處理任務(wù)對用戶日志進行一次處理，把輸出的標(biāo)簽、行為特征等關(guān)鍵數(shù)據(jù)存儲就可以，基礎(chǔ)的用戶日志還是應(yīng)該被存檔或清除釋放資源供給更有價值的最新日志來使用。

綜上所述，實時監(jiān)控和非實時監(jiān)控分別應(yīng)對兩種場景：實時對應(yīng)“業(yè)務(wù)可用性、線上運行時異常”等使用訴求，非實時對應(yīng)“性能指標(biāo)、用戶日志查詢、用戶行為復(fù)現(xiàn)”等使用訴求。

“后續(xù)”

之后會繼續(xù)講述一些有關(guān)"用戶體驗、效率提升、頁面搭建"相關(guān)的話題。

審核編輯 黃宇