Alloyteam Conf 2017 現場實錄

時間  2019-11-15
標籤 alloyteam conf 現場 實錄 欄目 職業生涯 简体版
原文   原文鏈接


首先是大佬登場介紹 AC 是每一年一度的 Alloy Team 團隊技術分享會，而前段時間 TFC 主要是邀請業界大牛的技術分享。AC 但願給開發者提供最好的參會體驗，也但願現場的各位分享本身的故事。
插個開場舞圖：

第一場：面向億萬級用戶的 Web 同構直出

以興趣部落爲例講解面向億萬用戶的 Web 同構直出。
首先介紹了一些基本概念。
什麼是直出？javascript

以 Node 做爲後端語言實現的服務端渲染頁面並輸出的技術。複製代碼

什麼是同構？前端

客戶端與服務端能夠共享部分代碼複製代碼

而後給出了兩個二維碼，讓你們掃碼體驗哪一個是直出前頁面，哪一個是直出後頁面。java


接下來主要分兩部份內容繼續議題，如何同構直出以及服務的高可用行。

如何改造直出

同構直出的三要素
  • DOM 一致性
    保持DOM一致性利用了 React 虛擬 DOM 的思想。服務端經過 ReactDomServer.renderToString 拼裝 HTML 字符串，返回給瀏覽器。瀏覽器端根據服務端返回的數據 ReactDom.render 出真實 DOM。
  • Data 一致性
    保持數據一致性服務端經過http.request請求須要直出頁面的數據，經過 store 保存數據，瀏覽器端經過Provider 中的 store 屬性渲染服務器返回的數據。
    遇到的問題：前端代碼不能在服務端執行，瀏覽器使用 ajax，Node端使用 http.request 如何解決。
    不能在服務端執行的前端代碼經過打標籤，使用構建工具處理。
    `_BROWSER_`;
...
`_END_`;複製代碼
  • Route 一致性
    先後端路由保持一致性，避免返回錯誤頁面。
方案

經過直出框架機來實現。react

  • 首先是項目構建
  • 接下來是 actions 提取。
    整個框架機的工做流以下：

高可用性

開發調試

框架集本地開發調試經過使用命令行工具包 fireDragon ,執行如下命令就能夠啦。jquery

npm link // 創建全局連接
firedragon init //初始化路由配置
firedragon // 讀取路由配置文件，啓動服務複製代碼
容災

容災採用兩種方式，框架機進行柔性處理，以及接入層轉發。git

壓測

經過 wetest.qq.com 平臺監控各項應用數據瞭解承受能力，找出性能瓶頸。github

灰度

採用灰度發佈，逐步擴大直出頁面訪問用戶從 10 拓展到 3億，服務器從 1 臺拓展到 111 臺。web

監控告警

服務器層面從 CPU 使用率，CPU 性能，內存佔用，磁盤 IO，網絡 IO 監控。
運行時數據從腳本錯誤，測試，PV/UV，直出服質量，後臺接口質量和染色日誌。面試

第二場：大型 Web 項目可用性提高零腳本錯誤的實戰

零腳本錯誤實戰主要從下面五個方面展開講解。ajax

如何發現代碼出了問題

客戶反饋？老闆連環奪命 call ? 經歷了這些思考採用更高效的方案。

基礎監控體系組成

體系組成分爲三步，監聽->上報->數據收集系統。

  • 監聽
    使用 try-catch，window-onerror。
  • 上報
    發送 ajax請求或者直接使用 img。
  • 數據收集系統
    • 提供上報接口
    • 存儲上報數據
    • 數據分析展現

錯誤信息分析與優化

上報發現遇到不少 script error 錯誤，是由瀏覽器的同源策略致使的。
如何解決呢？script 標籤添加 crossorigin屬性，後端作 CORS 處理。

Web 安全與腳本錯誤

錯誤腳本分析基於 SourceMap 監控方案解決。
經過生成 SourceMap 文件維護源文件和處理後文件的映射關係，使用 VLQ 編碼來存儲映射。
或者使用開源的 sentry。

CSP 內容安全策略

監控、上報白名單中的前端資源。

  • 使用方式
    HTML Meta 標籤
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'" >複製代碼
    HTTP Header(響應頭帶上 CSP 的指令)
  • 配置
    使用上報（不攔截），攔截兩種方式。複製代碼
直接採用 https://

開發測試與腳本錯誤

推薦了兩個插件，js-error-dialog報錯彈窗和prettyjs代碼格式化、高亮和錯誤展現。

