一個程序員會遇到多少關於數據結構與演算法的需求?
考慮我是個前端, 我問這個問題主要是關心前端開發以外的情況, 而且關於前端已經有討論了: 前端工程師對數據結構與演算法要求高嗎？ - JavaScript - 知乎
其實還是看項目 像最近BuckleScript編譯器的項目 幾乎所有常用的圖演算法都自己寫了一遍原因是兩個 其一通用的庫效率太低了 沒有自己定製的高校其二 別人的庫一堆dependencies 還有license的問題 所以不如自己寫得快編譯器做累了寫寫經典演算法 就當是种放松吧……
學校里，計算機系老師一開始就會說 程序 = 數據結構 + 演算法。
但是畢業工作後，對大部分程序員來說，程序 = 數據結構 + 邏輯。數據結構的合理選擇和使用是開發人員的基本要求。因為錯誤的選擇數據結構，很容易影響程序效率以及空間複雜度，還容易給團隊其他成員造成一些不必要的麻煩。而邏輯通常指軟體開發中系統功能邏輯，說白了就是開發人員要清晰理解業務需求並做出完善的功能邏輯設計，盡量避免異常和bug。至於演算法，除了專門的演算法工程師以及很多遊戲開發者，大部分開發人員並不是天天會碰見的。即便碰見一些基本的演算法使用，通常語言類庫本身也已經有很好的實現了。
再說一點，確實有這麼一個事實，就是廣大程序員的演算法知識最熟練的時候就是他們上學考試的時候以及每次面試前半年的時候（一般是準備大公司面試時）。謝邀。很多 candidate 不喜歡演算法與數據結構相關的面試，覺得演算法面試中的內容是與日常工作無關的刁鑽考察；與其相反，我認為 (良好設計的) 演算法面試是對日常 engineering 工作的一層抽象 (abstraction)。如果你在工作中不需要解決類似演算法面試中的難題，也許是因為你的工作不夠有趣？：D
舉個例子。你要在網頁上放一張北京市的地圖，然後把每個知乎用戶所在的位置都用小紅點標示出來。如果這個地圖不支持任何互動的操作也不會隨時間變化，那麼你可以簡單的用一個數組 (array) 來存儲每個用戶的位置以及個人信息；渲染時遍歷這個數組，把每一個小紅點添加到地圖上。這個操作的時間複雜度是 O(n)，聽起來還不錯。
但如果我們要支持用滑鼠框選的操作，並顯示選中範圍內的用戶信息呢？我們可以拿到滑鼠位置變化的數值，但我們的數據結構並不了解用戶間的相對位置信息。因此，每一次的選區變化都迫使我們重新遍歷這個數組，檢查每個用戶是否在選區內。這明顯不是個高效的操作——想像一下有幾千名用戶出現在地圖中時，這個操作的性能會怎樣。
什麼是更好的解決方案？我們可以換用一個四叉樹 (Quadtree - Wikipedia) 來存儲每個用戶的位置信息。簡單來說，這個四叉樹把地圖分成四個象限；每一個象限可以再被分解為四個子象限 (以此類推)，然後每個點根據 (x, y) 的位置被放進相應的子象限中。這樣，我們存儲下了用戶間的相對位置關係；當滑鼠選區變化時，我們更可以只在 Quadtree 中搜索新舊選區間所增減的部分。
上面所描述的就是北美某司的一道面試題。給定需要實現的需求 (在地圖上渲染數據點並支持框選)，設計並在白板上寫出所需要的數據結構。
小測驗：這個操作的時間複雜度是多少？幾乎所有程序員演算法水平的最高點就是在他們准面電話面試的時候。
和前端還是後端沒啥關係。
當你不懂數據結構和演算法的時候，確實感覺不會用到很多。怎麼實現不是實現？反正咔咔咔一把梭代碼寫完再說。
當你懂了數據結構和演算法的時候，寫代碼大部分時候會多一層這方面的考慮，這個時候就用的多了。首先是面試的時候需要會寫，但如果真正開始工作寫程序，並不需要全部記住如何實現，因為幾乎都有人已經實現好了，就算沒有看著wiki手糊一個也不是什麼問題。但腦子裡一定要有對複雜度的概念，這是最重要的。
直接考數據結構和演算法的機會可能不多，但不懂數據結構，你就會寫出這樣的代碼
普通優秀的程序員:尋找適合的演算法和數據結構，並花費一些時間實現應用。優秀的程序員:大部分時候都知道什麼是好的演算法和結構，直接找最好的實現使用。
最優秀的程序員:我寫的代碼就是最好的，演算法和數據結構由其他優秀程序員總結。
碼農對這些玩意兒零需求。碼農只管好好碼代碼就行了，瞎操什麼演算法的閑心，咸吃蘿蔔淡操心。
我從接觸前端到現在已經兩年時間。時間不算長，遇到的演算法問題只有兩個：
1. 實現虛擬dom中的diff步驟需要用到動態規劃相關的知識。2. 實現一個類似於一筆畫遊戲時需要用到圖相關的演算法。我個人感覺，平時的項目中一般沒什麼演算法問題。但如果要是自己開發框架和工具，肯定會遇到更多演算法方面的問題。好比你問一個大學生，你學加減法幹啥？除了考試還有什麼用啊？打dota要數學么？泡妞要數學么？吃飯要數學么？當然不要了，可是這只是你了解世界的一點點而已。
數據結構和演算法只是了解計算機世界的途徑，也許作為一個code monkey你確實不需要知道，O（1）和O（n）的區別。因為monkey只是monkey，不是engineer
一個函數是一個演算法，一個加減乘除的語句也是一個演算法
如果是做RD方向的生產工具類軟體的話，平均每個項目中大概有N個練演算法的需求，難度見需求，這些演算法通常也是這個工具的核心內容。而N和你做的這個工具的最終使用者在行業裡面的寡頭程度正相關。
而且一般大多數的演算法設計的主要內容是基於一種演算法的思路，實現這個演算法的框架後選擇一些合適的參數和參數的調整，以及用來包裝原數據的用於演算法的數據結構，而不是演算法設計本身。只有在數據結構非常大影響到演算法的效率的時候才會設計一個合適的數據結構，或者因為存在一個沒法動的數據結構（比如之前就存在N多年的超大資料庫，而這個資料庫有專門的部門維護，同時也是好多部門都在用的），而設計一個合理的演算法。
以我這行來說，N大概等於2-3的樣子。
另外還有一類「演算法實現」，是按照工程規則實現相應的計算，通常這種計算的細節和程序設計無關，實現的主要內容就是把工程規則翻譯成演算法，通常這一部分在本行業中都是簡單的搜索演算法。
如果是面向大眾的東西的話，我可以想像基本都有現成的把？面試的時候最有用，但是但是但是，不想35退居二線升不上去下不來，房貸還有孩子沒上大學，老老實實寫演算法，寫代碼，不斷的學習就是最好的演算法
工作以來用得最順手的的演算法：keep things simple
正準備重新學習演算法和數據結構，買了本《演算法》（第四版），結合著本書作者在youtube上的視頻學習
演算法可大致分為基本演算法、數據結構的演算法、數論與代數演算法、計算幾何的演算法、圖論的演算法、動態規劃以及數值分析、加密演算法、排序演算法、檢索演算法、隨機化演算法、並行演算法，厄米變形模型，隨機森林演算法。https://wapbaike.baidu.com/item/%e7%ae%97%e6%b3%95/209025?adapt=1fr=aladdin基本演算法數據對象的運算和操作：計算機可以執行的基本操作是以指令的形式描述的。一個計算機系統能執行的所有指令的集合，成為該計算機系統的指令系統。一個計算機的基本運算和操作有如下四類：1，算術運算：加減乘除等運算2，邏輯運算：或、且、非等運算3，關係運算：大於、小於、等於、不等於等運算4，數據傳輸：輸入、輸出、賦值等運算[1]
先回答問題：
數據結構幾乎天天在用，在合適的時候選擇合適的數據結構，合格的工程師有必要讓自己的每段代碼性能最優。甚至使用資料庫的時候，也需要知道資料庫實現的數據結構，以便於自己設計的讀寫模式正好達到最優的性能，這個是伺服器開發的基礎。
設計演算法的機會會少很多，這個要看工種，也看團隊的發展階段，很難有個定數，在搭建基礎框架的時候，會有很多需求，鋪業務的時候就會少很多。但是問題並不是這麼簡單，招聘考察數據結構和演算法的本質，並不是worker層面能明白的，除了工作中需要演算法，有它更深層次的原因：1、基礎和素質的考察：其實是對基礎知識和素質的篩選，一個數據結構和演算法學得好的人，很大可能他的其它基礎也較好，人很勤奮努力，有學習能力，這樣的人潛力相對更大一些。雖然不是必然，但基本是正相關的。2、團隊發展的需要：今天可能在鋪業務，假設我招了一個只能複製粘貼代碼，實現平鋪邏輯的人。兩年後業務擴展了，需要搭建很多需要數據結構和演算法的系統，你說我用不用這個人呢？用了，做不好。不用，難道我再招幾個專門做平台的人嗎？五年後業務又擴展了，當初的新人成了老員工，原來的lead升了總監，你說他應該提拔誰去lead技術團隊？讓演算法都不想學的老員工lead新員工去做需要演算法的平台，還是讓新人領導老人呢？總會有很多問題的，莫不如當初就都招基礎最好的。數據結構是寫代碼的基礎
演算法是培養遇到問題時，解決問題的思路並不是面個試就完了，對以後還是很有用的android ios 呵呵了，最複雜的結構是列表，演算法是冒泡，都沒見過樹
推薦閱讀：
※有沒有一種數據結構，查找、刪除和插入效率都比較高呢？
※如何在程序中將中綴表達式轉換為後綴表達式？
※如何高效地判斷兩個單鏈表是否有交叉？
※希爾排序對於h有序數組排序的選擇問題？
※演算法導論的學習路線是怎樣的？