演算法當然不是最重要的，這在絕大多數情況下是正確的。你主管的觀點基本正確。

作為技術人員，你工作的目標是什麼？首先是滿足業務需求。技術主管關心的是進度，質量，成本，風險等因素。至於演算法，在他看來可能只是錦上添花的事情。比如系統設計要求響應時間是3秒，目前是兩秒，你透過演算法最佳化達到了1秒，但這並沒有改變專案的業績。

現在覺大多數程式設計師實現功能也只是呼叫現有的程式碼庫中的方法，這些類庫覺大多數都能滿足需求。你也不需要自己實現一個連結串列，一個二叉樹，更不可能搞出來一個新的排序演算法等。利用這些現有的程式碼庫，怎麼都能把功能做出來，而且不止一種方式，所以所謂的演算法在看起來就沒那麼重要了。

所以，你應該先深刻了解需求，然後實現它。然後在考慮演算法的問題。這應該就是你主官的本意吧。

任何技術的理論都需要相應的土壤，才能發光發亮。其工作內容是透過演算法或大資料等手短實現功能和最佳化解決方案，只要在能夠提供這類工作的企業工作，才能談得上深入研究，否則都是自己琢磨，這樣學習的成本過高，達到的效果不好。作為前輩的程式設計師建議保守的方案當然是正確的。

其次演算法是程式設計師行業的一個小工種而已。大多數是面向業務進行邏輯程式碼書寫的。對於多數人多數情況而言只有邏輯程式碼寫好了，才有可能獲得演算法工程師的工作。

單純盲目的追求演算法的學習，很多可能落得紙上談兵，浮漂起樓的窘態。

這也是中國軟體開發的現狀，中國大部分程式設計師的工作基本上就是面向業務進行程式設計，還有做些系統整合，用到的演算法也都是比較常見的那一類，技術難度不大，要求的是知識的廣度和對業務的熟悉程度。結果就是我們的程式設計師的職業生涯貌似到了三十幾歲如果不能升任管理崗位就會感到職業危機。如果是想走技術路線的程式設計師，演算法就是必修，同時必須學好，這個世界一直在快速變化，系統架構在不斷演進，業務也在不斷變化，但演算法的變化卻少之又少。人的精力是有限的，我們很難一直保證自己有快速的學習能力，年輕時掌握不變的東西是延長職業生涯極其有效的方式。

因為大多數工作內容是處理業務邏輯，搞清楚業務流程就行，演算法用的不多都是簡單的，網上找找貼上去就行。絕大部分應用產品沒有什麼難度大的演算法。除非你做數學建模，圖形影象，生物計算等，否則基本上流程圖就是工作的全部核心

講真，我們都明白專案運用的重要性，但是江湖上有一句話：“無演算法，不程式”。

如果把程式看成一輛汽車，那麼程式語言就構成了這輛車的車身和輪胎。而演算法則是這輛車的核心——發動機。

這輛車跑得是快是慢，關鍵就在於發動機的好壞（當然輪胎太爛了也不行），而資料結構就是用來改造發動機的。

演算法就是程式的靈魂，一個需要實現特定功能的程式，實現它的演算法可以有很多種，所以演算法的優劣決定著程式的好壞。

在早期的程式設計師可能對演算法的認識不足，認為演算法的研究是那些演算法工程師的事情，對於普通的程式設計人員的用處是很小的。

總感覺資料結構和演算法是“屠龍技”、“虛招式”，除了面試，工作中根本用不著。

不懂演算法，只要程式語言API、開發框架用得熟練，程式碼照樣寫得“飛”起來。

語言是我們走向更高階的程式設計的必經之路，如果不能在演算法方面有自己的建樹，軟體程式設計做到頭也就是一個碼農而已。

技術大牛和普通程式設計師在相同工作時間內，大牛的完成率通常是普通程式設計師的兩倍

這就是資料結構與演算法的神奇之處，能幫你碼出更快更優質的程式碼。

普通程式設計師，只擁有單身20年的手速，只能用框架寫CRUD。

高階程式設計師，必須擁有【資料結構和演算法】內功，才能以氣馭劍，獨霸江湖。