第三場：如何構建後現代前端工程化開發體系

分享提問開發者開發的第一個網站爲引導，引出前端工程化的議題，而且從開發環境、銜接和生產環境三個環節來說述。

開發

開發工程化從三個主要環節進行，腳手架與命令行、組件化和接口聯調。

  • 腳手架與命令行
    腳手架的搭建從5個要素考慮：快速部署與更新、團隊約定、快速配置、頁面性能、構建性能。
    alloy team 基於以上幾點要素開發了 steamerjs。即裝即用的插件式機制方便項目快速搭建，只須要鍵入如下幾條命令就好啦：
    npm i -g steamerjs
  npm i -g steamer-plugin-kit
  npm i -g steamer-react
  steamer kit複製代碼
  • 組件化
    組件化推薦採用跨項目組件的開發方式，把通用組件發佈到公網 npm 或者 npm 私服，方便跨項目的組件複用。
    業內優秀的組件庫如 element。
  • 接口聯調
    推薦了一些工具和插件，postman,easy-mock.com,steamer-plugin-mock。

開發環境與生產環境銜接

  • 數據上報與錯誤監控
    主要採用一些成熟的市場方案。統計推薦百度統計 or 騰訊統計，性能監控推薦 wetest, 日誌監控推薦 sentry.io。
  • 持續集成
    開源項目可使用 github + travis-ci,私有項目可使用bitbucket + pipeline or github + pipeline。
    代碼規範推薦使用 IDE 提醒 + pre-Commit 檢查。
    測試環境部署
    • 多域名測試環境
      對於純Web站，不須要代理工具，測試便利。節省服務器。
    • 單域名多測試環境
      對於APP內嵌頁面，能夠方便測試。各測試環境獨立，互不干擾。

生產環境

生產部署推薦使用騰訊雲（此處有廣告硬植入，哈哈~）

第四場：Service Worker 主題分享

首先介紹了什麼是 Service Worker。
Service Worker 是瀏覽器後臺運行 JS 處理網絡請求和管理緩存相應的方法。Service Worker 提供了一個 Application Cache 的替代方案。

快速上手

最簡單的 Service Worker 樣例：

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('./sw.js')
 }

 // sw.js
 self.onfetch = (e) => {
    e.respondWith(new Response('Hello Service Worker!'))
 }複製代碼

基礎知識

  • 生命週期
    首次加載會經歷 Installing -> Active，出錯的話會進入 Error。
  • 更新機制
    Service Worker 更新會經歷 Installing -> Waiting -> Active，出錯的話一樣會進入 Error。

工程實踐

  • 兼容性

  • Service Worker 的 URL
    千萬不要打版本號！！！正確的作法是保持 SW URL 不變，且與主頁在同一域名下。

    xxx.com/xxx/sw.js複製代碼

  • Dev Tool
    在 Chrome 調試工具 network 選項中，Size 欄爲 from Service Worker就是啓用了 Service Worker 加載的資源。

  • 自動構建
    業界比較成熟的是谷歌的 sw-precache。使用也很簡單，一行命令搞定：

    sw-precache —config=sw-config.js
// sw-config.js
module.exports = {
  // 須要SW緩存的⽂文件，默認使⽤用緩存優先策略略
  staticFileGlobs: [
      'dist/cdn/**',
      'dist/webserver/**'
  ],
  // 前綴替換
  stripPrefixMulti: {
      'dist/cdn/': '//path/to/your/cdn/',
      'dist/webserver/': '//path/to/your/webserver'
  },
  // 輸出路路徑
  swFile: '/dist/webserver/sw.js',
  // 動態內容的緩存策略略
  runtimeCaching: [{
      // 對於全部url中帶有 '/api/' 的請求，優先⽹網絡請求，若離線，則使⽤用以前的緩存
      urlPattern: /\/api\//,
      handler: 'networkFirst'
  }]
};複製代碼

固然 sw-precache 也有一些缺陷，好比沒有集成的 Runtime，不支持外部 CDN 資源。
考慮到這些缺陷，基於 sw-precache 作了一些改進解決這些缺點，命名爲 create-sw。

  • 業務接入
    手機QQ-附近-顏值配對模塊使用了該方案。約爲 80% 的的安卓用戶，由於安卓手機 QQ 內置騰訊瀏覽器採用 X5 內核，Service Worker API 支持率達到了 91%。採用 Service Worker 的有效率約爲 50%。

