演算法與資料結構對程式設計師的重要性
阿新 • • 發佈：2019-02-10
曾經有個說法，程式=資料結構+演算法。這在面向過程的程式語言流行的年代是很受推崇的。
然而，隨著時代的發展，各種程式語言的出現，各種程式設計模式的發明，面向物件、設計模式、框架、模型等各種概念早已淹沒了當年那個簡單的提法。
那麼，在這個多樣化的年代，如果想立志做程式設計開發，還有沒有必要學好資料結構和演算法呢？
我的回答是，非但有必要，更應該學好、學博、學精。
第一，資料結構與演算法是程式的靈魂，是樸素的基礎，學好它有有助於理解各種上層抽象。
在沒有充分學習和理解資料結構與演算法的基礎上去學習面向物件、設計模式，是無法真正體會這些上層抽象的真正意義的，最終可能會導致學之泛泛，用之泛泛。
在工作中，見識了太多開口設計模式，閉口面向物件的人，在某個具體的問題上，問他為什麼要用面向物件，為什麼要用這樣的設計模式，得到的回答相當空泛，有時候甚至是為了物件而物件，為了設計而設計。這樣的人，做出來的設計，往往過度設計，似是而非，導致做出來的東西混亂不堪。
遇到的真正設計高手，還沒有一個是對資料結構與演算法是不精通的。讓他講為什麼這樣設計，為什麼這樣架構，他往往能深入淺出，將面向物件的思想、設計模式的考慮，與基礎的資料結構和對應的演算法結合起來，貼合問題的實際情況，給出良好的結論。
有人可能會擡槓：照你這麼說，是基礎就要學，那是不是還要把CPU的物理原理學透了才能寫程式？
我的回答：你說的還真對，一個對CPU的執行原理不清楚的人，是不可能真正理解現在流行的SMP架構、MPP架構的，也不可能寫出高質量的併發程式。這其中當然有個量的問題，但沒有質的差異。
從程式設計的角度來看，資料結構與演算法幾乎是最樸素的基礎知識了，這是關，是每一個立志當好程式設計師的必經之路，不管你是想學C還是想學JAVA，不管你是想學面向過程，還是面向物件，不管你是想當架構師，還是想當DBA（一個沒有良好演算法底子的DBA差不多算是半個殘廢）。
第二，在程式設計實踐中，資料結構和演算法隨處可見，影響重大。
有人說在工作中沒用到資料結構和演算法，這是一種誤解。並非讓你去實現一個連結串列才叫使用了連結串列。這可能與大學裡教條的教學有關，一味地講這些資料結構是怎麼程式設計實現的，一味地講這些演算法是怎麼證明的，卻忽視了學習這些的主要目的是為了在程式設計實踐中去應用它，而不是去重造輪子再發明一次（當然也有少數在演算法領域繼續深造作出新貢獻的人，這裡就排除不講了）。
見過不少對連結串列的基本屬性都不瞭解的人，在程式裡一味使用陣列，記憶體能開多大就多大；也見過太多根本不知道HASH原理的人，對Hash表隨意使用，造成KEY值嚴重重複、效率極為低下、失去了選用HASH的初衷。
即使不是演算法密集型的程式裡，哪怕是面向業務的程式設計工作中，能夠適當地應用資料結構，選擇恰當的演算法，也是能極大地提高程式的開發效率、執行效率和執行穩定性的。更不要說面向業務和工作流的基礎平臺，本身就含有大量的資料結構與演算法理論，想利用好這些平臺，沒有一個好的底子，那會事倍功半的。
第三，現在的軟體工程充斥著大量的過度設計、資源浪費，實際上已經到了硬體承受不了的地步了。學好資料結構和演算法，能夠從根本上去避免這些問題。
從我這裡的5年經驗來看，J2EE就是最佳代表。一個WAS應用，能夠承受的併發使用者數，竟然只有區區的100！！花費百萬元的投資，去買幾十個CPU、上百G記憶體，花費十倍甚至幾十倍的代價，卻只能提升百分之幾十的效率。這還是一個產品級的應用，是一個大型銀行核心的資料服務之一。那就更不用提在水平更低的專案組中那些可笑的效率問題了。
這是J2EE、JAVA的錯嗎？我不覺得，我同樣見到了設計良好的J2EE產品，效率一流，穩定性極佳。主要原因，還是開發者自身的水平，對演算法無知到了極點，對資料結構忽視到了極點。
第四，當今流行的WEB新時代，各種雲概念，海量資料，百萬使用者併發（從以前著名的C10K問題，到現在的C1000K甚至更高問題），最終都是資料結構與演算法的比拼。這一切，較量才剛剛開始。
這裡我就不展開了，雖然我這5年來做的主要工作就是這方面的（其中一點）。但它離初學者的層面還是太遠了，每一點展開都是工程實踐大部頭論述。
最後，說說對於初學者來說，該怎麼去學資料結構與演算法。
1、常備參考書。即使不能通讀，也要時時備查
2、已有的資料結構與演算法，怎麼實現是末節，能理解原理、明白適用場合才是重點。
3、不必過度追求怪異演算法，適用的就是最好的，簡單的才是最佳的。
4、多讀開源作品，看看他們是怎麼熟練應用那些基本的資料結構與演算法的。
5、希望你能在融會貫通的基礎上，舉一反三，來教教我怎麼繼續深入學習。因為我目前也卡在更高深的演算法泥潭中不能自拔
然而，隨著時代的發展，各種程式語言的出現，各種程式設計模式的發明，面向物件、設計模式、框架、模型等各種概念早已淹沒了當年那個簡單的提法。
那麼，在這個多樣化的年代，如果想立志做程式設計開發，還有沒有必要學好資料結構和演算法呢？
我的回答是，非但有必要，更應該學好、學博、學精。
第一，資料結構與演算法是程式的靈魂，是樸素的基礎，學好它有有助於理解各種上層抽象。
在沒有充分學習和理解資料結構與演算法的基礎上去學習面向物件、設計模式，是無法真正體會這些上層抽象的真正意義的，最終可能會導致學之泛泛，用之泛泛。
在工作中，見識了太多開口設計模式，閉口面向物件的人，在某個具體的問題上，問他為什麼要用面向物件，為什麼要用這樣的設計模式，得到的回答相當空泛，有時候甚至是為了物件而物件，為了設計而設計。這樣的人，做出來的設計，往往過度設計，似是而非，導致做出來的東西混亂不堪。
遇到的真正設計高手，還沒有一個是對資料結構與演算法是不精通的。讓他講為什麼這樣設計，為什麼這樣架構，他往往能深入淺出，將面向物件的思想、設計模式的考慮，與基礎的資料結構和對應的演算法結合起來，貼合問題的實際情況，給出良好的結論。
有人可能會擡槓：照你這麼說，是基礎就要學，那是不是還要把CPU的物理原理學透了才能寫程式？
我的回答：你說的還真對，一個對CPU的執行原理不清楚的人，是不可能真正理解現在流行的SMP架構、MPP架構的，也不可能寫出高質量的併發程式。這其中當然有個量的問題，但沒有質的差異。
從程式設計的角度來看，資料結構與演算法幾乎是最樸素的基礎知識了，這是關，是每一個立志當好程式設計師的必經之路，不管你是想學C還是想學JAVA，不管你是想學面向過程，還是面向物件，不管你是想當架構師，還是想當DBA（一個沒有良好演算法底子的DBA差不多算是半個殘廢）。
第二，在程式設計實踐中，資料結構和演算法隨處可見，影響重大。
有人說在工作中沒用到資料結構和演算法，這是一種誤解。並非讓你去實現一個連結串列才叫使用了連結串列。這可能與大學裡教條的教學有關，一味地講這些資料結構是怎麼程式設計實現的，一味地講這些演算法是怎麼證明的，卻忽視了學習這些的主要目的是為了在程式設計實踐中去應用它，而不是去重造輪子再發明一次（當然也有少數在演算法領域繼續深造作出新貢獻的人，這裡就排除不講了）。
見過不少對連結串列的基本屬性都不瞭解的人，在程式裡一味使用陣列，記憶體能開多大就多大；也見過太多根本不知道HASH原理的人，對Hash表隨意使用，造成KEY值嚴重重複、效率極為低下、失去了選用HASH的初衷。
即使不是演算法密集型的程式裡，哪怕是面向業務的程式設計工作中，能夠適當地應用資料結構，選擇恰當的演算法，也是能極大地提高程式的開發效率、執行效率和執行穩定性的。更不要說面向業務和工作流的基礎平臺，本身就含有大量的資料結構與演算法理論，想利用好這些平臺，沒有一個好的底子，那會事倍功半的。
第三，現在的軟體工程充斥著大量的過度設計、資源浪費，實際上已經到了硬體承受不了的地步了。學好資料結構和演算法，能夠從根本上去避免這些問題。
從我這裡的5年經驗來看，J2EE就是最佳代表。一個WAS應用，能夠承受的併發使用者數，竟然只有區區的100！！花費百萬元的投資，去買幾十個CPU、上百G記憶體，花費十倍甚至幾十倍的代價，卻只能提升百分之幾十的效率。這還是一個產品級的應用，是一個大型銀行核心的資料服務之一。那就更不用提在水平更低的專案組中那些可笑的效率問題了。
這是J2EE、JAVA的錯嗎？我不覺得，我同樣見到了設計良好的J2EE產品，效率一流，穩定性極佳。主要原因，還是開發者自身的水平，對演算法無知到了極點，對資料結構忽視到了極點。
第四，當今流行的WEB新時代，各種雲概念，海量資料，百萬使用者併發（從以前著名的C10K問題，到現在的C1000K甚至更高問題），最終都是資料結構與演算法的比拼。這一切，較量才剛剛開始。
這裡我就不展開了，雖然我這5年來做的主要工作就是這方面的（其中一點）。但它離初學者的層面還是太遠了，每一點展開都是工程實踐大部頭論述。
最後，說說對於初學者來說，該怎麼去學資料結構與演算法。
1、常備參考書。即使不能通讀，也要時時備查
2、已有的資料結構與演算法，怎麼實現是末節，能理解原理、明白適用場合才是重點。
3、不必過度追求怪異演算法，適用的就是最好的，簡單的才是最佳的。
4、多讀開源作品，看看他們是怎麼熟練應用那些基本的資料結構與演算法的。
5、希望你能在融會貫通的基礎上，舉一反三，來教教我怎麼繼續深入學習。因為我目前也卡在更高深的演算法泥潭中不能自拔