演算法和資料結構是否是屠龍之技？

1樓：

演算法感覺本質是上是乙個管理學問題，資料結構就是部門分案。演算法研究就是不斷追求更好地分配執行單元的執行力，去解決巨集觀戰略問題。

2樓：拉勾教育

不知道你所說的「屠龍之技」是怎麼定義的。

不過呢，我想說，資料結構與演算法的確是非常重要的。不會資料結構與演算法，你基本與大廠無緣了。在這個層面上，的確可以稱作「屠龍之技」了。

想學好資料結構與演算法，不是件容易的事情。可以學習一些大神的經驗，比如，中科院博士公瑾的【重學資料結構與演算法】。

感興趣的可以私我發鏈結~

3樓：Lancet

以前覺得機組很屠龍，後來發現我錯了。

後來覺得編譯原理很屠龍。後來發現我又錯了。

近幾個月我居然已經隱約感受到可計算理論的非屠龍特性。

but 我從沒有一天感受到演算法和數構的屠龍特性。

或許真正的屠龍技只是我很多年前在那個暖暖的下午上的蛋白質分離課。

4樓：

演算法這東西就算你不會實現，最低限度至少得理解各種演算法的應用場景。

舉個簡單例子，你知道一系列元素各自之間的依賴關係，要算出它們的順序，被依賴的需要在依賴者前面。這個需求在普通業務系統也很常見了吧。

就算你調庫，你也得先知道這個東西叫「有向圖拓撲排序」呀。

現在重點來了，如果你不先了解「有向圖拓撲排序」的原理，那你一開始是怎麼知道這個需求對應這個演算法的？

5樓：Raynor

xy，屠龍之技的前提是沒有龍。而資料結構已經被廣為應用了，就連再冷門的都有人用，所以不算。

演算法可以參考

資料結構可以參考

List of data structures基本上這些全部學完了你就有個大概了解了。

6樓：invalid s

是的，所以編譯原理 (豆瓣) 乾脆就叫龍書。

不同的是，軟體的世界裡到處是龍。你老窩新手村的話無所謂，想稍微出點遠門還是得會屠龍。

7樓：

本人見識有限, 可恥的匿了。諸位大神，輕噴。

要論實用：

10年前借錢貸款在北京（上海深圳同樣適用）買房才是最牛b的。其他的都是扯蛋。

1.資料結構演算法這東西，個人感覺偏向於考深度，就是說如果乙個人他把資料結構和演算法都學的挺好，那麼八成這個人是能夠靜得下來好好專研一塊知識的，是比較講究實踐的（acm之類的平台都是當場跑，當場出結果）。。。反之不一定成立。。。

2.除了演算法工程師等特殊崗位外，複雜的資料結構在工程中幾乎用不上，尤其是時間複雜度這類偏向純理論研究的部分。。雖然在架構效能分析的時候可能會給予一定幫助，或者在小的核心模組設計上可能會有那麼一些模擬啟發，但是很少有直接用上的。

3.最近看GO語言的執行時某幾塊邏輯，也是有一點啟發，裡面的效能優化部分（就我看的那些部分）更多的是偏向於多重知識的聯合，往往不是通過一種複雜的資料結構來解決乙個大問題，而是通過聯合作業系統，做乙個本地的local鍊錶（或陣列），乙個全域性的鍊錶陣列。本地可以無鎖操作，必要時才和全域性的互動乙個方式來解決。

簡而言之就是通過聯合作業系統的知識，建立二層乃至三層快取的形式，充分讓演算法跑在多核的盡量無鎖的簡單的資料結構上，實現效能的多方位優化。

本人見識比較有限，但工作中給我感覺最深的往往是，工程中優化效能問題的時候，往往不是純粹的通過最底層的資料結構的調整，它作為乙個工程的整體，會先優化裡面的引數，其次會考慮建立多級快取，考慮記憶體硬碟網路等綜合開銷，而最裡面的實現卻往往是比較簡單資料結構便於維護以及擴充套件。

工作中演算法，資料結構往往作為很多能力中的乙個點，聯合其他的知識綜合考慮，還需要結合業

務，考慮魯棒性，可維護，可讀性，穩定性等等問題。

4.演算法中的乙個思想：快取的思想（動態規劃那類題目就是很好的體現），往往使用的最多的，也是便於理解，便於控制和嵌入業務邏輯的思想（現實中更多的是建立一層或多層快取）。

5.還有乙個思想：實踐的思想，實事求是的思想。

就像acm中以實際test case跑出來的成績為準一樣，工程中的效能模組也是應該有這種實事求是的思想，有時候市面上會有很多的華麗麗的概念和技巧，實際效果如何，還是應該實事求是地驗證。

雖然貌似「釣魚問題」，不過就算整理思路，好好回答一下了。

演算法和資料結構是否是屠龍之技？

有哪些用 Python 語言講演算法和資料結構的書？

學習演算法和資料結構可以提高智商嗎？

學好演算法和資料結構，對提高業務開發程式設計能力有什麼直接關係嗎？

其他用戶還看了：