爲何須要 Service Worker

  • 資源換成
  • 加載速度比 304 更快
  • 離線能力
  • 徹底的緩存控制能力
  • 漸進式加強，無痛遷移

最後還提到了 PWA 實踐，有興趣能夠詳細瞭解。

第五場：Javascript 與機器學習

首先簡單描述了人工智能的大背景，人工智能時代背景下每一個人都須要瞭解或學習人工智能。以後推薦了一個前端深度學習庫 deeplearn.js。

分享目標

  • 掌握機器學習基本概念
    機器學習是生成算法的算法。人工神經網絡是目前最流行的機器學習方法，神經網絡由大量的人工神經元聯結進行計算。
  • 掌握神經網絡分類器
    主要從線性分類、異或分類和數據分類幾個方面講述，而且現場運行了數據分類的 Demo。

  • 掌握兩種神經網絡訓練方法
    • 遺傳算法變異神經網絡
    • 反向傳播矯正神經網絡
  • 掌握遺傳算法+神經網絡的案例
    以 flappyBird 爲例。經過隨機生成一批種羣 -> 執行設定的關卡程序 -> 待種羣所有陣亡按照分數高地排序取前20% -> 對選出的20%以及由他們變異出的80%的種羣進行下一輪關卡程序。
    繼續第二步執行關卡程序直到關卡測試終止。
  • 掌握反向傳播算法
    反向傳播是「偏差反向傳播」的簡稱，是一種與最優化方法（如梯度降低法）結合使用的，用來訓練人工神經網絡的常見方法。該方法計算對網絡中全部權重計算損失函數的梯度。這個梯度會反饋給最優化方法，用來更新權值以最小化損失函數。反向傳播要求有對每一個輸入值想獲得的已知輸出，來計算損失函數梯度。所以，它一般被認爲是一種監督式學習方法。
  • 掌握手寫數字識別案例
    經過機器學習提升手寫文字識別率。

總結

  • 任何可使用 JS 寫的，都會有 JS 寫。
  • webgl 用來訓練神經網絡是不錯的選擇
  • AI 技能和數據庫編程，網絡編程同樣會成爲通用技能
  • 量子計算沒法遍歷全部神經網絡權重樹，仍是須要研究算法
  • 機器學習在基礎物理沒有突破以前沒法獲得質的突破
  • 毀滅人類的必定是人類或者天然災害，而不是人工智能

第六場：高效 H5 動畫設計與性能優化

分享主要以興趣部落送禮頁面的實踐爲例，分如下幾個話題講述：

經常使用動畫方案

  • GIF
    缺點明顯
    • 是一張圖片資源
    • 最多 256 種顏色
    • 支持全透明，不支持半透明
    • 不適用於」真彩色」-RGB
    • 動畫質量遇資源體積成正比
  • APNG
    缺點明顯
    • 也是一張圖片資源
    • 非官方承認
    • 第一幀是 PNG，後續是拓展塊
    • 支持度低
  • Video
    是一種不錯的方案，不過帶寬問題須要考慮。
    • 設置autoplay 屬性自動播放
    • 設置 loop 屬性控制循環
    • 視頻長度很重要（12s-30s）
    • 帶寬是個問題
  • SVG
    • 矢量無失真
    • 難以呈現複雜位圖效果
    • 複雜動畫具備渲染問題
  • Canvas
    推薦，也是業界主流的方式。
    • 可編程畫布
    • 2D Context API
    • 單個 Dom 元素，無狀態
    • WebGL
  • JS
    • 使用 JS 控制 DOM、CSS
    • 自身維護時間流和動畫速度
  • CSS3
    • 過渡動畫（transition）
    • 關鍵幀動畫（keyframes）
    • 渲染引擎會使用跳幀保證動畫的流暢性
    • 渲染引擎會中止或下降不可見元素動畫的刷新頻率


這麼多方案選哪種好呢？性能說話！可使用 FPS 工具 stats.js 進行性能分析。

移動端屏幕適配

移動端的屏幕適配分爲如下幾種場景闡述：

  • 背景
    • 背景爲純色或漸變色，直接鋪滿
    • 背景爲單張大圖，設置爲 cover
    • 背景爲可重複性紋理，直接 repeat 就好
  • 主體
    • 主體區域默認 iphone6 基準尺寸
    • 基於主體區定位的元素
    • 默認屏幕居中縮放
    • 採用 rem 保持頁面完整性及好的用戶體驗
      如何界定主體區域？
  • 邊緣元素
    • 音樂圖片、操做指引等主體無關元素
    • 處於屏幕固定位置，基於屏幕定位

