「系統程序員」的技能棧有哪些？

01-11

看到余鋒自我介紹裡面經常寫自己是一個「系統程序員」，不知道具體應該如何定義一個「系統程序員」，技能棧包括哪些？
淺薄_caoz的夢囈

但遇到一些更加複雜的技術場景，我就顯得辦法不多，束手無策，後來遇到超級強悍的淘寶資料庫專家余峰，和人家一對比，我才意識到自己的對系統的理解，對資料庫執行機理底層的邏輯，對cpu執行邏輯和硬體io邏輯，完全是茫然無知的境界。前段時間和前淘寶大學校長子柳老師聊天還提到他，我們共同承認，這傢伙的系統理解力如庖丁解牛一般嫻熟，達到這個境界，看所謂的負載問題，架構問題，優化問題，就非常透徹和清晰，解決具體場景中的問題，也會有更明晰的思路和邏輯。

最重要的是有所為有所不為。

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

-- Bjarne Stroustrup

我寫代碼，要讓應屆生也能輕易讀懂並 follow，這樣我就可以放心地把活交給他們去做，自己把關就好了。

說俗一點，代碼要「耐操」。哪怕是新人來改，也不容易改壞。功能方面可以用單元測試和回歸測試來把關，防止改壞。有些正確性（比如線程安全）不容易用單元測試來驗證，那麼可以用 loadtest，更重要的是採用一個明確的大家都能理解的線程模型，這樣很容易識別出破壞線程安全的改動。

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
-- Tony Hoare

就怕代碼寫得 tricky 且 subtle，用盡了畢生智慧，非常 fragile，自己幾個月之後都看不懂，別人更無法維護了。我以前接手維護過某個 C++ library，我都能猜出作者在寫它的時候讀過哪本書，就怕遇到這種學一點新技術就想方設法用到工作中的人。

謝腰，System Programming 沒有一個公認的定義。我覺得 Bjarne Stroustrup 在 Lang.NEXT 2014 上的一個定義（Panel: Systems Programming in 2014 and Beyond）雖不見得精確，但是最有可操作性：

如果你的項目碰到了計算機硬體的限制，或者項目的其中一部分碰到了這些限制，你就進入系統編程的問題領域了。

Wikipedia 上把系統編程定義為系統最底層直接操作硬體的部分，或者說，寫硬體 driver, which is useless.

舉個容易理解的例子：你自己用紅黑樹實現了個 std::map, 這不是系統編程範疇。但是你如果要開始考慮你的實現可能有很糟糕的 cache 命中率，你開始根據真實應用場景設計 benchmark, 然後發現原來做個準確的 benchmark 是這麼難，那你就要開始進入系統編程的問題範疇了。

要了解系統程序員的技能棧，有個簡單的方法，去看 OSDI 和 SOSP 兩個系統頂會，看這些人都在研究什麼問題，可以把 abstract 掃一遍, 嘗試去理解他們關心的問題到底是個毛線，為什麼這個問題重要，如果裡面有你特別感興趣的問題，看文章，至少把 introduction 和 related work 看了，把裡面指出的重要文獻加入 read later 並且真的 read later.

MIT 的 Computer System Engineering 課程作為 index 挺好。計算機架構，操作系統，網路這些基礎課程當然重要，但可能更重要的是真的去做點東西，這樣你會碰到真正的系統問題。培養對數據的敏感性，系統問題基本都是各種 trade-off, 「知道」只是很粗淺的一步，分析能力才是關鍵。操作系統是一門可以展現很多取捨智慧的課，有很多的 open questions （然後你就可以看 SOSP 和 OSDI 上的人的腦洞了），但是很多地方都快被教成 Linux（某版本）源碼解析了，MIT 這個課還好。

看標題我馬上想到的是 brendon greg

他提到的技能棧有很多，他自己的網站上也有很多相關

不過我覺得最重要的是二進位調試的能力，所謂系統程序員，Brendon Greg應該有參照意義

只需要一個：「腦中模擬」

反正不是拿著 design patterns 當寶貝的那種吧

計算機科班知識從來沒過時過、只是很多崗位不需要這麼豐滿的知識庫。

人家強是干出來的、沒幹過活，那幾本書還只是書。

我的理解

1. 懂編譯系統

2.熟悉CPU體系結構

3.熟悉操作系統：操作系統的各個組件（各種驅動，文件系統，內存管理，調度，網路棧等）

4.熟悉各種系統調用或庫的介面等

無論是開始設計還是後期遇到問題，能從系統角度分析思考，(晶元→)硬體→多層軟體…識別痛點，得到最終的方案…

合格的系統工程師不是一朝一夕能達成的，除了有各層的知識，還得有多年實戰的磨練

也許在20世紀70，80年代，『系統程序員』指從事unix相關開發的程序員；特指那些實現unix操作系統的人或者對unix機制很熟的人。技能，就是微處理器手冊，操作系統和網路協議。開發出玩具操作系統的人不少，最終在商業上成功的，大概沒有吧。

『系統快遞員』，『系統搬磚員』，本質都是一樣的。

以上。

我覺得應該包括但不僅限於操作系統原理，網路協議，體系結構。

系統內核(文件系統，任務調度，內存分配，緩存處理，特定音頻視頻驅動，GPU驅動)，TCP/IP協議棧，系統環境/網路編程，這是最基礎的