你是不是覺得資料結構和演算法，跟作業系統、計算機網路一樣，是脫離實際工作的知識？可能除了面試，這輩子也用不著？

儘管計算機相關專業的同學在大學都學過這門課程，甚至很多培訓機構也會培訓這方面的知識，但是據我瞭解，很多程式設計師對資料結構和演算法依舊一竅不通。還有一些人也只聽說過陣列、連結串列、快排這些最最基本的資料結構和演算法，稍微複雜一點的就完全沒概念。

當然，也有很多人說，自己實際工作中根本用不到資料結構和演算法。所以，就算不懂這塊知識，只要Java API、開發框架用得熟練，照樣可以把程式碼寫得“飛”起來。事實真的是這樣嗎？

今天我們就來詳細聊一聊，為什麼要學習資料結構和演算法。

想要通關大廠面試，千萬別讓資料結構和演算法拖了後腿

很多大公司，比如BAT、Google、Facebook，面試的時候都喜歡考演算法、讓人現場寫程式碼。有些人雖然技術不錯，但每次去面試都會“跪”在演算法上，很是可惜。那你有沒有想過，為什麼這些大公司都喜歡考演算法呢？

校招的時候，參加面試的學生通常沒有實際專案經驗，公司只能考察他們的基礎知識是否牢固。社招就更不用說了，越是厲害的公司，越是注重考察資料結構與演算法這類基礎知識。相比短期能力，他們更看中你的長期潛力。

你可能要說了，我不懂資料結構與演算法，照樣找到了好工作啊。那我是不是就不用學資料結構和演算法呢？當然不是，你別忘了，我們學任何知識都是為了“用”的，是為了解決實際工作問題的，學習資料結構和演算法自然也不例外。

業務開發工程師，你真的願意做一輩子CRUD boy嗎？

如果你是一名業務開發工程師，你可能要說，我整天就是做資料庫CRUD（增刪改查），哪裡用得到資料結構和演算法啊？

是的，對於大部分業務開發來說，我們平時可能更多的是利用已經封裝好的現成的介面、類庫來堆砌、翻譯業務邏輯，很少需要自己實現資料結構和演算法。但是，不需要自己實現，並不代表什麼都不需要了解。

如果不知道這些類庫背後的原理，不懂得時間、空間複雜度分析，你如何能用好、用對它們？儲存某個業務資料的時候，你如何知道應該用ArrayList，還是Linked List呢？呼叫了某個函式之後，你又該如何評估程式碼的效能和資源的消耗呢？

作為業務開發，我們會用到各種框架、中介軟體和底層系統，比如Spring、RPC框架、訊息中介軟體、Redis等等。在這些基礎框架中，一般都揉和了很多基礎資料結構和演算法的設計思想。

比如，我們常用的Key-Value資料庫Redis中，裡面的有序集合是用什麼資料結構來實現的呢？為什麼要用跳錶來實現呢？為什麼不用二叉樹呢？

如果你能弄明白這些底層原理，你就能更好地使用它們。即便出現問題，也很容易就能定位。因此，掌握資料結構和演算法，不管對於閱讀框架原始碼，還是理解其背後的設計思想，都是非常有用的。

在平時的工作中，資料結構和演算法的應用到處可見。我來舉一個你非常熟悉的例子：如何實時地統計業務介面的99%響應時間？

你可能最先想到，每次查詢時，從小到大排序所有的響應時間，如果總共有1200個數據，那第1188個數據就是99%的響應時間。很顯然，每次用這個方法查詢的話都要排序，效率是非常低的。但是，如果你知道“堆”這個資料結構，用兩個堆可以非常高效地解決這個問題。

基礎架構研發工程師，寫出達到開源水平的框架才是你的目標！

現在網際網路上的技術文章、架構分享、開源專案滿天飛，照貓畫虎做一套基礎框架並不難。我就拿RPC框架舉例。