性能監控遇優化

需考慮內存消耗和幀率，推薦工具 stats.js 和 Chrome developTool。

  • 使用 GPU 硬件加速

    • 避免頻繁重繪和重排
    • 避免 width 和 height，使用 transform:scale(x)
    • 避免 margin、top / left，使⽤用 transform: translate(x, y)
    • 元素建立後，⽴當即設置 transform: translateZ(0) 或 translate3d(0,0,0)
    • 元素會使⽤用獨⽴立的 layer 參與渲染

  • 圖片壓縮

  • 性能問題
    性能的監控使用以前推薦的 stats.js 就好。分析發現 translate 的表現明顯優於 background。
    測試過程當中發現動畫有鋸齒，卡頓明顯，有多是圖片太大致使的。

  • 性能調試 timeline
    鋸齒是如何產生的呢？

    • FPS 下降時，GPU 罷工
    • 大圖 -> 丟幀
    • 大圖燒顯卡

  • 幀動畫圖片性能
    幀動畫到底用不用合圖？建議不要合圖使用 HTTP2.0 便可。合圖以後的雪碧圖會有空白區域，一個動畫大概 40 - 50 幀的圖片，單張圖片要 500 500 px,合併圖後達到 4000px 3000px。

  • 幀動畫優化方案 - zip 壓縮包

    • 資源打包，減小請求數
    • 避免單個⼤大圖渲染瓶頸
    • 前端解壓使用jszip stuk.github.io/jszip/
    • jszip解析出ArrayBuffer，base64 ? Blob
    • URL.createObjectURL(blob)
      使用zip 動畫資源 CDN 部署，max-age和前端緩存加速。

  • 幀動畫優化方案 - indexedDB

  • 硬件加速 will-change

    • 提早通知瀏覽器元素哪些屬性會發生動畫
    • 瀏覽器預優化
    • 不能過多濫用

  • 兼容性問題 CSS3 動畫控制

    • 使用 setTimeout 的 CSS3 動畫結束後回調偏差大
    • CSS3 Animation提供了動畫事件 animationStart & animationEnd
    • 部分機器不支持
    • 降級使用JavaScript實現精準控制

  • 兼容性問題 FPS 控制

    • setTimeout/setInterval。執行時不許確
    • 使用 requestAnimationFrame
    • 與瀏覽器刷新頻率保持一致
    • IOS 所有支持，Android 支持率約 89%

  • 限制幀率 RAF
    通常建議保證 60 FPS 的幀率。若是不限制幀率的時候，使用 RAF 自由發揮，但須要注意資源包體積。

  • 兼容性問題 canvas Retina適配
    250px 250px 的原圖到 500px 500px 的畫布上發現變模糊了，緣由是設備像素比 window.devicePixelRatio 致使的。能夠畫在 500px * 500px 的 Canvas 上再 scale(0.5)。

性能評分

