jtalk第七期前端場--收穫分享

前言

本次分享主要是三個主題吧，一個是阿里通訊染陌大神漸進式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 爲員工找到進步的節奏，依據，讓他感覺到本身在切實的成長，公司也感覺並感激他的付出