程序世界是一片廣闊的大地，相比我十多年前進入這個世界時，這片大地的邊界又擴大了很多倍。初入程序世界難免迷茫，要在這個世界立足、生存，並得到很好的發展，應首要具備怎樣的技能呢？未來的程序之路，先給自己準備一份基本的技能地圖，先有圖，再上路。
在程序的技能地圖中，需要先開啓和點亮哪些部分呢？回顧我過去的經歷並結合現實的需要，可以從如下兩個不同程度的維度來說明：
掌握
瞭解
掌握，意味着是一開始就要求熟練掌握的硬技能，這是生存之本。而至於掌握的深度，是動態的，倒是可以在行進過程中不斷去迭代加深。瞭解，相對掌握不是必需，但也需要達到知其然的程度，甚至知其所以然更好。
一、掌握
上路之初，需要掌握的核心生存技能有哪些呢？![]
- 開發平臺
開發平臺，它包括一種編程語言、附帶的平臺生態及相關的技術。在如今這個專業化分工越來越細的時代，開發平臺決定了你會成爲什麼類型和方向的程序員。比如：服務端、客戶端或前端開發等。其中進一步細分客戶端還可以有 Windows、Mac、iOS 和 Android 等不同的平臺。
編程語言
語言的選擇基本決定了開發平臺的性質，但有些語言可能例外，如：C++、JS、C# 等，這些語言都可以跨多個平臺。但即使你選的是這些語言，基本也會歸屬到某一類平臺上。好比你選了 C++，如果你去做了客戶端開發，就很少可能再去用 C++ 寫服務端程序了。
關於語言的選擇，前面我已經寫過了選擇的邏輯，便不再多說。但選擇了語言，我們不僅僅是熟悉語言自身的特性，還需要掌握支撐語言的平臺庫。Java 若僅從語言特性上來說，有其優點，但其瑕疵和缺陷也一直被吐槽，要是沒有 JDK 強大的平臺庫支撐，想必也不會有今天的繁榮。
平臺生態
與語言平臺關聯的還有其技術生態以及各種技術框架的繁榮程度。這些平臺技術生態的存在讓使用這門語言編程完成特定的任務變得容易和簡單得多。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，並用好它。
當工具變得越來越強大時，工具背後的思想其實更重要，對其的理解決定了我們應用工具的模式。而對源碼進行管理的最基本訴求有以下三點：
並行：以支持多特性，多人的並行開發
協作：以協調多人對同一份代碼的編寫
版本：以支持不同歷史的代碼版本切換
最後，把以上內容總結爲如下一張圖：紅色區域相對更小而聚焦，是需要掌握的部分，要求深度；藍色區域的部分更廣而泛，需要廣度。
以上就是回顧走過的路徑後，覺得需要具備的一份基礎技能圖。十多年後，這張圖上的每一個分類都出現了新的技術迭代，有了新的框架、算法和產品等，但它們並不過時，依然可以爲你的技能點亮之路提供方向指引。也許，你程序生涯的第一個一萬小時你就會花在這張圖上了。
資料領取：加羣：714526711；羣文件可以直接下載
【如果感覺文章還可以，就請關注一下吧！！！】