不同的公司、不同的人做出的RPC框架，架構設計思路都差不多，最後實現的功能也都差不多。但是有的人做出來的框架，Bug很多、效能一般、擴充套件性也不好，只能在自己公司僅有的幾個專案裡面用一下。而有的人做的框架可以開源到GitHub上給很多人用，甚至被Apache收錄。為什麼會有這麼大的差距呢？

我覺得，高手之間的競爭其實就在細節。這些細節包括：你用的演算法是不是夠優化，資料存取的效率是不是夠高，記憶體是不是夠節省等等。這些累積起來，決定了一個框架是不是優秀。所以，如果你還不懂資料結構和演算法，沒聽說過大O複雜度分析，不知道怎麼分析程式碼的時間複雜度和空間複雜度，那肯定說不過去了，趕緊來補一補吧！

對程式設計還有追求？不想被行業淘汰？那就不要只會寫湊合能用的程式碼！

何為程式設計能力強？是程式碼的可讀性好、健壯？還是擴充套件性好？我覺得沒法列，也列不全。但是，在我看來，效能好壞起碼是其中一個非常重要的評判標準。但是，如果你連程式碼的時間複雜度、空間複雜度都不知道怎麼分析，怎麼寫出高效能的程式碼呢？

你可能會說，我在小公司工作，使用者量很少，需要處理的資料量也很少，開發中不需要考慮那麼多效能的問題，完成功能就可以，用什麼資料結構和演算法，差別根本不大。但是你真的想“十年如一日”地做一樣的工作嗎？

經常有人說，程式設計師35歲之後很容易陷入瓶頸，被行業淘汰，我覺得原因其實就在此。有的人寫程式碼的時候，從來都不考慮非功能性的需求，只是完成功能，湊合能用就好；做事情的時候，也從來沒有長遠規劃，只把眼前事情做好就滿足了。

我曾經面試過很多大齡候選人，簡歷能寫十幾頁，經歷的專案有幾十個，但是細看下來，每個專案都是重複地堆砌業務邏輯而已，完全沒有難度遞進，看不出有能力提升。久而久之，十年的積累可能跟一年的積累沒有任何區別。這樣的人，怎麼不會被行業淘汰呢？

如果你在一家成熟的公司，或者BAT這樣的大公司，面對的是千萬級甚至億級的使用者，開發的是TB、PB級別資料的處理系統。效能幾乎是開發過程中時刻都要考慮的問題。一個簡單的ArrayList、Linked List的選擇問題，就可能會產生成千上萬倍的效能差別。這個時候，資料結構和演算法的意義就完全凸顯出來了。

其實，我覺得，資料結構和演算法這個東西，如果你不去學，可能真的這輩子都用不到，也感受不到它的好。但是一旦掌握，你就會常常被它的強大威力所折服。之前你可能需要費很大勁兒來優化的程式碼，需要花很多心思來設計的架構，用了資料結構和演算法之後，很容易就可以解決了。

內容小結

我們學習資料結構和演算法，並不是為了死記硬背幾個知識點。我們的目的是建立時間複雜度、空間複雜度意識，寫出高質量的程式碼，能夠設計基礎架構，提升程式設計技能，訓練邏輯思維，積攢人生經驗，以此獲得工作回報，實現你的價值，完善你的人生。

所以，不管你是業務開發工程師，還是基礎架構工程師；不管你是初入職場的初級工程師，還是工作多年的資深架構師，又或者是想轉人工智慧、區塊鏈這些熱門領域的程式設計師，資料結構與演算法作為計算機的基礎知識、核心知識，都是必須要掌握的。

掌握了資料結構與演算法，你看待問題的深度，解決問題的角度就會完全不一樣。因為這樣的你，就像是站在巨人的肩膀上，拿著生存利器行走世界。資料結構與演算法，會為你的程式設計之路，甚至人生之路開啟一扇通往新世界的大門。

課後思考

你為什麼要學習資料結構和演算法呢？在過去的軟體開發中，資料結構和演算法在哪些地方幫到了你？

歡迎留言和我分享，我會第一時間給你反饋。如果你的朋友也在學習演算法這個問題上猶豫不決，歡迎你把這篇文章分享給他！