2018 年掘金 AMA 年度總結：16 位技術大牛他們的技術事

時間 2019-11-08

標籤 ama 年度總結技術他們简体版

原文原文鏈接

寫在前面

趁着社區的年度徵文活動👉【🏆 掘金年度徵文 | 2018 與個人技術之路】，加上我司翻譯計劃大佬 LeviDing 出了【2018 年「掘金翻譯計劃」年度總結：咱們共同的成長故事】不才的沸點運營也來湊個熱鬧總結下沸點#AMA#話題的那些事吧。~~別問我爲何不總結沸點，沸點太多不才無從下手~~css

在正式開始以前，仍是簡單說下 AMA 是什麼？前端

AMA 是什麼？

掘金 AMA（ask me anything) 是掘金沸點的一個話題，掘金團隊會邀請一位技術大牛經過「你問我答」的形式回答你的問題，讓你們在技術、工做、生活方面有所成長。java

* Tips：本人不喜歡太過官方 or 正式的文字，本篇文章比較口語化，見諒(≧▽≦)node

本文目錄python

目錄mysql

2018 年 16 期 AMA

本文會從每期 AMA 會選一個高贊或極有價值問題，僅供技術交流。jquery

Vol 1：掘金 AMA - 聽閒魚客戶端架構師宗心談 Flutter 和他的團隊

旁白：第一期 AMA，也是我我的最喜歡的 AMA 之一，宗心的海報真的讓人感到開心。git

本期優質問題：你怎樣看待最近 Airbnb 和 Udacity 都相繼放棄了 RN ？-- 來自@zyf在掘金

請問，閒魚 App 中有哪些地方使用 RN，你怎樣看待最近 Airbnb 和 Udacity 都相繼放棄了 RN ？程序員

宗心回覆github

閒魚 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 回覆

從技術方面，圍繞着快速高效的解決問題來說：
1. 熟練掌握性能優化手段，包括卡頓，FPS，CPU，佈局優化，內存優化等。
2. 架構能力，熟練掌握 MVP，MVVM，組件化，並可以針對業務場景實施合適的架構方案。
3. 開發組件上，要熟練掌握經常使用組件的原理及擴展方式，好比圖片加載庫，RxJava，OkHttp 等，在團隊碰到經常使用組件的問題上可以給與解決思路或方案。
4. 掌握系統原理，好比安裝包結構，打包安裝過程，插件原理等。
從軟技能上，要培營養享溝通表達能力，這些能力對傳播知識和方法論，培訓新生力量，提升整個團隊的戰鬥力有很大的幫助。

本期 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 與論文，其實不少都很是有趣。

以上。