致使性能問題的緣由多是機器性能低，內存緊張，幀率低。
性能評分的原理是頁面建立必定數量的DOM，並添加 transform 和 opacity 變化。根據幀率衡量機器性能。

  • 性能評分方法
    首先在頁面建立 200 個正方形 DIV 元素。
    每一個 DIV 寬度和高度均爲 100px，DIV 初始位置的中心點與頁面的中心點重合。
    設置時間 t1 和 t2，在每一幀週期內對頁面中每一個 DIV 進行隨機位移、縮放和透明度變換。
    開始時間 t1，結束時間 t2，幀數爲 n
    fps = 1000 * n/t
    取幀率的10倍爲性能評分
    ``` score = floor( 10000 * n / t)
    分級
  • 提升性能措施
    • 減小幀數（圖片數）
    • 減小裝飾及動畫複雜度
    • 取消特效
    • 使用 @1x 圖片

自動化與可配置性

產品頻繁新增/更換禮物，若是每次更換都修改代碼無疑是不可取的。所以須要把動畫效果改成可配置，定義統一配置文件，動畫資源由 packageID 惟一標識，禮物配置與動畫資源分離。

  • 「常規操做」
    • 禮物 「面板」 懶加載
    • 禮物 「配置」 預加載
    • 禮物面板 「圖片」 預加載
    • 面板呼起時送禮 「動畫資源」 預加載
    • 送禮 「動畫資源」 緩存 indexDB

課程資源

github.com/Caesor/AC-H…

第七場：在 ES7 時代下的異步處理機制

Javascript 語言的執行環境是單線程的。若是一個任務耗時很長，就會阻塞後面的任務，致使頁面無響應。因而，Javascript 將任務的執行模式分爲同步和異步。

原生 Javascript 解決異步的方式

  • 回調函數
    回調函數優勢和缺點都很明顯。
    優勢是簡單、容易理解和部署。
    缺點是不利於代碼的閱讀和維護、高度耦合、流程混亂，並且每一個任務只能指定一個回調函數。
  • 事件監聽
    與回調不一樣。添加事件監聽，在異步函數觸發監聽事件處理邏輯。
  • 發佈/訂閱
    發佈/訂閱與「事件監聽」，相似，但優於後者。能夠監控程序運行，而且實現多任務綁定。

經過 jQuery 解決異步方式

經過jQuery when方法一樣能夠實現相似於 Promise 對象的功能。而且經過 when 可使得多個異步並行請求，而後獲取返回值進行回調處理
經過 done 或者 then 兩種方式進行回調。

經過 Promise 解決異步方式

promise的功能是能夠將複雜的異步處理輕鬆地進行模式化。
接着簡單介紹了 promise 的 API，就再也不詳細講述了：

  • then(onResolve, onReject)
  • catch(onReject)
  • resolve(callback)
  • reject(callback)
  • all(Array)
  • race(Array)

同步調用和異步調用同時存在致使的混亂

Promise只能進行異步調用方式。
理論上，在promise.then 執行的時候promise對象已是肯定狀態，從程序上說對回調函數進行同步調用也是行得通的。
Promise也會以異步的方式調用該回調函數，這是在Promise設計上的規定方針。
當需求變得複雜後，多層嵌套和鏈式調用，也讓代碼看起來不那麼優雅。

ES7下異步處理的終極解決方案

經過 async/await 解決異步方式有如下幾個有優勢：

  • 簡約而乾淨
  • 同、異步混合錯誤處理
  • 條件判別
  • 輕鬆獲取中間值
  • 錯誤堆棧信息
  • 調試便捷


async/await 基本規則：

  • async表示這是一個async函數,await只能用在這個函數裏面。
  • await 表示在這裏等待promise返回結果了，再繼續執行。
  • await 後面跟着的應該是一個promise對象。
  • await等待的雖然是promise對象，但沒必要寫.then()，直接能夠獲得返回值。

以後是下午甜點：

第八場：ES2017時代的後函數式編程

首先以一個 Demo 爲例判斷是否爲函數式編程。

function f(h){
    return h + 1;
}
var x = 3;
f(x + 1);複製代碼

理解函數式編程意味着：

  • 有能力閱讀開源代碼
  • 開拓新的思惟方式
  • 編寫整齊有序的代碼

經過點擊計數任務不一樣的寫法來說述函數式編程的特色。代碼傳送門：

什麼是函數式編程

函數式編程是種編程範式，它將電腦運算視爲函數的計算，關注純邏輯與數學運算。

函數式編程特色

  • 聲明式與命令式
  • 流式，更適合人的閱讀

函數式編程基石 —— 純函數

純函數只有邏輯運算和數學運算，同一個輸入總獲得同一個輸出。純函數的優勢是可緩存、可測試、可並行(web worker)，可進行惰性計算。

  • 變量緩存
    var memoize = function(f) {
var cache = {};
return function() {
  var arg_str = JSON.stringify(arguments); 
  cache[arg_str] = cache[arg_str] || f.apply(f, arguments);
  return cache[arg_str];
};
};複製代碼
  • 反作用
    • 往數據庫插入記錄
    • 發送一個 http 請求
    • 可變數據
    • 打印/log
    • 獲取用戶輸入
    • DOM 查詢
    • 訪問系統狀態等
      這些函數執行並不能老是返回相同的結果，能夠經過延遲執行避免產生。

函數的變換和操做

  • 柯里化
    經過柯里化將低階函數轉換爲高階函數，能夠形象地比喻成吃豆豆的過程。
  • Compose
    從右至左依次執行。
    let f = x => x + 1;
let g = x => x * 2;
g(f(1))
compose(g, f)(1)複製代碼
  • Functor
    functor 是實現了 map 函數並遵照一些特定規則的容器類。經過調用 Container.of 把東西裝進容器中隔絕外部影響，經過 Map 來接觸、操做窗口內的值，得到包含新值的容器。
    var Container = function(x) {
  this._value = x;
}
Container.of = function(x) {
  return new Container(x);
}
Container.of(3)
// => Container(3)
Container.prototype.map = function(f){
  return Container.of(f(this._value))
}
Container.of('flamethrowers').map(function(s) {
  return s.toUpperCase()
}
// => Container('FLAMETHROWERS')複製代碼
  • Monad
    實現了 chain 的 Functor。
    chain( flatMap )
    使用Map執行後（可能會加容器/卷）剝離一次容器/卷，不會產生新的卷。

流式特色

上個函數輸出是下個函數函數輸入。
流式框架有 xtream 和 RxJS。

實戰

  • Redux Middleware 源碼
  • CycleJS 代碼解讀

最後附上參考資料

第九場：如何把本身構建成大型互聯網公司須要的前端人才

老教授首先拋出一個經典問題，「若是你是一個大學畢業生，你會選擇大型互聯網公司仍是創業公司？」。
這個問題歷來沒有標準的答案，而且現場的回答者就很堅決的選擇小公司，而老教授的建議是選擇大公司。

大公司有什麼好？

  • 豐富的學習資源
  • 活躍的技術交流氛圍
  • 專一作前端深刻研究
    合格面試官須要具有完整前端知識體系，抓住重點辨別人才。
    關於前端校招的考察內容能夠查看老教授的這篇文章《前端校招面試該考察什麼？》

社招與校招的區別

校招面試流程

前端基礎

  • HTML
    • 經常使用的 meta 頭
    • 語義化
    • HTML5 新增功能
    • HTML 渲染解析知識
  • CSS
    • 可讀規範的 CSS 代碼
    • 盒模型
    • CSS3 特性：動畫、彈性佈局等
  • JS
    • 事件模型
    • 閉包和內存泄漏
    • 原型鏈
    • 渲染樹、重排重繪、分層渲染等（進階）
  • HTTP
    • 常見 HTTP 狀態碼
    • 不一樣請求類型的區別
    • 如何緩存
    • HTTP2
  • 調試
    • 如何抓包
    • 如何 debug 程序問題
    • 如何作移動端調試
    • 如何發現頁面問題
  • 移動 Web 開發
    • 移動 Web 開發和 PC Web開發的區別
    • 響應式佈局
    • 移動端的手勢和事件
    • 怎麼提升移動頁面的渲染性能

以及一些綜合知識考察，好比：用戶從輸入 url 到最終頁面展現，這個過程當中發生了什麼？老闆反饋頁面打開白屏，而你手機是正常的，怎麼辦？頁面卡頓，怎麼優化？

校招前端專業知識是考察重點嗎？

若是你連前端基礎知識都沒掌握好，我怎麼相信你是熱愛前端的學習者？

項目經歷

一個字，懟！找出項目經歷的關鍵詞，而後由淺入深，一直問到答不上來爲止。暗中觀察團隊協做意識、攻克難題決心、搜索資料能力等。

大學階段該作什麼積累？

  • 補齊學好前端基礎
  • 跟進新技術，嘗試新語言
  • 實踐項目中吃透用到的技術項

怎麼用大公司標準要求本身、提高本身？

  • 技術準備
    • 補齊基礎知識
    • 單點深挖
      大公司推崇一專多長
      大學的時候以廣度爲主，拓展視野；
工做以後以深度爲主，單點深挖；
當達到瓶頸後，再次向廣度拓展，打通知識。
                  ————百度某總監複製代碼
    • 以技術項目練兵
      從業務優化出發，以好玩有趣爲主，挖掘技術項目。
    • 寫文、分享
  • 思想準備
    • 溝通能力
      用溝通代替自做主張
      多作反饋，主動反饋
      有風險及時拋出
    • 正式資源不足
      「若是什麼都準備好了，誰都能作，那要你幹嗎？」
    • 問題到我爲止
    • 培養高效工做方法

跳槽社招

  • 基礎知識
    基礎知識相比社招有更高的要求。

  • 項目經驗
    項目經驗需對比騰訊的高級前端工程師要求。

最後，樂觀自信和技術能力同樣重要！

到這裏本次 AC 大會的現場實錄就更新完了，一成天 9 場的技術分享加圓桌討論，議題也是從項目搭建、優化、監控到編程思想、前沿科技以及職業發展涵蓋各個方面，真的是幹到不能再幹的大會了。一天很短，內容很長，但願對你們有所幫助，將來幾天慢慢消化，接下來也能夠多多交流。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程