1樓：
工程師是搞定問題的，debug解決，和利用已有的原理(演算法資料結構)解決，區別在於乙個要花不少時間，乙個根據特性很快搞定。人與人之間就是這麼拉開的。有用沒用，還得看場景深度。
2樓：
因為計算機行業的標準速度太快了，
有用沒用是相對的，對做基礎內容的確實有用，
對做業務的，全部用的一體化方案，這種細節真的有用嗎？
3樓：行者
前端開發確實在普通應用中演算法用不太到。演算法一般是為了解決特定問題，比如最簡單的冒泡演算法，後端一般會直接把資料弄好，你拿到資料直接渲染即可
你覺得演算法不重要，很可能是你沒到特定的場景。
前端深入之後，就會涉及到演算法，框架設計，比如react的diff演算法，可以看看如何最高效地更新dom.
還有海量資料渲染，怎麼渲染才最高效，怎麼做到低端機器上不卡頓，怎麼節省流量。
往往複雜的業務邏輯都離不開演算法的優化。
假如你僅僅滿足於做個普通程式設計師，畫畫頁面，呼叫別人寫好的api就夠了，那確實不需要演算法。
假如你想去大廠，要去解決複雜性的問題，想要成為架構師去設計架構，想要再程式這條路上更進一步，演算法還是要學的。
演算法就是你的核心競爭力，讓你和普通程式設計師有所區別。
4樓：菌菇
你簡歷上寫你用過redis？
是的那你講講redis的實現原理是什麼？
我用過，會用，原理我沒看過
是不是很熟悉？
寫業務確實不用演算法，if else for就能夠應對80％的場景，你只需要會用各種庫就行了，但是你想要深入了解甚至寫出乙個redis，你就必須要懂一致性雜湊、跳表等各種演算法，雖然業務上都不需要這些知識
寫程式就是乙個刨根問底的過程，而演算法就是這些根、底的一部分
5樓：
首先應該區分神馬是科學家，神馬是工程師。然後你就明白了，演算法研究是計算機科學家做的事，工程師是把科學家的研究結果與現實相結合，產生效益。
6樓：啊卡林
你這個問題的目的，是要確定自己學或不學嗎？答案肯定得學。
問題的關鍵是，你得學到什麼程度，花多大精力，什麼時候學。
每個人的情況是不一樣的，所以不用糾結這句話。因為這句話在說出的時候，是帶了上下文和場景的。
如果你真的一點都不學，那就很奇怪了。
7樓：陳魯愚
沒必要一捧一踩。因為有人只想當鹹魚；有人不甘心想梭哈一把不得不學；有人覺著有趣所以學了。等等。
而且，人（包括上述三者但不限於）與人之間存在明顯的學習觀念上的差異，這就導致一類人對另一類人做道德或者行為上的指摘是不恰當的。假以時日，「指摘」終會變成「異教徒」之間的謾罵和指指點點，抑或是為了批評異見者而暫時抱團取暖。
況且，學習行為在求知的同時也是為了自我滿足，目的是超越並殺死某個時刻以來的「無知」的自己。這類循著前人路徑攀登未知山脈並到達檢查點（山巔？）所帶來的快感，回味之悠長遠超酒精尼古丁等致幻藥物。
軟體工程師學習演算法對工作絕對是有幫助。要是還想問為什麼有用？我有個不成熟的小小建議：
把題目修改成「軟體工程師工作中的演算法使用場景有哪些？」或「各位用演算法知識解決過哪些軟體開發所遇到的問題？」。
我感覺這樣，熱心的知友才會正經地回答問題，告訴疑問者如何應用演算法知識。同時瀏覽者也可以輕鬆地排除無效的答案。
至於認為軟體工程師學習演算法沒什麼用的人。我們只需要擺事實，講道理。千萬不要妄圖批判他什麼，畢竟，每個人都有自己的選擇。
8樓：Cirno Scarlet
不學演算法？不學演算法好啊，你不會，我會，我比你有優勢，更能拿到好的offer，更能拿到高薪，更能公升職。
我強烈呼籲所有軟體工程師都不要學習資料結構不要學習演算法，好為他人讓出上公升空間。
9樓：lu luce
軟體工程師覺得學習演算法沒用的想法是正確的。
畢竟大部分人都是面試造火箭，入職擰螺絲。
但是：你要是不會造火箭，你沒法拿到入職Offer。
就是這樣。
會，但是不用和不會是不一樣的。。
萬一，工作中用到了。就體現出來了。。
10樓：唐昊
有這個認識的基本上都是碼畜，連碼農都夠不上，達不到工程師的水準的。
資料結構、演算法等計算機基礎是乙個碼農真正成為工程師的必修課，只有意識到位了才可能公升級，就跟你玩遊戲一樣，那麼多人操作犀利，但是能上王者的屈指可數……無他，就是意識不夠。在開發的道路上也是一樣的，當乙個開發人員意識到資料結構和演算法以及甚至是數學是多麼的重要，後悔當初沒有好好努力學習的時候，他才是真正上路了……
11樓：玄鐵匠
演算法時時刻刻都有用，首先你得知道有某種演算法，其次在工作中，在你寫了很多if else的時候，就要想想有沒有什麼更好的演算法來實現。
12樓：AS123
看業務之前寫圖層許可權管理，用遞迴將資料庫裡面的樹組裝成樹，前端js再用遞迴展示樹。
重寫日誌解析器，替代ELK裡面的logstash和filebeat，用到Trie樹，用於帶引數指令的匹配。
寫分布式任務排程的時候，基於linkedhashmap的LRU快取，現在準備引入innodb的midpoint的概念，再改造一下linkedhashmap。
寫負載均衡的時候，用到一致性hash演算法，用跳表實現的，跳表優於Treemap紅黑樹的地方，是當前分配節點故障，可以直接找下乙個節點，紅黑樹還需要遞迴上上下下。
13樓：布客飛龍
演算法有用，但是對 curd 沒用，否則大家都是演算法工程師了。
作為軟體工程師，你可以學學演算法來鍛鍊思維，開闊眼界，這個沒問題，但你不能寫著 curd 還怪演算法沒用，這種行為叫腦臀分離。
建議所有軟體工程師首先把本職工作做好，多看成熟軟體的架構避免自己犯2b，做好單元測試提公升質量，用好自動化工具節省時間。然後才是演算法的事。
14樓：李白
高考考數學的目的不是因為大學專業會用到，而是要把用數學把聰明人給選出來。
大廠問演算法也是一樣的道理，不缺人幹活，缺的是聰明人。
你問學演算法重要不？你不學你咋知道自己是不是「聰明人」？
15樓：若川
那估計只是所處階段可能沒用上就說沒用。
就好比我們爬山，爬一座小山，大家都是不費吹灰之力就爬上去了。所以覺得別人經常鍛鍊身體也沒用。
爬一座海拔很高的山，很多人就爬不上，經常鍛鍊身體的人就很容易爬上。
但很多人潛意識還是覺得資料結構和演算法有用。不然就不會極客時間一推相關課程幾萬人購買…
16樓：oceanus
可以從國內軟體行業發展的階段來看，目前國內軟體公司多數還處於野蠻生長階段，市場上的程式設計師仍是供小於求，所以軟體公司普遍對程式設計師的要求並不高。
作為一般的程式設計師，掌握基本的程式設計知識，能讀懂框架或元件的文件，就可以滿足絕大部分的開發工作。但隨著行業的發展，軟體開發必將由現在的粗放式過度到精細化（其實很多大廠轉向精細化了，所以招聘要求很嚴苛），那時便需要借助演算法、作業系統、計算機網路、組成原理等這些基礎知識來進一步優化應用，降低軟體的執行和維護成本、提高開發效率、提公升使用者體驗等，從而讓公司在市場上更有競爭力。
目前很多人覺得學習演算法沒用，也是因為難以應用到工作中去，待行業邁向下乙個階段，學習演算法的價值便體現出來了。
17樓：內心悶騷的瓜皮
這個問題轉化乙個角度來看：現在的小初高數學越來越難學對學生有什麼用？我想大部分行業都用不上函式方程立體幾何這些吧？
很多人覺得沒用因為本來就不是很多人可以用得上的
18樓：折曜
前端菜雞說些自己的看法吧。
從前端角度來說，現在很多任務具都已經封裝好了很多實現，只需要調api就可以完成絕大部分需求，這就是俗稱的api工程師。同時前端並不會設計到太大的資料量，這時乙個n→nlogn的優化並不能得到太好的效果。的從這個角度來說，的確沒有學習資料結構的必要。
但是api工程師是沒有競爭力的，如果你想要了解一些框架的底層實現資料結構與演算法是並不可少的。舉個例子：vue 的虛擬dom 用到了樹，虛擬dom 的 patch 用了一種非常優美的演算法使得複雜度降到了n。
從這個角度來說，演算法很有用不是嗎？
學習演算法的目的是增加自己的核心競爭力，否則工作三年的你和剛畢業的應屆生有什麼區別呢？
19樓：LineCutFeng
演算法，對於自己的邏輯思維還是有很大提公升的，演算法能讓人頭腦更加靈活，日常的重複性增刪改查寫多了，介面UI畫多了，總有瓶頸的時候，複雜的業務邏輯，離不開演算法與資料結構去優化(主要是現在的硬體日益提公升，優化帶來的效果並不十分明顯,在上古程式設計時代，硬體資源十分有限，比如暫存器大小論kb計算，演算法的優化顯得尤其重要，)，有很多原始碼也用到了演算法，說沒用的，只是沒用到而已，畫個介面，有時候甚至用到三角函式，導數等等高中知識呢，數學才是推動計算機發展的強大動力，誰說沒用了？只是你沒用上而已（想做個普通碼農確實不用看演算法）。
職業選擇問題，演算法工程師 vs 軟體工程師
同樣有此困惑，無奈只好選擇coding了，可以見我這個問題 軟體行業求職方面的困惑，高深演算法還是Coding？程式設計 軟體開發也有好多好多崗位啊，沒法一概而論。選了軟體開發的壞處是，離科學很遠，數學什麼的基本就跟你沒什麼關係了。你就變成乙個工匠，乙個手藝人。好處是，現在網際網路發展快，程式設計師...
軟體工程師怎麼學習硬體知識？
Leo 建議你先學數位電路方面的，比較簡單學得快，先是邏輯門，暫存器。然後學各種匯流排協議，微處理器，nmos,pmos,估計就夠了。有一些電壓比較器鎖相環之類的要涉及模擬電路知識，就不是很好學了，你要先學電路分析 最基礎的 然後是模擬電路搞清三極體mos管這類的工作方式，然後是高階模擬電路比如說運...
作為軟體工程師 Software Engineer ，最應該學習的課程和技能Top10是什麼？
囈人61 在北美為什麼不繼續做飛機製造業相關的工作？那個專業更有前途。好吧，回到你的問題。作為軟體工程師和專案經理，我認為最重要的是 資料結構 演算法 清晰的注釋 溝通能力和邏輯思維能力 設計模式 快速查詢類庫的能力 快速定位問題，解決問題的能力 閱讀官方文件的耐心 資料庫知識 對業務的理解能力。 ...