《程序員進階攻略》學習筆記（上）
這裏有一份簡潔的前端知識體系等待你查收，看看吧，會有驚喜哦~若是以爲不錯，麻煩star哈~前端
前言
知識分爲兩種，一種是技能性知識，一種是關於路徑選擇和自我認知的知識。git
技能性知識須要你在平常的學習和工做中勤學苦練，練成以後你就會成爲某一類問題的 「解答題高手」。程序員
而關於路徑選擇和自我認知的知識，它能讓你在成長的不一樣階段從新認識本身，由於 「知」 從而改變你的 「行」。有時選擇對了合適的路，比光顧着趕路要重要得多。github
本文是關於程序員的成長路徑，它會圍繞程序這個行業、程序員這個職業，畫出一條清晰的成長路徑，並解答這條路徑上可能面臨的各類問題與困惑。算法
這條成長路徑，或許是長這樣子：數據庫
這是一條成長線的表意圖，有兩個部分：圖上左側的路徑，是匹配不一樣成長階段，對應不一樣職業角色；右側是一條由不一樣成長階段組成的成長線。編程
「啓程之初」，是你剛踏上程序之路面臨的一些問題和感悟。設計模式
「程序之術」，是你工做早期的主要內容，以修煉編程技能爲主。數組
除了編程寫代碼，還有不少其餘的內容，這是另一個維度的修行之路，也即 「由術入道」。緩存
工做數年，成長到必定階段，你可能會面臨一個成長平臺期的困擾，在此就進入了 「道中彷徨」 的徘徊期。
這些困擾和彷徨不少都關乎選擇，這期間是你發出 「路在何方」 之問的尋路期。
最後，你堅決了道路，繼續前行，前面的路上還有一道 「斷層」，突破以後你將會蛻變，最終 「破繭成蝶」。
本系列文章爲程序員提供了可供參考的路標，一言以蔽之：「走在一樣的路上，碰見本身的風景。」
關於本系列文章，是整理自極客時間《程序員進階攻略》，節選了我認爲最有價值的內容，更詳細的版本請看這裏。固然，若是你喜歡這個課程，請購買正版。
征途：啓程之初
技術方向的選擇
選擇語言
選擇那些展示出蓬勃生命力的語言。
美國做家納西姆·塔勒布（《黑天鵝》《反脆弱》等書做者）曾說：信息或者想法的預期壽命，和它的現有壽命成正比。
而編程語言以及由它編寫的全部軟件系統和程序，本質就是信息了。換句話說就是，若是你想預測一門語言還會存在多久，就看看它已經存在了多久。存活時間足夠長的語言，能夠預期，它將來也還可能存活這麼長時間。固然這一論斷並不絕對，但它更多想說明越是新的語言或技術，升級換代越快，也越容易被取代。
選擇回報
選擇技術方向，選擇語言，本質都是一種投資。
越年輕的語言和方向，風險越高。一個今年剛出現的新方向、新語言，你怎麼知道它能在明年倖存下來？
因此，考慮肯定性的回報和更低的風險，你應該選擇有必定歷史的方向或語言，也許不能帶來超額的回報，但最起碼能帶來穩定的回報，讓你先在這個行業裏立穩腳跟。在此基礎上，再去關注新潮流、新方向或新技術，觀察它們的可持續性。
在選擇技術方向時，你還要看看當前的市場需求是什麼，最須要什麼，以及長期須要什麼。
好比，今天技術的熱潮在人工智能、機器學習、區塊鏈等上面，這是市場最須要的，而市場給的價格也是最高的。因此，你應該投入這裏麼？先別頭腦發熱，看看本身的基礎，可否翻越門檻，及時上得了車嗎？
世紀之初，互聯網時代的到臨，網絡的爆發，你會寫個 HTML 就能月薪上萬。上萬，彷佛很少，但那時北京房價均價也才 5000 多啊。2010 年左右，移動互聯網興起，一年移動開發經驗者的平均待遇達到了五到十年 Java 開發的水平。現在，你只會 HTML 基本找不到工做，你有五年移動開發經驗和有五年 Java 開發經驗的同窗，薪資待遇也變得相差很少了。
關於技術，有一句流行的話：「技術老是短時間被高估，但長期被低估。」今天，在人工智能領域得到超額回報的頂級專家，實際數十年前在其被低估時就進入了這個領域，數十年的持續投入，纔在現在迎來了人工智能的 「牛市」 ，有了所謂的超額回報。
因此，不妨投入到一些可能在長期被低估的基礎技術上，而不是被技術潮流的短時間波動所左右。
技術的選擇，都是賺取長期回報，短時間的波動放在長期來看終將被抵消掉，成爲時代的一朵小浪花。
選擇行業
選語言，就是選職業，而選職業首先選行業。
先想一想本身想從事哪一個行業的軟件開發；而後，再看看：這個行業的現狀如何？行業的平均增速如何？和其餘行業相好比何？這個行業裏最好的公司相比行業平均增速又如何？最後，再看看這些最好的公司都用些什麼樣的技術棧和語言。若是你想進入這樣的公司，那就很簡單了，就選擇學這樣的技術和語言。
這裏要區分職業跟興趣的關係！
職業可不是爲了發展什麼業餘愛好，而是爲了得到安身立命的本領，得到競爭的相對優點。而興趣，就是這件事裏有些吸引你的東西，讓你覺這是 「很好玩」 的事。但有個一般的說法是：「一旦把興趣變成了職業也就失去了興趣。」由於，職業裏面還有不少 「很差玩」 的事。
興趣能輕鬆驅動你作到前 50%，但按二八原則，要進入前 20%的高手領域，僅僅靠興趣就不夠了。興趣給你的獎勵是 「好玩」，但繼續往前走就會遇到不少 「很差玩」 的事，這是一種前進的障礙，這時功利，也算是給予你越過障礙所經歷痛苦的補償吧。
有時這樣的選擇確實很難，由於咱們缺少足夠的信息來作出最優選擇。赫伯特·西蒙說：「當你沒法得到決策所需的全部信息時，不要追求最優決策，而要追求滿意決策。」
定下本身的滿意標準，找到一個符合滿意標準的折中方案，就開始行動吧，停留在原地糾結，什麼也不會改變。
技能地圖
在程序的技能地圖中，包含兩個維度：
- 掌握
- 瞭解
紅色區域相對更小而聚焦，是須要掌握的部分，要求深度；藍色區域的部分更廣而泛，須要廣度。
十多年後，這張圖上的每個分類都出現了新的技術迭代，有了新的框架、算法和產品等，但它們並不過期，依然能夠爲你的技能點亮之路提供方向指引。也許，你程序生涯的第一個一萬小時你就會花在這張圖上了。
下面逐一介紹下：
掌握
開發平臺
開發平臺，它包括一種編程語言、附帶的平臺生態及相關的技術。
在現在這個專業化分工愈來愈細的時代，開發平臺決定了你會成爲何類型和方向的程序員。好比：服務端、客戶端或前端開發等。其中進一步細分客戶端還能夠有 Windows、Mac、iOS 和 Android 等不一樣的平臺。
1、編程語言
語言的選擇基本決定了開發平臺的性質，但有些語言可能例外，如：C++、JS、C# 等，這些語言均可以跨多個平臺。
但即便你選的是這些語言，基本也會歸屬到某一類平臺上。比如你選了 C++，若是你去作了客戶端開發，就不多可能再去用 C++ 寫服務端程序了。
選擇了語言，咱們不只僅是熟悉語言自身的特性，還須要掌握支撐語言的平臺庫。Java 若僅從語言特性上來講，有其優勢，但其瑕疵和缺陷也一直被吐槽，要是沒有 JDK 強大的平臺庫支撐，想必也不會有今天的繁榮。
2、平臺生態
與語言平臺關聯的還有其技術生態以及各類技術框架的繁榮程度。
這些平臺技術生態的存在讓使用這門語言編程完成特定的任務變得容易和簡單得多。Java 的生命力除了 JDK 的強大支撐，實際還有其平臺生態的繁榮，也起了決定性的做用。
在選擇了開發平臺後，除了語言和平臺庫以外，其生態體系內主流的技術框架和解決方案也是必選的掌握內容。
經常使用算法
算法，表達的是一個計算的動態過程，它引入了一個度量標準：時空複雜度。
當我回思時，發現這個度量標準思惟在工做十餘年中一直在發揮做用。現在，幾乎全部的經典算法都能在開發平臺庫裏找到實現，不會再須要本身從頭寫。但結合工做實際的業務場景，咱們須要去設計更貼合需求的算法，而只要是算法它都受到時空複雜度的約束，而咱們只是在其中進行平衡與折衷。
數據結構
數據結構一般都和算法一塊兒出現，但算法表達的是動態特性，而數據結構表達的是一種靜態的結構特性。
大部分開發平臺庫都提供了最基礎和經常使用的數據結構實現，這些都是咱們須要熟悉並掌握的，包括：
- 數組 Array
- 鏈表 Linked List
- 隊列 Queues
- 堆棧 Stacks
- 散列 Hashes
- 集合 Sets
另外，還有兩種數據結構不屬於基礎結構，但在現實中有很是普遍的直接映射場景。
- 樹 Trees
- 圖 Graphs
每種結構都有各類變體，適用於不一樣的場景，甚至不少時候你還須要會組合不一樣的結構去解決一些更復雜的問題。
瞭解
須要瞭解的內容比須要掌握的更普遍，但瞭解了這些方面會讓你更高效地協做並解決問題。
數據存儲
無論你寫什麼樣的程序系統，估計都離不開數據存儲。數據是一個業務系統的核心價值所在，因此怎麼存儲不一樣類型的生產數據，是你必需要了解的。現在普遍流行的數據存儲系統有下面三類：
- SQL 關係型數據庫（如：MySQL、Oracle）
- NoSQL 非關係型數據庫（如：HBase、MongoDB）
- Cache 緩存（如：Redis、Memcached）
每一種數據存儲系統都有其特定的特性和應用場景。做爲程序員，咱們一般的需求就是最有效地用好各種數據存儲，那麼按了解的深度須要依次知道以下幾點：
- 如何用？在什麼場景下，用什麼數據存儲的什麼特性？
- 它們是如何工做的？
- 如何優化你的使用方式？
- 它們的量化指標，並可以進行量化分析？
這 4 點雖不要求一開始就能掌握到必定程度，但你最好一開始就有這個層次思惟，在往後的工做中不斷去迭代它的深度。
測試方法
爲何咱們作開發還須要瞭解測試？
測試思惟是一種與開發徹底不一樣的思惟模式。有一種流行的開發方法論叫 「測試驅動開發（TDD）」，它的流行不是沒有道理的。在寫代碼的時候，用測試的思惟與方式（提供單元測試）去審視和檢測代碼，也就是說明確要開發某個功能後，先思考如何對這個功能進行測試，並完成測試代碼的編寫，而後編寫相關的代碼知足這些測試用例。
開發與測試這兩種相反視角的切入維度，能真正長期地提升你寫代碼的效率和水平。
工程規範
每一種開發平臺和語言，估計都有其相應約定俗成的一些工程規範要求。最基礎的工程規範是代碼規範，包括兩個方面：
- 代碼結構
- 代碼風格
像 Java 這麼多年下來，逐漸造成了一種基於 Maven 的代碼組織結構規範，這種約定俗成的代碼結構規範省卻了不少不必的溝通。有時候，一樣的內容，有更規範的結構，其可閱讀性、理解性就能獲得提高。
而至於代碼風格，相對沒那麼標準化。但爲了寫出更清晰、易讀的代碼，咱們至少要堅持本身寫的代碼具備某種一致性的風格。
另外，除了風格問題，也能夠藉助靜態代碼檢查工具來規避一些新手愛犯的低級錯誤，而老手也能夠經過這些工具來找到本身的認知與習慣盲點。
開發流程
在開發流程方法論上，敏捷基本已經橫掃天下，因此咱們至少要了解下敏捷開發方法論。
雖然敏捷方法論定義了一些參考實踐，但它依然是一組很是鬆散的概念。每一個實踐敏捷的開發團隊，估計都會根據本身的理解和摸索創建一整套逐漸約定成型的開發流程規範。而爲了和團隊其餘成員更好地協做，估計每一個新加入團隊的成員都須要瞭解團隊演進造成的開發流程規範。
源碼管理
既然咱們生產代碼，天然也須要了解如何管理好代碼。
在個人從業經歷中，源碼管理工具經歷了從 CVS 到 SVN 再到 Git 的變遷。Git 誕生的背景是爲 Linux 這樣超大規模的開源項目準備的，天然決定了其能應對各類複雜場景的源碼管理需求。因此，你至少要了解 Git，並用好它。
當工具變得愈來愈強大時，工具背後的思想其實更重要，對其的理解決定了咱們應用工具的模式。而對源碼進行管理的最基本訴求有如下三點：
- 並行：以支持多特性，多人的並行開發
- 協做：以協調多人對同一份代碼的編寫
- 版本：以支持不一樣歷史的代碼版本切換
修煉：程序之術
架構與實現
把一種想法、一個需求變成代碼，這叫 「實現」，而在此以前，技術上有一個過程稱爲設計，設計中有個特別的階段叫 「架構」。
軟件架構，就是軟件系統的結構與行爲設計。而實現就是圍繞這種已定義的宏觀結構去開發程序的過程。
架構師的交付成果是一整套決策流，文檔僅僅是交付載體，並且僅僅是過程交付產物，最終的技術決策流實際體如今線上系統的運行結構中，而實現的最終交付物是程序代碼。
架構
從定義上，你已知道架構是一種結構設計，但它同時可能存在於不一樣的維度和層次上：
- 高維度：指系統、子系統或服務之間的切分與交互結構。
- 中維度：指系統、服務內部模塊的切分與交互結構。
- 低維度：指模塊組成的代碼結構、數據結構、庫表結構等。
在不一樣規模的團隊中，存在不一樣維度的架構師，但不論工做在哪一個維度的架構師，他們工做的共同點包括下面4個方面：
- 肯定邊界：劃定問題域、系統域的邊界。
- 切分協做：切分系統和服務，目的是創建分工與協做，並行以得到效率。
- 鏈接交互：在切分的各部分之間創建鏈接交互的原則和機制。
- 組裝整合：把切分的各部分按預期定義的規則和方法組裝整合爲一體，完成系統目標。
實現
實現通常會有6個方面的考慮：選型評估；程序設計；執行效率；穩定健壯；維護運維；集成部署。
我以交付一個功能需求爲例，講述下這個過程。
實現一個功能，可能所有本身徒手作，也可能選擇一些合適的庫或框架，再從中找到須要的API。
肯定了合適的選型後，須要從邏輯、控制與數據這三個方面進一步考慮程序設計：
- 邏輯，即功能的業務邏輯，反映了真實業務場景流程與分支，包含大量業務領域知識。
- 控制，即考慮業務邏輯的執行策略，哪些能夠並行執行，哪些能夠異步執行，哪些地方又必須同步等待結果並串行執行？
- 數據，包括數據結構、數據狀態變化和存取方式。
開始編碼實現時，你進一步要考慮代碼的執行效率，須要運行多長時間？要求的最大等待響應時間可否知足？
你還須要考慮系統的穩定健壯：併發吞吐能力如何？運行的穩定性和各類邊界條件、異常處理是否考慮到了？
還有維護運維的問題：上線後，出現 Bug，相關的監控、日誌可否幫助快速定位？是否有動態線上配置和變動能力，能夠快速修復一些問題？新上線版本時，你的程序是否考慮了兼容老版本的問題等？
最後你開發的代碼是以什麼形態交付？若是是提供一個程序庫，則須要考慮相關的依賴複雜度和使用便利性，以及將來的升級管理。若是是提供服務，就須要考慮服務調用的管理、服務使用的統計監控，以及相關的 SLA 服務保障承諾。
以上是整個實現過程的思惟框架。若是你每次寫代碼時，都能有一個完善的思惟框架，應該就能寫出更好的代碼。若是漏掉了其中某個部分，可能會以某種線上 Bug 或問題的形式返回。
關注點
架構的一個核心關注點： 熵。也就是系統的混亂程度。
系統只要是活躍的，「熵」值就會在生命週期中不斷波動。需求的增長和改變，就是在不斷增長「熵」值（系統的混亂程度）。但軟件系統的「熵」有個臨界值，當達到並超過臨界值後，軟件系統的生命也基本到頭了。
而黑線表示，實現中重構與優化的動做則是在不斷進行減「熵」，做出平衡，讓系統的「熵」值在安全的範圍內波動。
實現的核心關注點，是：簡。
簡，是簡單、簡潔、簡明、簡化，都是在作減法，但不是簡陋。關於實現的所有智慧都濃縮在了這一個字裏，它不只減小代碼量，也減小了開發時間，減小了測試時間，減小了潛在 Bug 的數量，甚至減小了將來的維護、理解與溝通成本。
架構關注複雜度的變化，天然就會帶來簡化，而實現則應當順着把「簡」作到極致。
斷裂帶
架構與實現之間，存在斷裂帶。
斷裂帶出如今架構執行過程之中，落在文檔上的架構決策其實是靜態的，但真正的架構執行過程倒是動態的。
形成架構和實現之間斷裂帶的緣由，主要有有：
- 溝通問題：如信息傳遞障礙。
- 水平問題：如技術能力不足。
- 態度問題：如偷懶走捷徑。 4.現實問題：如沒法變動的截止日期（Deadline）。
當系統規模足夠大了，架構師的關注點應該放在戰略性細節上。而其餘大量的實現細節，只要沒有越出頂層宏觀結構定義的邊界便可。
模式與框架
「設計模式」 是前人解決某類問題的總結，是一種解決問題域的優化路徑。
開發框架是可複用的設計組件，它統必定義了高層設計和接口，使得從框架構建應用程序變得很是容易。所以，框架能夠算是打開「快速開發」與「代碼複用」這兩扇門的鑰匙。
框架和模式的共同點在於，它們都提供了一種問題的重用解決方案。其中，框架是代碼複用，模式是設計複用。
軟件開發是一種知識與智力的活動，知識的積累很關鍵。框架採用了一種結構化的方式來對特定的編程領域進行了規範化，在框架中直接就會包含不少模式的應用、模式的設計概念、領域的優化實踐等，都被固化在了框架之中。框架是程序代碼，而模式是關於這些程序代碼的知識。
代碼與分類
編程，就是寫代碼，但代碼其實能夠分爲以下三類：
- 功能
- 控制
- 運維
若是你想提升編程水平，寫出優雅的代碼，那麼就必需要清晰地認識清楚這三類代碼。
功能
功能代碼，是實現需求的業務邏輯代碼，反映真實業務場景，包含大量領域知識。
要把功能代碼寫好，最難的不是編碼自己，而是搞清楚功能背後的需求並獲得正確的理解。以後的編碼活動，就僅是一個「翻譯」工做了：把需求「翻譯」爲代碼。
真正地理解並知足用戶的原始需求，這一步操做就很困難。這是由於從用戶內心想要的，到他最後獲得的之間有一條長長的鏈條，以下所示：
用戶心理訴求 -> 用戶表達需求 -> 產品定義需求 -> 開發實現 -> 測試驗證 -> 上線發佈 -> 用戶驗收
需求信息源自用戶的心裏，而後經過表達顯性地在這個鏈條上傳遞，最終固化成了代碼，以程序系統的形態反饋給了用戶。
但信息在這個鏈條中的每一個環節均可能會出現誤差與丟失，即便最終完成了系統開發、測試和發佈，也可能發現用戶的心理訴求要麼表達錯了，要麼被理解錯了。
用戶常常會把他們的須要，表達成對你的行爲的要求，也就是說不真正告訴你要什麼，而是告訴你要作什麼。因此你才須要對被要求開發的功能進行更深刻的思考，努力去理解業務及其背後用戶的真實需求，這是寫好功能代碼的基本能力。
程序存在的意義就在於實現功能，知足需求，但這僅僅是第一步。
控制
控制代碼，是控制業務功能邏輯代碼執行的代碼，即業務邏輯的執行策略。
編程領域熟悉的各種設計模式，都是在講關於控制代碼的邏輯。而現在，不少這些經常使用的設計模式基本都被各種開源框架固化了進去，程序員被解放出來專一寫好功能業務邏輯。
控制代碼，都是與業務功能邏輯不直接相關的，但它們和程序運行的性能、穩定性、可用性直接相關。提供一項服務，功能代碼知足了服務的功能需求，而控制代碼則保障了服務的穩定可靠。
有了控制和功能代碼，程序系統終於能正常且穩定可靠地運行了，但難保不出現異常，這時最後一類 「運維」 型代碼便要登場了。
運維
運維代碼，就是方便程序檢測、診斷和運行時處理的代碼。它們的存在，才讓系統具有了真正工業級的可運維性。
最多見的檢測診斷性代碼，應該就是日誌了，打日誌太過簡單，所以咱們一般也就疏於考慮。其實即便是打日誌也須要有意識的設計，評估到底應該輸出多少日誌，在什麼位置輸出日誌，以及輸出什麼級別的日誌。
在現實中，檢測診斷類代碼常常不是一開始就主動設計的。但生產環境上的程序系統可能會偶然出現異常或故障，而由於一開始缺少檢測診斷代碼輸出，因此很難找到真實的故障緣由。現實就這樣一步一步逼着你去找到真實緣由，因而檢測診斷代碼就這麼被一次又一次地追問爲何而逐漸完善起來了。
但若是一開始你就進行有意識地檢測診斷設計，後面就會獲得更優雅的實現。有一種編程模式：面向切面編程（AOP），經過早期的有意設計，能夠把至關範圍的檢測診斷代碼放入切面之中，和功能、控制代碼分離，保持優雅的邊界與距離。
而對於特定的編程語言平臺，好比 Java 平臺，有字節碼加強相關的技術，能夠徹底乾淨地把這類檢測診斷代碼和功能、控制代碼完全分離。
運維類代碼的另外一種類，是方便在運行時，對系統行爲進行改變的代碼。一般這一類代碼提供方便運維操做的 API 服務，甚至還會有專門針對運維提供的服務和應用，例如：備份與恢復數據、實時流量調度等。
功能、控制、運維，三類代碼，在現實的開發場景中優先級這樣依次排序。有時你可能僅僅完成了第一類功能代碼就迫於各類壓力上線發佈了，但你要在心裏謹記，少了後兩類代碼，未來都會是負債，甚至是災難。而一個知足工業級強度的程序系統，這三類代碼，一個也不能少。
而對三類代碼的設計和實現，越是優雅的程序，這三類代碼在程序實現中就越是能看出明顯的邊界。爲何須要邊界？由於，「碼以類聚，人以羣分」。功能代碼易變化，控制代碼固複雜，運維代碼偏繁瑣，這三類不一樣的代碼，不只特徵不一樣，並且編寫它們的人（程序員）也可能分屬不一樣羣組，有足夠的邊界與距離才能避免耦合與混亂。
而在程序這個理性世界中，優雅有時就是邊界與距離。
跨越斷層，突破邊界
在前文中定義過程序員的職場階梯，而階梯不過就是不少人已經走過的路，咱們只須要沿着這條路去持續成長就能爬上還算不低的樓層。只是到了必定樓層後咱們會發現上面彷佛還有幾層，但卻看不見下一層的樓梯了。由於再往上走的人就很少了，也就沒能成了路，天然也就看不見，這可能就是所謂成長階梯的斷層。
在程序員的成長階梯上，到了必定階段，咱們可能會面臨方向的選擇，不一樣的方向選擇意味着不一樣的路徑，會碰到不一樣的斷層，而跨越斷層也須要不一樣的方法。
那咱們會面臨怎樣的方向選擇呢?
方向
在個人技術成長路上，我看到了三個方向，正好能夠用三個字來表 達:「高」「精」「尖」。
「高」 指的是 「高級(High-grade)」，「精」 表明 「精確(Precision)」，而 「尖」 則是 「尖端(Advanced)」。這是我所看到的技術人前進的三個主要方向，而這 三個方向的走向每每仍是互斥的。
高級，說的不是更高級的技術，由於技術之間的橫向比較沒有高低級之分，好比操做系 統、數據庫、網絡編程、機器學習等技術，無法比出個高下。這裏的「高級」，如其英文 是更高等級的意思，是職位和人的級別。而往高等級走的技術人，離 「精」 天然只能越來 越遠，畢竟站的高就只能看得廣，但很難看得精確了。
精確，就是把一門技術作到真正的精通。如今技術的分工愈來愈細，一般能精通一兩個細 分領域已實屬不易。而要作到精，其實越日後付出越多，但感受提高卻變得愈來愈慢。都 到 95 分了，再日後每提高 1 分都須要付出艱辛的努力。走到細微深處，也很難再看得 遠、看得廣了。
尖端，彷佛聽起來像 「精」 的極致，其實否則，這徹底是另外一條路。「高」 與 「精」， 是工業界的實踐之路，而 「尖」 是理論界的突破之路。只有能推動人類科技進步的技術才 稱得上尖端，就如 IT 界歷史上著名的貝爾實驗室裏的科學家們作的工做。
「高」 是往宏觀走，「精」 是往微觀走，「尖」 是去突破邊界。
這三條路，「高」 和 「精」 的方向在業界更常見，而 「尖」 不是工業界常規的路，畢竟 業界擁有相似貝爾實驗室這樣機構的公司太罕見，因此 「尖」 的路線更多在學術界。於是 後面咱們主要探討 「高」 和 「精」 兩個方向的路徑斷層與跨越方法。
高
高的兩條典型路線以下:
- 程序員—架構師—技術領導者
- 程序員—技術主管—管理者
往高處走，每一次角色的轉變，都是斷層。有時候，公司裏到了必定級別的程序員就會被冠以架構師的稱呼，但工做的實質內容依然是資深程序員平時作的事，如:一些關鍵系統的設計和實現，解決一些困難的技術問題。
這些工做中的確有一部分也算是架構師的內容，但若是不能認識到架構師工做內容的實 質，再往高處走也就很難實現斷層的跨越了。而架構工做的實質是創造一個模型，來連 接、匹配關於業務、技術和團隊之間的關係。
其中的 「業務」 屬於架構師工做內容中的領域建模;「技術」 是匹配領域模型的技術實 現模型;「團隊」 是關於個體之間如何組合的結構，須要知足個體技術能力與技術實現模 型的匹配。由這三個元素鏈接和匹配構成的模型中，「業務」 是變化最頻繁的，其次是 「團隊」，而變化頻次最低的反卻是 「技術」。
每一項元素髮生變化，都意味着架構模型須要去適應這種變化，適應不了變化的模型就需 要升級。而常見的組織架構調整，也就意味着 「團隊」 的溝通路徑變化了，由於康威定律 (系統設計的通訊結構和設計系統的團隊組織的溝通結構是一致的)的緣故，必然帶來架 構模型的適應性變化調整。
透過具體的實質再往高處抽象到本質，你會發現架構工做的本質是在經過模型調優生產關係，從而提升生產效率和生產力。這是一條槓桿之路，經過找到其中的關鍵支點去放大輸出，擴大價值。
在架構模型三元素中，技術自己就是一種槓桿，而團隊和業務是價值支點。
曾經，技術的草莽時期，是一個英雄輩出的年代。兩我的能夠創造 Unix、C 語言，一我的 也能夠發明 Linux，也能夠寫出 Foxmail。掌握了技術，就可能創造歷史，那時技術的槓 杆很高。
現在，是技術的成熟時期，個體英雄少了，更可能是一種團隊和集團軍做戰的方式。若是你是技術的絕世高手(精的極致)，那你也須要找到一支契合你技能的場景與隊伍，加入進去。此時我的的技術槓桿也許不像曾經那麼高，但也許大家這個隊伍仍是有機會能創造歷史的。
前幾年，Facebook 曾收購了一家叫 WhatsApp 的公司，花了 190 億美圓。這家公司當 時僅 50 人，而其中一半是技術人員，這應該是近年用技術槓桿撬動價值之最了吧。
在 WhatsApp 這個例子中的價值支點是什麼?是產品(業務)，鏈接用戶、造成網絡。技 術自己的價值經過這個產品業務形態支點，在每一個活躍用戶身上獲得了放大。
而另外一個價值支點，是藉助團隊，但這隻適合高級別的技術人員，好比:技術管理者或架構師。但團隊也須要能創造真正的價值，才能實現利用槓桿放大價值的效果。在商業環境下，任何一種產品業務形態，其最終能實現價值，都會存在一個價值網絡。這個網絡中覆蓋了各類角色，技術只是其一，若要找到最好的價值支點，那麼一般會在離價值來源比較近的地方。
技術像是一根棍子，能發揮多大價值，取決於棍子自己的品質和運用的方式。而往高處走的技術人，要跨越這條路徑的斷層，就是要認識清楚這個價值網絡，並找到最適合技術發揮的價值點。
精
精的路線是一條 「專家」 之路。
曾經在前文《定義:階梯與級別》中定義過 「專家」，我說:專家可能就是某個領域中你 繞不過去的人吧。這個定義中包含兩個點，一個是領域，另外一個是繞不過去。第一點表達 了某個範圍，第二個則模糊地表達了這個範圍的大小，繞不過去實際上是一個很大的範圍 了。
好比，若你處在物理學領域，牛頓就是你繞不過去的人，以後是愛因斯坦。而在計算機領域，圖靈定義了計算機的邊界，也是這個領域繞不過去的人。但這樣的天才人物，百年來纔出一個，若是都要達到這個水平纔算是專家，可能就太難了，從而失去了指導意義。
現在反思，其實用這兩點來定義專家也是能夠的，只是須要更清晰地明確領域和量化範圍。大至國家、社會、行業，小到公司、團隊、小組，都有本身關於專家的定義。
走向專家之路，就是精確地找到、創建你的領域，並不斷推高壁壘和擴大邊界的過程。
那麼如何創建屬於本身的、更大範圍內且具有足夠識別性的領域?這就是 「精」 的路徑中 的非連續性斷層問題。曾經讀過一篇吳軍的文章，談到了工程師成長中的相似問題，他用 了一個公式來描述解法:
成就 = 成功率 x 事情的量級 x 作事的速度
在連續的成長階段，咱們的成長主要體如今不斷提高作事的熟練度，也就是上述公式中的速度和成功率，但這兩個指標到了必定的熟練度階段後就會碰到物理極限。實際狀況是，一個資深的工程師的速度甚至不會比一個初級工程師快兩倍，但可能成功率會高几倍，甚至十倍，這就是傳說中的一個頂十個的程序員，但離極限也就差不遠了。
而要成爲傳說中以一敵百的程序員，只有一個可能，他們作的事情和其餘人不在一個量級 上。現實案例中，就有如 Linus 這樣的人。因此，一直作一樣的事，都是寫代碼，也能夠 跨越斷層，但關鍵是，你寫的代碼體如今什麼量級的事情上。
以前在工程思惟中總結過:問題的量級變了，邏輯就不同了。做爲程序員，咱們會有直 觀的感覺，用戶量級越過了必定的門檻後，咱們編寫、維護和部署程序系統的方式都會發 生本質的變化。而提高量級最難的就在於咱們要放下曾經熟悉的方式和習慣，站在更高的 維度去看更大量級的事情，而且找到適合這個量級事情的合適解決方案。
面臨成長路上的非連續斷層，以及角色之間的無形壁障，該如何跨越斷層，突破邊界?我 們着重從成長路線的兩個方向:「高」 和 「精」， 提供了分析和解法。
- 高的路線，須要藉助技術的槓桿，認清所處的價值網絡，找到合適的價值點，撬動更大的價值;
- 精的路線，在作事情的成功率和速度接近本身的極限後，只能去提高事情的量級，才能發揮出專家的價值。
成長藍圖，進化躍遷
回顧過去，咱們會清晰地看見走過來的路線，但面向將來咱們又該如何走下去?但凡過往，皆爲序章，過去不可變，將來纔是但願，而如何去規劃並管理好將來的成長進化之路，纔是咱們當下要面臨的主要任務。
咱們先從一個高度抽象的維度，來看看這條成長之路。
1、成長路線
結合我本身的經歷、思考與總結，我對走過的路和將來的路歸納成以下這張圖:
圖中描述了好幾個階段，從一個階段到下一個階段，都會經歷一次轉折。
1. 開發代碼(Develop Code)
從剛走出學校到進入職場成爲一名新手程序員，在最初的一兩年內，你可能都處在這個階 段。不停地大量寫代碼，爲各種系統的「大廈」添磚加瓦，像塊海綿同樣，把本身吸得滿 滿的，朝 9 晚 24 地工做與學習，並不時自嘲爲 「碼農」。
這個階段，你爲生存所需(迫)，會強烈地渴望成長。
2. 開發系統(Develop System)
3、五年後，你可能從初級、中級成長到了高級，此時你再也不僅僅是寫代碼搬磚，而是開始負責起或大或小的整個系統。這時，你最關心的是如何用最好的技術方案，去開發、優化和完善系統。
3. 開發產品(Develop Product)
從高級走向資深、專家或架構師，你會發現你的技術執行技能已經優化到了至關的程度，這時往前多走一步，關注你所實現的系統所屬的產品，會讓你打開新的空間，找到更有效率和效果的實現路徑，減小作無用功。並且在技術的世界裏，有不少面向開發者的技術型產品，這個領域中最適合承擔起產品經理角色的就應該是各種資深的技術專家和架構師了。
4. 開發團隊(Develop Team)
當你選擇走上技術主管並轉變爲一名管理者，那麼人和團隊將成爲你的主要開發對象，而 再也不是代碼了，這是成爲管理者的必經之路。
5. 開發夢想(Develop Dream)
夢想這個東西也會隨着歲月與你相伴成長，夢想實際永遠在前方，它只是不斷引領着你往 前走。夢想相對而言是一個感受上很 「虛」 的概念，它可能須要產品做爲載體，也須要團 隊來一塊兒開發創造。如此，夢想的引力就會引起你向一名創新者或領導者的方向進化躍 遷。好比說，十多年前，剛畢業時，個人夢想是成爲一名架構師，現在已然實現。
以上這張圖只是幫你看清從過去到將來的一條路，但如何走好這條路，就須要另外一個視角維度的藍圖了。
2、戰略藍圖
戰略這個詞，一般會和組織、公司關聯在一塊兒;那假想下，若是我的是一家公司，那麼這 家 「公司」 的戰略該如何肯定?
在分析戰略以前，咱們須要先分析下公司的業務。爲了更好地分析清楚公司的主要業務， 這裏借鑑下諮詢公司愛用的商業分析模型:波士頓矩陣。實際有不少不一樣的分析模型，我 只是以爲這個最簡單，比較適合像我的這樣的小小微 「公司」。
波士頓矩陣模型，把公司業務分紅下面四類:
- 現金牛業務
- 明星業務
- 問題業務
- 瘦狗業務
現金牛業務，比較形象地表達了就是產生現金的業務。好比谷歌的搜索業務、微軟的 Windows 操做系統，都是它們的現金牛業務，有很高的市場佔有率，但成長率相對就比 較低了。
就我的來講，現金牛業務天然是一份穩定的工做，產生現金，維持我的生活的基本面，當 然穩定以外越高薪越好。程序員這個職業就是很好的現金牛業務，行業繁榮，工做也比較 穩定，專一於這個業務，不斷提高薪資水平，這就是:活在當下。
明星業務，比較形象地表達了頗有前景的新興業務，已經走上了快速發展的軌道。好比: 亞馬遜的雲計算(AWS)就是它的將來之星。而我的呢?若是你的現金牛業務(級別和薪 資)已經進入行業正態分佈的前 20%，那麼再繼續提高的難度就比較大了。
我的的明星業務是爲將來 5 到 10 年準備的，就是如今還並不能帶來穩定的現金流但感受 上了軌道的事。於我而言，是投資理財。人到中年，除了勞動性收入，資產性收益將做爲 很重要的補充收入來源，而當資本金足夠大時，極可能就是將來的主要收入來源。當你開 始在考慮將來的明星業務時，這就是:活在將來。
問題業務，比較形象地表達了還有比較多問題的業務領域，面臨不少不肯定性，也就是還 沒走上正軌。未來究竟是死掉，仍是成爲新的明星業務，如今還看不清楚。好比谷歌的無 人駕駛、機器人等業務領域都屬於此類。
就我的而言，多是一些自身的興趣探索領域。於我來講，目前就是寫做和英語，即便寫 做已經開了專欄，但並不算是穩定可靠的收入來源，主要仍是以興趣驅動，投入時間，不 斷探索，開拓新的維度，這就是:活在多維。
瘦狗業務，比較形象地表達了一些食之無味、棄之惋惜的業務。瘦狗業務要麼沒法產生現 金流，要麼產生的現金流不斷萎縮。今日之瘦狗，也許是昨日的明星或現金牛，好比像諾 基亞的功能機。
就我的而言，行業在發展，技術也在進化，曾經你賴覺得生的 「現金牛」 技能，可能過幾 年後就會落後，逐漸變成了 「瘦狗」，沒法果斷地放棄舊技能、開發新技能，可能就如諾 基亞通常在新的時代被淘汰。固守瘦狗業務，那就是:活在過去。
業務模型構成了你的藍圖，而對你的各類業務進行與時俱進地佈局與取捨，這就是戰略。
3、進化躍遷
明晰了路線，掌握了藍圖，該如何完成你的成長進化躍遷呢?
躍遷是量子力學裏的概念，指電子吸取能量後，忽然跳到更高的能量級，這種不連續、跳 躍的突變，咱們稱之爲 「躍遷」。我借用了這個概念來類比成長，從如上定義中有幾個關 鍵點:
- 吸取能量
- 更高能量級
- 非連續跳躍
我的成長的躍遷也須要能量，在這裏能量就是知識、技能和能力。完成 「能量」 的積累就 須要持續地學習和實踐行動，而持續行動又靠什麼來驅動?
心裏的自驅力，這是穩定有效 的驅動力來源，若沒有自我驅動的力量是不太可能帶來持續行動的。
學習行動計劃、養成行動習慣都是爲了提高行動的效率，行動積累了足夠的 「能量」 後， 就向更高能量級跳躍。這裏更高的能量級是對知識和能力的更高維度抽象的比喻，好比: 知識模型和技能體系，就比孤立的知識點和技能擁有更高的能量級。
而第三個關鍵點:非連續跳躍，說明這樣的進化有突變的特徵。而我的知識的積累與能力的提高，其實都是比較緩慢而連續的，非連續的跳躍其實體如今機會和運氣上。合適的機會若沒能降臨，你就無法完成躍遷。
連續的成長積累是你能掌控的部分，而躍遷的機會、運氣則屬於機率成分，你的努力可能必定程度上提升了機率，但它並不能致使必然的躍遷結果發生。即便機會沒能到臨，努力事後也許有無奈，也該當無悔了。
最後，咱們總結下:
從開發代碼到開發夢想，你能夠畫出一張你的成長路線圖，從而走上進化躍遷的道路;上了路後，接着你能夠利用工程師的思惟模式和商業工具模型，創建一個你的成長戰略藍圖去指導你如何走這條路。剩下的，就讓你的努力、選擇和運氣來幫助你完成不斷的躍遷變化吧。