寫在前面
趁著社群的年度徵文活動?【? 掘金年度徵文 | 2018 與我的技術之路】，加上我司翻譯計劃大佬 LeviDing 出了【2018 年「掘金翻譯計劃」年度總結：我們共同的成長故事】 不才的沸點運營也來湊個熱鬧總結下沸點#AMA#話題 的那些事吧。別問我為什麼不總結沸點，沸點太多不才無從下手
在正式開始之前，還是簡單說下 AMA 是什麼？
AMA 是什麼？
掘金 AMA（ask me anything) 是掘金沸點的一個話題，掘金團隊會邀請一位技術大牛通過「你問我答」的形式回答你的問題，讓大家在技術、工作、生活方面有所成長。
* Tips：本人不喜歡太過官方 or 正式的文字，本篇文章比較口語化，見諒(≧▽≦)
本文目錄
目錄
- 寫在前面
- AMA 是什麼？
- 2018 年 16 期 AMA
- Vol 1：掘金 AMA - 聽閒魚客戶端架構師宗心談 Flutter 和他的團隊
- Vol 2：掘金 AMA - 聽騰訊 NOW 直播技術團隊 Leader Randzhu 談 Android 開發和團隊構建那些事
- Vol 3：掘金 AMA：聽分散式架構 SOFA 的開源負責人黃挺聊分散式架構和開源
- Vol 4：掘金 AMA：聽掘金小冊《Redis 深度歷險》、《深入理解 RPC》的作者 -- 老錢談技術輸出、沉澱那些事
- Vol 5：掘金 AMA：聽 Node.js Core Collaborator 之一 死月聊 Node.js && 技術寫書
- Vol 6：掘金 AMA：聽開源活躍貢獻者 + 程式設計師秀恩愛偽專家 -- phodal 和你聊如何平衡寫作、工作、生活
- Vol 7：掘金 AMA：聽 Vue.js 作者--尤雨溪談 Vue.js & 獨立開發 & 設計那些事
- Vol 8：掘金 AMA：聽知乎專欄《V8 引擎》、LibrarySniffer 作者 -- justjavac 和你聊 V8 & 技術學習之法
- Vol 9：掘金 AMA：聽有贊前端負責人 -- 施德來聊如何走上技術管理崗 & 團隊管理那些事
- Vol 10：掘金 AMA：聽阿里 Node 基礎框架 EggJS 的核心開發者--天豬講 EggJS 和 Node 那些事
- Vol 11：掘金 AMA：《開發者必備的 Docker 實踐指南》小冊作者--有明聊 Docker
- Vol 12：掘金 AMA：前端 + 區塊鏈的跨界者--CSS魔法聊前端和區塊鏈 DApp
- Vol 13：掘金 AMA：聽天貓營銷平臺前端-- ?耗子講非科班的他是如何走上程式設計路 & 招聘那些事
- Vol 14：掘金 AMA：聽螞蟻金服 OceanBase 團隊的技術專家-- 慶濤聊資料庫那些事
- Vol 15：掘金 AMA：聽前端娛樂圈的老人 & Facebook 實習生 -- 黃玄說他的前端 & 美國故事
- Vol 16：掘金 AMA：聽螞蟻金服 mPaaS 團隊技術專家--凝睇講客戶端推送 & 997 那些事
- 2019 年的 AMA
2018 年 16 期 AMA
本文會從每期 AMA 會選一個高贊或極有價值問題，僅供技術交流。
Vol 1：掘金 AMA - 聽閒魚客戶端架構師宗心談 Flutter 和他的團隊
旁白：第一期 AMA，也是我個人最喜歡的 AMA 之一，宗心的海報真的讓人感到開心。
本期優質問題：你怎樣看待最近 Airbnb 和 Udacity 都相繼放棄了 RN ？-- 來自@zyf在掘金
請問，閒魚 App 中有哪些地方使用 RN，你怎樣看待最近 Airbnb 和 Udacity 都相繼放棄了 RN ？
宗心回覆
閒魚 app 裡沒有使用 RN，但有不少頁面使用 Weex，在我看來，不管是 Weex 還是 RN，我們去看成本：
- 前端體系的學習成本
- debug和相容性的成本
- 基礎設施建設的成本
這三個成本是逃不過的，所以如果覺得這三個成本大於你的收益，建議不要用。而對於閒魚來說
- 我團隊有專門的weex專家帶一些有前端知識體系的同學
- 基礎設施有阿里巴巴集團的基礎設施做基礎，自己需要再建設的不多。
這兩個其實已經決定了我們在使用過程中成本沒有那麼高，目前最高的可能就是 debug 成本和相容性問題了，暫時是可以接受的。再說收益
- 我們有一套從sketch到程式碼的生成工具，所以UI還原部分，我們基於此少寫了很多程式碼
- 三端一致性，在部分業務上確實帶來了好處，尤其閒魚要在外部多端進行投放，不管是手淘還是外部投放，我就寫一份程式碼，相比來說成本肯定要低一些，所以這個要看場景
- 作為前端使用，效能上比h5還是會好很多，前端使用過程中也有一些收益。 均衡來看，我們還是在對應的場景下會持續使用下去。
本期 AMA 小故事
AMA 進行回答的第一天，宗心去了醫院，所以第一天的問題下的回覆都是在醫院裡誕生的。?延伸下：接觸下來優秀的人對事態度都特別認真。
Vol 2：掘金 AMA - 聽騰訊 NOW 直播技術團隊 Leader Randzhu 談 Android 開發和團隊構建那些事
旁白：這期和上一期的嘉賓都是一顆香菜安利給我的，感謝香菜，以及 Rand 是一個非常 Nice 的人--詳見小故事。
本期優質問題：作為一位資深的 Android 開發者，請問您覺得哪些技能點是比較重要的？--來自@Snailer
作為一位資深的 Android 開發者，請問您覺得哪些技能點是比較重要的？
Rand 回覆
- 從技術方面，圍繞著快速高效的解決問題來講：
- 熟練掌握效能優化手段，包括卡頓，FPS，CPU，佈局優化，記憶體優化等。
- 架構能力，熟練掌握 MVP，MVVM，元件化，並能夠針對業務場景實施合適的架構方案。
- 開發元件上，要熟練掌握常用元件的原理及擴充套件方式，比如圖片載入庫，RxJava，OkHttp 等，在團隊碰到常用元件的問題上能夠給與解決思路或方案。
- 掌握系統原理，比如安裝包結構，打包安裝過程，外掛原理等。
- 從軟技能上，要培養分享溝通表達能力，這些能力對傳播知識和方法論，培訓新生力量，提高整個團隊的戰鬥力有很大的幫助。
本期 AMA 小故事
Rand 的海報個人照被設計小姐姐否了 N+ 次，最後用了現拍的照片，?是不是程式設計師自拍水平普遍上來說都不大好呢？
Vol 3：掘金 AMA：聽分散式架構 SOFA 的開源負責人黃挺聊分散式架構和開源
旁白：個人很喜歡這期嘉賓的海報，個人照帶著一絲萌。
分散式的線上程式碼更新和服務重啟有什麼好的方法麼？ -- 來自@wking
分散式的線上程式碼更新和服務重啟有什麼好的方法麼？
黃挺回覆
分散式的架構下，應用的程式碼更新發布上線的確沒有單體應用的架構下來得這麼容易。目前業界也有比較多的釋出方案可以借鑑，比如藍綠髮布，灰度釋出，金絲雀釋出等等，來保證程式碼的更新在分散式的環境下可以做到充分的驗證。
關於服務重啟這個問題，可以從兩個方面去看，一個是服務如何做到平滑的關閉，一個是服務如何做到平滑的啟動。
關於平滑的關閉，一般上的做法是先從服務註冊中心裡面把對應的節點拿掉，等一段時間上游系統收到的地址列表裡不再有對應的節點，並且對應的節點已經沒有請求在處理了，那麼就可以開始關閉了。
關於應用的平滑的上線，首先應用在啟動完成之後，最好先做一遍自檢，檢查應用自己是否當前是健康的，健康了之後，再對外提供服務，這個過程一般上被稱為 Readiness Check，目前 SOFABoot 中也提供了這個能力：www.sofastack.tech/sofa-boot/d…
除了 Readiness Check 之外，因為 Java 的 JIT 的問題，一個應用剛剛啟動的時候，往往效能相對比較差，這個時候，就要做服務的預熱，在 SOFARPC 中，也提供了服務預熱的能力：www.sofastack.tech/sofa-rpc/do…
本期 AMA 小故事
在螞蟻金服分散式架構 SOFA 技術沙龍見過黃老師，運營妹紙和他對話說道：我還沒吃飯的時候，黃老師開啟了無視模式進入到了下一個話題，?是不是程式設計師都不大會關心人呢？
Vol 4：掘金 AMA：聽掘金小冊《Redis 深度歷險》、《深入理解 RPC》的作者 -- 老錢談技術輸出、沉澱那些事
旁白：第一期沒有嘉賓個人照上海報，老錢說不大好意思，我：？？？行吧。
有哪些高效工作和高效學習的祕訣？--來自@蔣海博
老錢，您好，既然您有孩子，請問如何平衡陪伴孩子和工作的時間？我看您又工作又寫出，應該很忙吧。還有是否能分享下如何高效工作和高效學習的祕訣。謝謝。
老錢回覆
我在掌閱的工作本身不是太忙，至少近期時間上還有不少閒魚。所以我才會有時間來做一些技術寫作的事。白天家裡有老人幫我看孩子，每天下班回家，孩子睡得也早。到了週末，我總會花一些時間帶著孩子去逛商場，這也就是平時最主要的親子活動了。我本人比較宅，社交活動很少，所以剩下的時間就可以專心做自己喜歡的事，如果一個人整天到處跑，除了沒時間之外，估計心態也會比較浮躁。
市面上所有的程式設計書籍都有一個規律，那就是越基礎的書越多，越高階的書越少。隨著自己知識的漸長，市面上的書籍大多已經不能滿足我的需要，所以平時的學習知識來源還是主要靠網路分享、靠原始碼、靠 google、靠 stackoverflow。除非是對某個新的領域感興趣，我會買一些基礎的書來了解入門。工作上當我做一件事的時候，我會非常專心地去做，我會帶著耳機希望自己不被打擾，安靜的狀態平和的心境就會帶來效率的提升。
本期 AMA 小故事
正如之前說的，優秀的人對事的態度極為認真，你可以從老錢的 AMA 回覆感受到。
Vol 5：掘金 AMA：聽 Node.js Core Collaborator 之一 死月聊 Node.js && 技術寫書
旁白：死月是我一個前端同事超迷的一位開發。
node 未來的方向？ --來自@wujunze
你好 node未來的方向 和 它真正能擅長的場景是哪些 ？
死月回覆
Web 領域應該會繼續守住，但也不會去撼動誰誰誰的地位，各有所長，在大家的熟練度、效能以及研發效率之間找一個平衡。相似的還有就是遊戲類的伺服器，但是競品太多了，而且還沒完成一個太集中和完善的生態，老大哥柚子感覺已經好久沒人維護了。
在渲染方面會有優勢。因為這一層比較輕薄，上 Java 就顯得厚重了。
一些 Serverless 引擎以及類似場景可能會有天然的優勢。例如 leancloud 在你做各種事情的時候可以寫一些 JavaScript 原始碼作為補充邏輯，自己解釋自己的開發成本通常比你在 Java 層面搞個解析器或者上 V8 之類的研發成本會低一些，而且效能也不錯。
IoT 方面也是一個不錯的選擇，不過我還在觀望。
其它方面就是客戶端的東西，例如 Electron，NW.js 等，的確會降低客戶端軟體的開發門檻以及研發效率，畢竟樣式什麼的直接上 HTML + CSS 了，這個方法比較好，以前就有人這麼用了，以前就是 qt 也用了類似的方法。我一直期待會有一個內建 Node.js 的無線終端引擎，而不是 React Native 之類的，也許是因為相較於他們現在的引擎 Node.js 還比較笨重吧。
包括 Cocos2d 之類的也一樣，不知道為什麼就是不基於 Node.js，可能是那邊的開發者不在一個領域，大家都不 care 裡面有什麼，生態裡面能做什麼，只要是能寫 JavaScript 就夠了。
最近在寫一個桌面的 2D 遊戲引擎的 Node.js 玩具 Wrapper，就想驗證一下自己的想法，Node.js 也可以寫遊戲，而不只能是基於別的執行時的 JavaScript。
Wrapper 在 GitHub 的私有倉庫。而 github.com/XadillaX/no… 這個是更小的一個倉庫，用於驗證通過 Node.js C++ 擴充套件能搞這麼一個 Wrapper 的正確性的小 Demo。
未來如果真有這麼一個引擎了，我感覺開發遊戲起來會更方便吧，不過這只是我的個人業餘愛好而已。
本期 AMA 小故事
死月對於海報只有文字版和真人上鏡無卡通形象版本很執念，最後我問他要照片無果，他勸說我上卡通版失敗，文字版海報上線…
Vol 6：掘金 AMA：聽開源活躍貢獻者 + 程式設計師秀恩愛偽專家 -- phodal 和你聊如何平衡寫作、工作、生活
旁白：這期嘉賓是一個簡介都在秀恩愛的人。
下一個會被棄用的框架會是哪個？ -- 來自@長大之後我就成了你
前陣子 github 棄用了 jquery，我想問下你覺得下一個會被棄用的框架會是哪個？
phodal 回覆
要預測下一個被棄用的框架很難。但是像 GitHub 這種棄用，不代表 jQuery 被棄用。GitHub 是一個面向開發者的網站，他們對於瀏覽器的相容性要求沒有那麼高，可以輕鬆使用各種新的 HTML 5 API。並且對於那些不是單頁面應用的前端專案來說，jQuery 實現上更能滿足他們的需求——修改下顏色，做做動畫。jQuery 可以用在非 SPA 應用上，基本上很難被完全棄用。
而現有前端應用的變革——新的框架都替換了舊的框架，多數是在開發 SPA 應用上。從這個角度來看，就會發現過去的 SPA 框架，如 Backbone、Mustache 都處於一個被棄用的階段上。
本期 AMA 小故事
請當 phodal 當嘉賓的時候原想讓大家學習下撩妹和戀愛之道，萬萬沒想到，他也是個以買買買為最終手段的人?
Vol 7：掘金 AMA：聽 Vue.js 作者--尤雨溪談 Vue.js & 獨立開發 & 設計那些事
旁白：我男神❤️。
正確的參與開源專案的姿勢是什麼呢？--來自@DateBro
我是一名大二學生，想問一下尤大，計算機領域的內容那麼多，前端，後端，移動開發，機器學習。。。您是如何在確立好興趣方向後做出個人發展的規劃的呢？正確的參與開源專案的姿勢是什麼呢？?
尤雨溪回覆
我的路線可能對你參考價值一般，因為我是學藝術和設計出身，所以很自然的首先接觸了和使用者打交道的前端，最感興趣的也是前端。對你自己來說，感興趣，有熱情是最重要的。是做出令人愉悅的互動讓你更有成就感呢，還是提升演算法準確度，增加轉化率資料呢，又或者是設計出一個吞吐量巨大的後端系統呢？只有找到最能給你帶來成就感的那個方向，才最有可能做出成就，也最值得去鑽研。
至於參與開源，這是一個比較大的話題，所以只能概括地說說。
首先，要避免以一種商家／使用者的關係去看待開源，而是以一種共同利益去思考，也就是把自己放在維護者的角度去想，什麼樣的貢獻對於這個專案是有益的。
其次，報 bug 的時候，一定要留意專案對 bug 的格式要求。很多開發者有個不好的習慣就是報 bug 的時候把錯誤堆疊甚至是截圖一丟就算是報 bug 了，但維護者修 bug 需要了解 bug 產生的根本原因，沒有一個真正的重現，很多資訊根本不可能猜得到。而來回詢問需要浪費非常多的時間，對於大專案來說，每天都會有十幾個 issue，維護者是沒有這麼多精力一個一個去來回詢問的。
最後，關於貢獻程式碼。遇到舉手之勞的錯誤，直接開 PR 會更好，但如果要做較大的改動，則應該注意先和維護者溝通，並且一定要說清楚自己的場景、用例，為什麼需要做這樣的改動，為什麼需要這樣的功能。有些時候，一些開發者覺得我辛辛苦苦貢獻了一個 PR 你居然不要，覺得不爽，這樣的情況一般都是缺乏溝通導致的。
本期 AMA 小故事
AMA 為期三天，第一天的時候已經有 100+ 個問題，為了方便尤大回復我對問題進行分類整理文了文件給他，最後他還是自己把所有問題篩選了回答了部分問題，?尤大真的很 Nice，對事超認真。
Vol 8：掘金 AMA：聽知乎專欄《V8 引擎》、LibrarySniffer 作者 -- justjavac 和你聊 V8 & 技術學習之法
旁白：jjc 大大認識挺久了，大家對他的爭議挺大，但個人覺得 jjc 大大還是有技術傍身可以來交流一番的。
如何閱讀有些枯燥的技術書籍？--來自@人民幣玩家
閱讀一些逐漸深入的書籍，如何有效處理長篇大論枯燥難尋。
justjavac 回覆
停下來，思考一下，玩會遊戲，然後繼續。給自己定個目標，一次讀 20-30 分鐘，硬著頭皮讀，然後思考 10 分鐘。我用這種方式，花了3個月的時間並行讀完了愛因斯坦的《相對論》和 Harari 的《人類簡史》，然後整理了 200 多頁的筆記和草稿。
也有一部分原因是生活和工作壓力太多了，讓很多人有了焦慮感。當讀書讀不進去時，就增增加了自己的挫敗感，最終形成的惡性迴圈。尤其是隨著年齡的增加，接受新事物新觀念新知識也變得越來越難。
我上大學時，從圖書館借了 2 本 Martin Fowler 的《重構》，一本英文原版，一本中文翻譯版。兩本書對照著看，大概用了不到一個月的時間吧，就把英文版讀完了。
工作後，就只能利用每天的早起時間讀書了。再後來我和老婆定了一個家庭讀書日，每月選出一個週末，這天一起看書 4 個小時以上。如果再加上選書、佈置環境、營造氛圍什麼的，基本上得耗費一天的時間。
閱讀是一種習慣，堅持下來就行
再補充一句，其實儀式感也很重要，突然就覺得讀書變得很神聖了
再再補充一句，找個女朋友，一起學習更有動力
本期 AMA 小故事
海報做出來的時候感覺 jjc 大大太黑，問他要不要美白下，他說原本如此。?真是個實誠的 boy
Vol 9：掘金 AMA：聽有贊前端負責人 -- 施德來聊如何走上技術管理崗 & 團隊管理那些事
旁白：線下大會見過德來師兄，是一個非常有範的人。
如何走上技術管理崗位？ --來自@liutao
「因為走管理線路的緣故，我現在極少參與 Coding。我是工作了四五年後想清楚自己的發展方向的」請問可以分享一下這塊的的思考嗎？
施德來回復
我對自己的技術還是蠻自信的，好歹科班出身，浙大計算機學院畢業：），但我發現如果做純技術，我另外一部分的能力比較難發揮，有點浪費了。比如我有不錯的銷售能力、不錯的商業思維、我能很好地把一個東西用人話歸納清楚、能寫讓人耐心讀下去的文章無論是不是技術的、很能發現問題（無論是不是技術類的，也無論是不是前端範疇）、比較有領導特質，等等吧，自吹自擂結束，至少我自己是這麼想的吧，所以就朝這個方向做了。
本期 AMA 小故事
邀請德來師兄的時候被拒絕了很多次，最後和他說可以順便招人?成功
Vol 10：掘金 AMA：聽阿里 Node 基礎框架 EggJS 的核心開發者--天豬講 EggJS 和 Node 那些事
旁白：天豬一直活在我的朋友圈（認識個妹紙經常提及他的 Nice 點），當邀請當嘉賓卻不是找人搭線認識的，具體過程見小故事。
點評下 nest，說說您或者 egg 團隊對他的看法？--來自@鯨吃瓜
請問天豬大哥能否簡單的點評下 nest，說說您或者 egg 團隊對他的看法，以及他的優缺點?
天豬回覆
nest 是近年來新出的一個框架，比較亮眼的是 TypeScript 和從 Spring 過來的一些概念。
從我們的角度來看，企業級應用有很多要素，包括程式設計模型約束、擴充套件點、多程式管理、日誌、安全、RPC 等等非常多的方面，TypeScript 靜態型別帶來的好處，是其中的一小點，但並不是全部。裝飾器等特性，目前還在 Stage 階段，並沒有落地到 Node LTS 版本中。在我們看來，靜態型別帶來的好處，還不如把單元測試覆蓋率做上去更實際。
TypeScript 也並不是某個框架獨有的，就像螞蟻鳳蝶團隊就有在用 TS 開發 Egg 應用（聽說他們做了個 tegg 框架，後面也許會放出來）。
順便重提下框架對比，從我們的角度看來，框架有三層：
- 基礎框架：Express，Koa
- 框架的框架：Egg
- 上層業務框架：tegg，chair，sofa-node，ThinkJS，Sails，Loopback，Nest
它們的定位：
- 微框架專注於底層中介軟體模型，是 Node HTTP 之上很薄的一層。
- 上層業務框架，是針對某個領域和業務場景定製的業務框架，針對團隊自身的業務場景和技術選型下的組合。（當然也有一些大教堂式的大而全框架）
- 上層業務框架一般每個團隊都會封裝一個，就像當年阿里各大 BU 那樣，而 Egg 就定位介於前面兩者之間，抽象出上層框架的一些共性 -- 一套載入規範，一方面提供外掛能力來複用，一方面提供框架定製能力供團隊架構師定製自己的上層業務框架。
本期 AMA 小故事
天豬是第一個我在 GitHub 找郵箱聯絡上併成功成為 AMA 嘉賓的人?
Vol 11：掘金 AMA：《開發者必備的 Docker 實踐指南》小冊作者--有明聊 Docker
docker 並不能完全將資源隔離起來，如何保證安全性？--來自@buheshuicat
docker並不能完全將資源隔離起來，如何保證安全性？
有明回覆
Docker 的安全可以從幾個角度出發去考慮：
- 隔離安全，也就是依靠 Docker 實現隔離的 Namespace、CGroup 等機制實現安全隔離。
- 核心能力限制，即通過限制 Docker 容器及其中應用對核心敏感功能的使用，來達到防範風險的目的。
- 伺服器安全防護，這和普通的伺服器防護原則是一致的，也就是設立防火牆，使用證照保護，應用非 root 執行等方式來限制外部攻擊。
- 設立安全機制，通過像 AppArmor、SELinux 這樣的安全策略或安全軟體來增強核心本身的安全性。
本期 AMA 小故事
本期 AMA 是我見過最實在的一期，基本上都圍繞著 Docker 展開技術提問，如果你對 Docker 感興趣也可以去圍觀學習下?
Vol 12：掘金 AMA：前端 + 區塊鏈的跨界者--CSS魔法聊前端和區塊鏈 DApp
怎樣快速提高自己的 css 能力？--來自@zuishiguang
魔法哥，有什麼推薦的國外技術社群、論壇和部落格，在現在 js 框架橫行天下的今天，js邏輯寫的比較多，css 寫的較少，怎樣快速提高自己的 css 能力？
CSS魔法回覆
第一個問題：有什麼推薦的國外技術社群、論壇和部落格？
因精力有限，我現在基本不會直接閱讀國外網站了。不過我找到一些可訂閱的人工聚合的日報，我就坐享其成了。要相信這一點：好文章或重要的資訊肯定會來找你。
可訂閱的資訊源有：
- 眾成翻譯 zcfy.cc/
- 部落格週報 github.com/qiwihui/git…
- 前端日報 github.com/kujian/fron…
- 雲謙早報 github.com/sorrycc/zao…
第二個問題：在現在 JS 框架橫行天下的今天，JS 邏輯寫的比較多，CSS 寫的較少。怎樣快速提高自己的 CSS 能力？
為什麼現在是 JS 框架橫行天下，而不是 CSS 框架橫行天下？這在某種程度上說明 CSS 在現階段沒那麼重要。對於普通前端開發者來說，我建議順勢而為。除非你在大企業裡專職開發 Element UI 或 AntDesign，否則不建議投入大量時間只為提升 CSS 能力。（參見我在下面某個問題下的回覆。）
另外，我們得面對一個殘酷的現實：CSS 能力無法快速提高。因為 CSS 是一個網狀系統，所有概念都不是孤立存在的，無法單點突破，不像 JS 那樣學會一個 API 就可以用上一個 API。因此我們對 CSS 的掌控能力一定是一個從量變到質變的過程。想要突破那個臨界點，需要投入大量的精力和成本。而這個成本投入是否划算，是需要考量的。
本期 AMA 小故事
魔法哥這期海報做到了 2 點，期間魔法哥一直線上和我溝通海報，o.o 雖然最後勉強能用，但是具體到面部還是有些不自然。
Vol 13：掘金 AMA：聽天貓營銷平臺前端-- ?耗子講非科班的他是如何走上程式設計路 & 招聘那些事
旁白：一直潛水在耗子姐姐的「前端的那些破事」群裡，他是個非常活潑的人。沒想到他的經歷如此的不同，具體可以看看他的 AMA 自我介紹。
網管-印刷工-噴繪機修理工-前端，可以分享下如何走上程式設計這條路？ --來自@清蒸不是水煮
網管-印刷工-噴繪機修理工-前端，可以分享下如何走上程式設計這條路，以及程式設計上對你影響最大的人是誰嗎？
?耗子回覆
網管-印刷工-噴繪機修理工-前端，可以分享下如何走上程式設計這條路，以及程式設計上對你影響最大的人是誰嗎？
或許你會覺得我要發雞湯，但可能我發的會是毒雞湯。希望每個人看到我的回答後都能找到自己的成長之路。
我高中時學習不好，很長一段時間陷入到自暴自棄的狀態，也因此沒有拿到好的文憑，以至於找工作的時候處處碰壁。 很早的時候就對 web 開發興趣濃厚。從最早的個人主頁製作、QQ 空間特效程式碼、到之後的管理運營 BBS、部落格群。積累了一些前後端開發的知識。
我做得最對的事可能是逃離二三線城市，擠進北上廣吧。在技術領域內，只有一線和超一線城市，才會彙集最多的產業資源。包括公司、人才和技術。
我只能說趕上了一個前端高速發展的時代，受惠於行業帶來的紅利。但是，這樣的紅利期已經在迅速減弱，目前應屆生想去一家好公司的難度已經比從前門檻高太多。
過去十年時間，整個行業向瀏覽器應用、移動端轉型，產生的一些新興技術領域，企業對前端、Android、iOS 等工種需求強烈，但這些領域大家都缺少技術經驗，企業不得不降低招聘要求，有個笑話不是說某企業要招 10 年以上 iOS 工作經驗嘛。
目前對於上述提到的領域，同樣水漲船高，因為這些領域技術趨近於成熟，發展也在放緩，所以並不是前人走過的路後人可以復刻。
可見的未來，比較稀缺的技術工種一定是在人工智慧、大資料、虛擬/增強/混合現實、區塊鏈（不是炒幣，那只是很小的一塊）等領域。但也可以看出，學習門檻也越來越高。
對我影響最大的人，其實有很多。經歷的幾家公司的領導都非常有魅力，給過我很多指導。只要用心，每個人身上都會有你值得學習的地方。
綜上所述，總結幾點：
- 選擇好的城市比選擇學校和專業更重要
- 欠缺的知識一定要抽時間補上
- 不要等一個技術濫大街了再開始瞭解，那時候已經缺少稀缺性
- 要相信正態分佈和迴歸平均，幸運不是常態，不幸也不是常態。不是隻要奮鬥就一定有收穫，但不努力一定沒有收穫。
- 相信頂端優勢、馬太效應和 80/20定律，資源總是向頭部傾斜，並且強者越強
- 三人行心有我師，見賢思齊，見不賢而改之
本期 AMA 小故事
耗子姐姐的 AMA 本來是第八期上線的，後來咕咕了我，再後來雙十一，好在最後上線了?
Vol 14：掘金 AMA：聽螞蟻金服 OceanBase 團隊的技術專家-- 慶濤聊資料庫那些事
OB 是如何實現智慧運維？--來自@吃提子不吐葡萄籽
終於來了個運維大佬，我之前讀過你們的技術文章，某篇文章提到過智慧運維的概念，可以具體地講一講 OB 是如何實現智慧運維的嗎？
慶濤回覆
【智慧運維】是理想，可以無限接近。現實中更多體現為自動化運維，彼此自動化程度上不一樣。我這裡就說【自動化運維】方面的。
運維最基礎的功能就是監控和告警。OB 內部效能指標非常豐富（不比 Oracle 的效能指標少），這為運維提供了很豐富的素材（資訊）。告警的目的是提前發現異常，【異常】的定義取決於業務要求和運維人員經驗。以前是靠為監控指標定義範圍或者波動範圍去識別異常，近幾年可以通過機器學習去識別以查。 個人認為理論上不會有一個統一的標準能適應所有的業務，機器學習也是一門不確定性技術。所以【漏報】和【誤報】永遠是運維人員的痛。
資料庫告警問題如果是資源相關，有兩個處理思路，都可以自動化做。
一是優化 SQL，降低 SQL 對 CPU /記憶體的消耗。自動獲取 DB 執行的所有 SQL，並及時分析其執行計劃，應用 DBA 的經驗和相關執行時效能資料，程式自動初步判斷 SQL 是否有效能問題，並給出初步的索引優化建議，這個是 SQL 自動優化的方向。準確率不會太高，但是隻要高於絕大部分研發人員水平，在資料庫規模很大的公司內，這個是自動化診斷對研發和運維都是很有意義的。OB 的所有 SQL 都可以計入審計，有詳細的執行時效能資料。這是源材料。怎麼加工發揮就是運維產品的水平了。
二是資源擴容或遷移，提升資料庫享用的資源或者資料庫遷移到壓力很小的主機上。雲資料庫就是在資源管理方面做的比較好。RDS 的 mysql 和 sqlserver 都是這個思路。不過這個資料遷移是靠運維產品用資料庫自身的備份恢復技術去做（搭建級聯備庫，然後切換應用的資料庫連線等）。OB 在這方面做的自動化程度非常高。OB 是支援多租戶管理。資源有叢集和租戶兩個維度。租戶是提供給業務的例項。租戶資源不足就對租戶擴容，一個命令瞬間完成，前提是叢集資源有餘量；叢集資源不足就加機器，也是一個命令。擴容命令結束後會引起租戶以及內部Unit的負載均衡（詳情請關注 OB 微信公眾號，看歷史文章【負載均衡】）。均衡操作會有資料重分佈動作，都是OB內部非同步完成，不依賴外部運維產品，不用擔心資料不一致，不用擔心中間出現異常或可用性故障等。當然，決策是否擴容目前還是運維人員判斷的。原因也一樣，沒有一個統一的標準適合所有的業務場景，還是人把關比較靠譜。
【監控】-【告警】-【處理】-【反饋】。當形成閉環後，這個自動化的運維產品的價值就體現了。反饋就是能跟蹤 SQL 在【處理】之後的改進情況。這還是要依賴資料庫的效能指標和 SQL 的執行時資訊等。這個反饋也是對開發做的處理的正向反饋，讓他知道應用的效能狀況，優化狀況，知道哪裡做的好哪裡做的不好，資料庫開發設計方面的能力也得到提升。
本期 AMA 小故事
感覺好像大家對運維、資料庫方便並不是很感冒，這期的 AMA 有些冷清，?有些小難過對不起認真回答問題的慶濤。
Vol 15：掘金 AMA：聽前端娛樂圈的老人 & Facebook 實習生 -- 黃玄說他的前端 & 美國故事
旁白：本期有個美國故事小專題
有哪些計算機基礎知識讓你覺得在工作中依然能夠受益 --來自@2014_
有哪些計算機基礎知識讓你覺得在工作中依然能夠受益，希望能夠推薦幾本書
黃玄回覆
這是這次 AMA 裡我最喜歡的一道問題 ;)
關於「基礎」、「成長」、「深入」的問題很多同學都在問，我想直接在這個回答下面總結一下我自己的感想。
「在特定領域內工作與學習」可以被認為是一種 Top-down （從技術棧的應用層向更下）或者說 Just-in-time 的學習方式，很多非科班前端（或者任何覺得基礎不夠用的時候）的學習路徑可能都會是比如
- 「JS -> JS 中存在的程式語言特性與模式」
- 「JS Callback -> EventLoop -> 併發模型」
- 「JS -> Babal +| V8 -> 編譯原理、程式語言執行時/虛擬機器」
- 「React + Redux/Flux -> Immutability/FP」
- 「Flow/TS/ReasonML -> 型別系統」
- 「CSS -> 瀏覽器渲染引擎 -> 圖形學」
- 「Ajax -> HTTP -> TCP/QUIC -> 計算機網路」
- 「實時通訊 -> Web Socket -> Socket」
- 「寫 UI -> 寫更好的 UI -> UX（使用者體驗）」 這樣的路徑。這種方式是不可缺少並且在很多時候更加快速實用得，但這種方式可能會由於對「共性更強的基礎知識」的欠缺比較容易出現「覺得永遠都在跟進新東西」的感覺，並且缺乏「創新」所需要的視野。
我在「如何取捨一些技術」裡提過：無論使用的是什麼技術，往根上走必然會走到一個更高的抽象層面，這個時候所有「變化的表象」就 merge 成了「更不變的基礎」。（這裡請想象一顆樹，根是最 generic/abstract 的基礎（你也可以理解成基類或者型別理論裡的 Top type，比如 OO 語言中的 Object），越往葉子節點是越 specific/derived 的技術（你可以理解為派生類）
而「CS 基礎的學習」相比之下則更像一種 Bottom-up（以技術棧比喻）或者說 Ahead-of-time 的學習方式，你可以從一種「更高層次抽象」的方式去理解新技術，並且更容易「子型別化」出新的東西。
React 從架構上來說，其實是越來越接近一個程式語言虛擬機器的，而從設計模式來說，是越來越接近 Haskell/OCaml 這樣的函數語言程式設計語言。這些都不是「原有的前端領域內知識」可能自然演化出來的。 這也從另一個側面回答了為什麼中國很多技術團隊創新能力不如國際團隊，即使只限定在前端框架領域，大部分在技術模型上有突破性的框架也都來自國際團隊：Knockout/Rx 來自微軟，React 來自 FB，Angular 來自 Google…
所以很多同學問的如何「基礎」和「前端有什麼深入的方向」也都可以從這個角度來回答，比如說我相對了解比較多的「程式語言」領域，「哪一門語言對前端未來發展或是學習上有很大幫助」？
從 JavaScript 來說，JavaScript 是一門比較雜交的語言，其發明與發展過程一直到目前為止也主要是「借鑑」其他語言的特性。這些特性通常在「原有的上下文」下有著更好的表達，另外大部分這些特性技術（OOP、FP、型別、執行時）本身的或學術或業界的發展也都是貢獻在這些語言而非 JS。所以說「基礎」可以是「學習 JS 發明與發展中過往或正在借鑑的語言」，「深入」可以是「瞭解這些語言的發展、瞭解 TC 39 的動向、瞭解未來可能影響 JS 去向的語言、影響或貢獻 JS 語言的發展」等。 舉例來說：
- Scheme 作為 JS 的最主要本源之一，學習 scheme 或類似的 Lisp 方言會讓你對 lambda 運算元、first-class function、CPS、closure 這些函數語言程式設計概念有更純粹的理解，並對這些概念在 JS 中的運用有更本質的理解。
- Java/python 或類似的 class-based OO 語言會讓你對 ES6 以及未來 ES 的 class、field、property、（private、static）有幫助；
- Java/OCaml/Haskell...等任何一門強型別語言會讓你理解「型別有什麼作用」、「型別安全是什麼」對 TypeScript/Flow/Reason 的各種概念和設計有同樣幫助；（比如讓你更容易理解 subtying、variance、只讀只寫的關係等）
- Rust/Swift/Kotlin/OCaml/Haskell 等嘗試用某種靜態分析機制約束異常（比如 option type 或 checked exception）、非同步（比如 Promise、async/await）等「效果」的程式語言能讓你對 JS 的未來、或是 React 這樣的框架 API 設計有幫助；
- Rust/C++ 能讓你對一切跟指標和記憶體有關的概念有無可替代的幫助；
- 學習任何一種與 JS Event Loop 不同的併發（或更好的支援可能的並行）模型的語言會讓你對「同步非同步」、執行緒程式、阻塞非阻塞有超過「能理解他們的字面意思和比喻」的理解…對 Web Worker、Sharedworker、sharedbuffer 這些 Web API 有幫助；
- 學習 assembly、JVM bytecode、stack machine 會對 web assembly 有幫助；
- 學習任何一門編譯到 JS 的語言都會讓你對 JS 「有什麼缺陷」這件事有幫助； ……
在「你是如何在前端領域下沉澱下來的？學習心得是什麼？」說過得這裡就不重複了，前端的複合性體現在他對眾多電腦科學（和其他學科）領域都有依賴，而不是說「層展現象」就完全替代電腦科學的基礎作用了……
我自身讀過的書並不足以推薦太多書籍，但是參考美國大學的課程教材（也就是那些知名大學教授編寫的經典書籍）絕對足矣。比如 程式語言相關的 SICP、TAPL、PAPL、Software Foundation、虎書、龍書… 計算機網路的 Top-down approach 體系結構的 CSAPP ……
這些教材都是「大部頭」，相比於大多「行業內的工具書」要嚴肅嚴謹得多，並且有大量「習題」，可以說能啃下來任何一本的任何一個章節都會有一種「被重新整理」的感覺。 除了書籍之外，如果希望對某個領域有非常理論化或前沿、試驗性的瞭解，可以嘗試觀看、閱讀學術會議與期刊的 presentation 與論文，其實很多都非常有趣。
以上。
本期 AMA 小故事
小故事挺多的，AMA 文中也說了，另外個小故事就是，這期 AMA 的圖片我很努力的摳最後還是一個不及格，被黃同學微博 diss 了，攤手?
Vol 16：掘金 AMA：聽螞蟻金服 mPaaS 團隊技術專家--凝睇講客戶端推送 & 997 那些事
旁白：嚴格意義上，這是 19 年的 AMA，但是隻有這一期沒上本文怪冷清的…本期有個 997 小專題
關於客戶端網路層的優化，有哪幾個地方可以切入？ --來自@J_Knight_
您好，請問一下關於客戶端網路層的優化，有哪幾個地方可以切入？而且在監控網路效能方面有哪些實踐可以分享一下嘛？
凝睇回覆
幾個方向可以先搞起來，首先是用長連結代替短連結，增加連結的複用率，減少每次請求的時間，然後資料的序列化方式可以用 PB，再則進一步可以自定義傳送協議，本地 dns (通過一定的策略下發 ip 列表)減少 dns 解析耗時和報錯，更細的可一些動態建聯策略，併發建連，1rtt 這種
監控方面，主要還是靠客戶端埋點日誌，上傳到伺服器上做大資料分析
本期 AMA 小故事
凝睇的技術非常的厲害，見【開篇 | mPaaS 服務端核心元件體系概述】 卻沒能和大家進行非常好的技術交流，有些小難過，當然已經反思出解決方案了?怪對不住凝睇的。
2019 年的 AMA
??，19 年的 AMA 暫時排期到了 4 月份，大家如果有啥想清蒸邀請來做客的可以和我說。
- vol 17: 《React 狀態管理與同構實戰》作者--LucasHC （01.22 - 01.24）
- vol 18: SOFA 團隊專家 （01.29 - 01.31）
- vol 19：奇舞團--月影（02.26 - 02.28）
- vol 20：《Android 開發藝術探索》作者--任玉剛（03.12 - 03.14）
- vol 21: Omi 框架作者--當耐特（03.26 - 03.28）
- vol 22：《Android 進階》系列三部曲作者--劉望舒（04.09 - 04.11）
希望 2019 年大家多多在 AMA 下和嘉賓進行技術交流 ^O^/