杭州前端阿里線下聚會（上）

　　有幸在好友的介紹下參加阿里舉辦的杭州前端線下交流會，半天下來收穫仍是很多。寫篇文章總結一下，爲了防止字數過多，因此將一篇文章經過上中下來寫，減小每篇的字數。

　　在2.22那天從學校急匆匆地打的趕到濱江的阿里，這算是第一次來參觀阿里的辦公大樓，仍是至關霸氣威武的。

　　阿里巴巴目前在杭州的濱江地區，週六的濱江真的是路很寬，人不多，車不多，風挺大，各類林立的辦公大樓與人煙一對比，不免讓人聯想到被媒體炒熱的「鬼城」一詞。

　　題外話說到這裏，本次線下交流會是由阿里1688的前端團隊主辦的線下前端交流會，在阿里內部的嶽麓書院（其實就是一個教室大小的房間）舉行，到會的除了阿里系以外約有30人左右，聚會設置了13：30到場，14：00正式開始，在活動開始前在房間的一邊設置了一些阿里前端的一些項目展現（這個在後文中會提到）；

　　教室裏一共設了4張圓桌，用臺籤標明瞭四大主題：node.js,用戶數據採集和行爲分析，移動無線（大概是這個意思），前端集成開發環境。參加聚會的同窗們能夠按照本身的興趣點挑選圓桌，那麼對應圓桌的討論議題也就是對應的臺籤。主持人是個帥帥的gg，他首先介紹了阿里1688的前端團隊，指出了本次交流會的主旨在於改變其餘交流會只是單獨有人在上面講下面人聽的形式，讓參加活動的每一個人都可以有機會發表本身的見解或者是疑問，同時這些疑問能夠被其餘人所解決。包括阿里自身在團隊在工做中也會遇到這樣那樣的困惑，但願可以經過交流得到一些啓發。

　　14：15左右討論正式開始，平均每張圓桌圍坐了10人左右，其中大概有2-3個阿里系的員工進行話題的引出和相關的時間引導與安排，我首先在前端集成開發環境這個議題的圓桌坐下，經過自我介紹以後，能夠發現與會的同窗基本上來自杭州的IT公司的前端，零星包含着想我這樣還在學校的學生。下面是討論的一些筆記：

　　前端集成開發環境從流程上來講包含：本地開發->打包編譯->測試->發佈部署->線上監控這些環節。若是全部步驟都是由人工來進行按步操做就會致使前端人員的時間的大量浪費在重複性，非技術性的環節之中，而一個合適的集成開發環境可以節省時間，優化流程。在討論過程當中提到了國內外的一些方案：FIS http://fis.baidu.com— 百度web前端研發部提出的前端解決方案。Grunt http://gruntjs.com一個基於任務的JavaScript工程命令行構建工具,阿里的crox；

　　印象比較深入的是經過md5的比較可以由機器自動識別改動，也就是一旦一個文件發生微小改動，整個工程就能經過md5識別出來，對於改動的內容如圖片連接，就會自動加入新的時間戳，這個對於曾經有個須要本身在必定時間超出須要手動更新時間戳的經從來說無疑是一大便利。討論中有同窗提出了本身在開發過程當中的一些疑惑，阿里的同窗也提出了本身的見解，對於我我的來講，由於相關的工程經驗比較少，更多地是瞭解了主流的發佈流程以及一些國內外的解決方案以方便往後學習。

　　通過一小時的討論後，進行了一個相似於一站到底的遊戲進行互動。同時人員也再次進行了分配，我來到了用戶數據採集和行爲分析。這裏的主講師是之昊，相比於其餘桌的偏於技術，之昊向咱們展現了更多的是一種將來可能的趨勢：

 傳統需求採集，經過獲取用戶對於在web頁面上的操做行爲如點擊按鈕，填寫表單等每一個行爲做爲一個數據進行採集到後端，通過後端服務器的大數據量的計算進行用戶行爲分析，如由兩個表單填寫間隔時間過長能夠猜想表單提醒的引導性不夠，進而轉換爲一個需求來進行頁面改動。

　　而之昊認爲這樣一個需求由用戶使用到更改的邏輯鏈過長，沒法對於用戶的實時使用進行改動，也就是咱們的頁面過於單板，不夠智能。是否能夠經過將用戶的行爲數據部門存於瀏覽器本地緩存，（相似於localstorage的概念）經過js的讀取來實時地判斷用戶的行爲，如：對於某一用戶或者某一類用戶某一表單填寫等待時間過長，說明缺乏引導這時候在頁面上顯示出新的引導，也就是對於不一樣人可能面對的就不是徹底相同的代碼了，當改動以後的用戶採集數據獲得了正反饋，進而這種大數據量的正反饋就會逐漸成爲後端的一個規律，也就是以後若是用戶遇到疑惑就會後臺自動生成一段提示代碼進行提示。 也就是由個體轉爲了規律。做爲前端經過直接的數據讀取，就能夠下降後端服務器的數據處理需求，下降成本以及更好地利用服務器性能。