前言
本次分享主要是三個主題吧，一個是阿里通訊染陌大神漸進式pwa的入門級介紹，一個是有贊連成傑分享涉及前後端協作的技術產物zanProxy和zanApi的部分，一個是宋小菜--scott老師關於前端一些方法論的分享。
然後我自己的話大概前端做了三年多一點，分享下自己的感受吧，有整理不對或者理解不對的，歡迎大家吐槽，我們從小白到大師慢慢來。
pwa：漸進式web應用
核心介紹特點
- service worker 主要用途以及其生命週期、更新機制
檔案請求載入以及資料載入優化，主要是離線場景使用；其api的部分相信大部分開發者查到使用文件並不難，不再贅述。
- 相關api 不斷完善中，但一些已經開發出來的部分對於開發者還是不錯的，比如訊息推送
- 桌面快捷入口
提供了一個區別於web瀏覽器地址和原生應用的中間體驗方式，可以新增到主屏；也有技術大神斷言，現在的electron（一個使用 JavaScript, HTML 和 CSS 等 Web 技術建立原生程式的框架）就是其之後的發展趨勢，可以實現在移動端替代原本的客戶端，或者其之後就會和electron實現技術合併，成為前端跨端應用技術。
- 相關推薦
light house是一款chrome外掛可以檢視web app的效能；pwa.rocks可以檢視到已經進行pwa實踐的專案；https://github.com/alibaba/ice，https://alibaba.github.io/ice/，阿里的開源專案推薦。
推薦場景
- 對離線使用體驗要求高的
- 靜態資源或者資料內容變化係數低的應用型別
- 業務初期推廣以及相關使用者引流以及啟用的技術棧
可能瓶頸
谷歌的技術支援不夠到位 ，並不是所有的中小公司都可以有如此的技術力量去實行； 需要https支援，如果業務的站點還沒做升級會有問題； 使用者習慣，你的使用者要習慣把web應用放到桌面上； 雖然主流瀏覽器支援，但要求較高的版本，而且其不可預期的問題還是很多的，部分低端機型還是有問題的，而不可能放棄這部分使用者； 產品體驗對離線使用有切實較高的要求； 需要在業務中區分清楚什麼情況下使用service-work，如果在很多場景中需要採用就要有細緻的區分，增加很多不同場景帶來的測試用例成本、產品定位成本，比如使用者離線的時候你讓它下單，這條肯定是失敗的，因為要連線伺服器產生真實資料，那麼這個業務點其實就是不能離線使用的，還有些資料如果使用者對資料真實性敏感的比如股票，如果產品不明確講明離線的資料是無效的，並闡明就會有相應的問題，當然這些只是更科學的做法，不是因為pwa引來的，而是因為離線你現在有資料的方案帶來的體驗必然要考慮的工作量與風險。
有贊前後端協作產出
首先，我個人是覺得有讚的技術tl以及整個團隊方案是很讚的，不但完成了其業務目標，而且完成了技術基礎建設，甚至進行了技術開源，作為一家非bat規模的公司，還是很不錯的，所以很多杭州的中小公司都會想參觀學習有贊內部究竟這些輪子能做什麼事情，有什麼缺點。
然後更具體的內容我覺得大家看有贊技術開放日那天介紹的比較詳細，移步有贊技術開放活動
我自己的個人感受是： 1 有贊確實在某些痛點上和大多數中小公司是一樣的，所以做的方案也是很切中要害的，但我覺得其真實的方案可能有兩點侷限性：與前端業務執行方式和前端整體技術棧掛鉤比較不容易解耦；與後端協作的某些細節以及後端對應的技術棧有較強關聯。所以在片面的使用它某些技術棧的時候，可能會與自己公司存在不符的情況。 2 技術核心是什麼。就技術核心來講，有讚的幾個技術成品沒有太複雜深入到其他公司研發團隊做不出來或者研究不出來的。但大多數公司更傾向於使用現有的技術成品，比如說請求攔截，開源的是fidder、postman,資料mock有mockjs或者easymock，寫api文件有阿里的rap或者swaggar，而缺少研發人員所應該具有的極客精神。然後ui框架也是的，滴滴出行、餓了麼很多公司都有開源出來其ui框架，但公司自己的ui元件卻拿不出來，可能更像是因業務堆砌的一堆頁面、死元件。
所以，最終個人感覺蠻需要反思的，也是更需要向有贊學習的，不管你當前技術棧是什麼，有多先進或者落後，紮根於當前分析大家目前能接觸到的最優技術棧並且分析其不足並用一定的可行方案做自己研發團隊能用的輪子，這點很重要。別人團隊再好的東西，很多時候不能直接拿來用的。
- 安利內容：線上編輯程式碼：Online coding
宋小菜 ，scott老師：前端方法論--套路
我個人來講，其實每隔一段時間就會聽一些溼貨，更多人喜歡叫方法論，純技術的人管這個叫套路。自己在畢業後的一年期限的時候，也開始做一名小主管，所以套路這東西從那時就開始慢慢的滲透到自己的管理思想和日常工作中。那麼，我結合scott老師有提到的一些點帶些案例出來，相信大家會理解的更好。
本能牴觸情緒
15年的時候還沒開始風行三大框架，大部分的公司還是前後端未分離，使用bootstrap+jq的時代。我們公司也是這樣的，但即便如此還是有人分不清js原生語法和jq語法，對jq語法一知半解，程式碼寫著寫著就摻雜了原生的部分，很多js封裝物件知識存在漏洞卻以能解決業務需求為理由拒絕學習。比如jq的鏈式操作、jq外掛不會寫、js物件的拷貝、js閉包、js陣列的複製與刪除等。 這時候，你如果和他們推jq的鏈式操作會建議你如何寫，某些dom的操作這樣寫是效能更快的，這些事件是這樣繫結的，他們根本聽不進去的。這個場景就和今天，三大框架風行，大部分人只會簡單用用，卻用不好，卻不知道為什麼這樣用，其原始碼是如何思考的一無所知很相似的吧。
方法論 ： 1 把正經可用的技術體系搬上技術棧、日程 2 讓牴觸學習的人在平時的開發中真實的體會到這樣寫帶來的問題，以及推薦的寫法帶來的優勢，並對比的獎勵那些寫優質程式碼的人 3 把技術提升部分作為員工技術評級考核的一部分
不能只談技術革新
老大肯定說先把業務搞上去，用啥技術不重要。產品肯定說，做業務，加業務。如果你直接談，給我研發一段時間，去做技術建設，去做程式碼重構，基本是失敗的。在公司小的時候，老大們會說，我們還沒發展到那個階段。到人多了，老大們會說你們做這個能帶來多少業績增長，或者你能保證這個能帶來多大的效率提高麼？作為技術推進的你，你也很猶豫，因為一方面你知道目前的方式肯定不行，另一方面，自己想的那個方案因為沒有實踐經驗自己也不敢打保票，然後公司也不曾培養過你這方面的能力。
方法論 ： 1 保留並持續的積累在某個方面問題的解決方案以及其具體的解決能力是什麼，反覆模擬確人，為溝通提供佐證。 2 尋找合適的破綻時機，比如你預言的某個場景或者問題爆發了，然後和老大去談，這個問題我有比較成熟的方案可以去推進解決。 3 向產品和領導們宣講你的技術方案，在間歇的時間裡做一些技術產品的甜頭，或者噱頭，給產品和老大看到技術改革所帶來的紅利，那麼推進會更容易 4 不要貪大，不要激進。從每個可控的可優化的細節部分開始，尤其是自己還不是某方面大牛的時候。
分業務線，不做救火人員
曾經私下和前端網的情封以及很多tl私聊過，其實大多數人都是建議前端分業務線的。然後具體的方案可能是：某個業務線固定的交固定人負責，讓其整理其模組並不斷地優化，中間哪怕業務忙了或者鬆了也是這個人負責。
那麼這樣做優勢是很明顯的，可以讓人對業務，對這部分業務使用的技術棧非常清楚，也給足了他足夠的機會和時間成為業務線的負責人而不僅僅是前端負責人。
可能的缺點就是：可能會導致他對其他業務不熟悉，對其他技術棧不熟悉。彌補的方案就是定期進行業務輪崗，技術輪崗，這個期限可能是半年或者一年。還有一個缺點就是可能會存在某個業務線真的臨時很忙，這時允許抽調人員，但不允許變更業務負責人；如果某個業務線長期業務緊，建議招人。
方法論 ： 1 分業務線，分模組處理業務，不要哪裡有活幹哪裡，也不要什麼活都接 2 進行定期的業務和技術輪崗，進行業務和技術更綜合的成長 3 對成員的管理、業務熟悉更加把握的細緻，讓他們成為技術的主人、業務的管理者。
技術棧的推進
假設你們公司已經開始說要推進技術棧了，但大部分專案都是原始專案，然後有人學了一個月vue，覺得很好用就說為啥不用vue呢，這個好用，那裡好用。還有的人學了下es6的語法，就開始鼓勵整個公司全部用es6語法去專案裡寫程式碼。然後遭到了技術總監的拒絕或者專案中遇到了滑鐵盧。
對於公司來講，大多數時候，其實並沒有到技術必須重構了才能業務做下去的場景的。前端大熱的場景下，隨便一個前端在自己的公司裡發現現在前端大熱的技術怎麼公司都不用的，然後就有點鬱悶，開始公司裡推，或者自己悄悄的寫兩行爽一下。今天scott老師也講到了，推技術棧不是簡單的一點。react就要把react全家桶以及其一系列的技術點、流程、可能帶來的問題，其技術方案完全準備好，沒準備好就最好不要開始。我最初也是這樣建議的，用vue-cli寫一個demo誰都會，但如果誰都會然後就開始寫程式碼了，引進vue了，就開始的太隨便啦。和大家當初用jq一樣，也許很多人都不知道requirejs或者seajs這種東西，人家那時候就在按模組載入了，而當初大家誰都不知道還可以這樣操作。所以問題不在於你知道了，而在於你理解的有多深，你能用好麼，你有架構師的深度和解決一系列工程化、業務化的能力沒有。
方法論 ： 1 推技術棧不是官方出個框架，你開始複製貼上這部分api這樣，需要進行技術預研，技術可行分析，其完整的生態，對團隊的要求種種苛刻的條件的 2 推技術棧也可以以大化小，先推某個技術點，某個原本框架的痛點可以用新框架的某個特性解決。 3 推技術棧可以漸進的，不用一次到位，先針對一個簡單場景找出其對應的方案是什麼，進行實踐驗證成功之後再進行下一步。 4 保障足夠的學習與技術基礎，不是隻是自己興趣或者自己不滿意公司的現狀 5 有足夠的溝通能力、團隊協商能力、能針對每個具體情況分析清自己切實需要的可行方案，以及對應的其他職能部門需要怎麼配合你，流程是什麼
人的成長是最不可忽略的一環
大家做業務都沒問題的啊，工資也沒少給，但還是有大波的人因為公司沒有用jq，因為公司vue用的不好，因為自己覺得專案不規範就離職了。對於技術來講，業務的堆砌對於他們來講是不敏感的，自己敏感和感興趣的是自己能寫什麼苦逼的程式碼，自己能力上升了。所以由此帶出，無論你想讓成員做什麼業務，保證一定的人的成長是非常關鍵的。
方法論： 1 定期的技術能力以及軟能力的溝通，考核，指導 2 提供成長的土壤、資源 3 提供其在能力成長的時候可以得到專案的歷練，職位以及薪資的提高 4 個人職業規劃，人生規劃，個人建議的長期關注 5 幫助員工落實她認為可以改善的事情，你或者公司能幫他做的，幫助員工落實你想讓他做的事情 6 為員工找到進步的節奏，依據，讓他感受到自己在切實的成長，公司也感受並感激他的付出