回覆列表
  • 1 # IT人劉俊明

    首先,程式設計師需要有紮實的數學基礎,這一點是毋庸置疑的,因為程式設計說到底就是數學問題。數學基礎的作用體現在演算法設計上,而演算法設計則是程式設計的“核心”。

    演算法的應用最重要的因素是場景,最常見的演算法是應用最廣泛的演算法。對於程式設計師來說,如何把演算法與實際問題相結合是重點內容,所謂的高深演算法往往應用場景十分有限,效果也未必會比常見演算法好。

    比如在機器學習領域,K近鄰、決策樹、樸素貝葉斯、支援向量機等演算法被廣泛使用,也被業界所廣泛認可,是公認的重要演算法。在特定的場景下,把這些演算法與實際問題相結合並形成高效的解決方案,這是研發人員的重要任務。另外,基於常見演算法的改進是一個被廣泛採用的方案,這樣的方案往往具有更高的穩定性。

    演算法的設計需要一個系統的過程,需要大量的資料驗證才能形成最終的解決方案,所以雖然演算法的研究經過了這麼多年,但是被廣泛採用的演算法卻並不多。在解決問題的實際方案中,往往經典的演算法有更好的效果。所以,在程式設計師解決問題的過程中,並不會去追求演算法的複雜性,而是追求解決問題的時效性。

    作為一名研發級程式設計師,首先要做的是系統掌握經典演算法的設計與實現,然後在實際解決問題的過程中再針對特定的使用場景進行演算法的改進,這往往是一個系統的過程,也往往需要經過大量的實驗。

  • 2 # 大學生程式設計指南

    作為一個做了十幾年程式的老司機,現在做的時間越長越是對於精通兩個字避之不及了,無論是精通程式語言還是精通演算法之類的話,輕易都不會說出口,學的越多越覺得自己知識面的狹窄,演算法決定程式設計師的上限,有很多程式設計師對於演算法的意識比較淡薄,覺得沒有特別厲害的演算法也能把程式做的很不錯,這個涉及到一個問題,不是所有的程式設計師崗位都是必須把演算法搞得特別好,才能做程式設計師。其實很多程式設計師的崗位對於演算法的要求不是那麼強烈,演算法主要在遊戲或者大型資料計算上用的比較多。

    說到演算法在人工智慧上用的最廣泛,而且屬於比較深層次的演算法,數學基礎不過關,基本上玩不轉,很多公司招收人工智慧的程式設計師,誇張一點演算法的要求大於對編碼的要求,編碼能力時間長了可以彌補回來,但演算法不是一時半會就能學會的,對於數學的線性代數,微積分基礎知識用的特別頻繁,很多人覺得人工智慧就是簡單學個python就可以玩了,只是入口函式的呼叫而已,真正涉及到效能的演算法,大部分還是C/C++完成。

    術業有專攻,不是每個程式設計師都對演算法都會很熟悉,演算法和程式設計邏輯有一定的相通之處,很多人所說的程式設計需要一定的數學基礎就是指的演算法相關的東西。

    現在很多大公司在招聘程式設計師這關還會專門設計一些演算法的考驗,演算法也是程式設計師基本功的一種了,不是所有的程式設計師演算法能力都很強,但演算法強的程式設計師能力一般不弱。目前國內市場演算法工程師的待遇還是高於一般的技術工種,演算法是特殊的技術工種,初學者入門寫程式的過程中不要忽略其中演算法的作用。

  • 3 # 嵌入式宏思微想

    對於程式設計師來講,未必需要精通演算法。

    程式設計師又分為前端程式設計師,後端程式設計師。也分為應用程式設計師,底層程式設計師,系統程式設計師。從專業職能上又分為演算法程式設計師,非演算法程式設計師。從職級上又分程式設計師,高階程式設計師,專家程式設計師。除了演算法程式設計師之外,其他的一般都是瞭解,會用演算法即可。

    演算法程式設計師又分為三個層次:會用,會改,會寫。從瞭解,熟悉,到精通,是一個金字塔式的階梯成長。不是所有崗位都要求精通,畢竟行業環境就是應用為主,以產品為最終目標,功能實現和使用者體驗

    才是最重要的。如果你的產品就是演算法,也就是賣演算法的,那麼平臺化,移植化,介面化才是最重要的,一堆理論和虛擬碼,是無法落地實施的。

    演算法是軟體的核心之一,但不是全部。就像一棟大樓,有基礎,框架,砌磚,裝修等等工種,都很重要,缺一不可。演算法,聽起來比較高深,實際上技術含量也很高,理論能力要求高,所以比較受人羨慕和追求。

  • 4 # 青衣

    作為一名程式設計師,我說說我的看法。

    需要精通演算法嗎?其實在程式設計師這行業待的越久,就越來越不敢說自己精通哪方面了,知識就如同海洋,沒有進去的人是並不清楚其中的深邃和廣博。你學的越多,你瞭解的領域越廣泛,而每一個領域涉及到一些龐大複雜的具體知識,你又不可能完全瞭解,覺得自己知道的越少,所以很難說精通演算法。但是,你對演算法的理解程度,會決定你在程式設計領域的高度,所以對於演算法方面的知識當然是多多益善了。

    在公司裡,程式設計師一般分為兩種,一種是做業務的程式設計師,這種程式設計師主要工作是實現業務功能,只要熟練使用各種框架的API,就可以勝任,對於這種程式設計師,在實際工作中,很少用到演算法相關的知識,所以對他們而言,不精通演算法也沒什麼太大影響。另一種是提供底層支援的程式設計師,主要工作是,為專案提供底層支援,編寫基礎框架,編寫通用API,簡化專案開發的工程師。在他們的工作中,可能會大量使用設計模式,資料結構和演算法相關的知識,對這些程式設計師來說,演算法是他們必須掌握的基礎知識。

    總之,想要在程式設計師這行業走的更遠,還是需要努力地去學習設計模式,資料結構和演算法等等底層的基礎領悟的知識。

  • 5 # 電商和區塊鏈

    到底需不需要,這個得看你的志向和方向。

    如果你有志於軟體行業發展,在技術上有一番造詣,那當然是需要精通。因為你追求優秀,工作效率能達到其他程式設計師的十倍乃至百倍,那麼底層知識、演算法都是必備知識。你看起來高深的演算法,在優秀的人看來只是小菜一碟,這怎麼說?那麼高深不高深,這也是看人的。

    如果你只是覺得軟體行業,在目前的就業前景還可以,想混個飯碗,那麼只需要熟悉一些框架,熟悉API的呼叫,有問題就百度,那就不需要熟悉太多演算法,更不要說“高深”演算法。

  • 6 # 薛定諤的小貓貓

    太高深的演算法可以適當學一些,但比較常用的演算法肯定是要會才行。不光是演算法崗才需要學習那麼多演算法,開發崗同樣需要會很多常見的演算法,這樣在開發時才能寫出高效能程式碼。我先舉一個例子,之前我在用MR處理一份資料,其中在reduce階段時候需要根據某個值保留TOP 3000的資料,但是如果不會其它演算法,就呼叫快速排序,最壞時間複雜度為O(n^2),當資料比較大的時候基本上就跑不出來了,而如果會維護大頂堆或BFPRT演算法,時間複雜度大大降低。可見,演算法還是很重要的。

    那麼,我們具體需要學習哪些演算法呢? 我大概列舉下面的幾個方向

    字串類演算法

    比如常見的KMP、多模式匹配的AC自動機、字典樹等,特別是字典樹,在工程開發中確實很容易遇到的。

    圖論演算法

    常見的圖論演算法,如並查集、最短路徑演算法、二分圖匹配、網路流、拓撲排序等等。

    搜尋演算法

    比如常見的二分搜尋、三分搜尋,特別是二分搜尋,面試都經常會問到,深度優先搜尋和廣度優先搜尋,經典的八數碼問題等。另外還有一些啟發式搜尋,比如模擬退火、遺傳演算法、粒子群演算法、蟻群演算法等等。

    動態規劃演算法

    比如經典的揹包問題(可以參考揹包九講有更詳細的介紹),求最短路徑的dijkstra演算法,最大子段和、數位DP等。

    數學類演算法

    這類就比較大了,特別是在機器學習、人工智慧、密碼學等方向應用比較多。例如數論中的大數分解問題、大素數判斷問題、擴充套件歐幾里得演算法、中國剩餘定理、Lucas定理等等,組合數學中的博弈問題、卡特蘭數公式、容斥原理、Polya計數等,計算幾何中的極角排序、凸包問題、旋轉卡殼、多邊形核心問題、平面最近點對問題等。另外還有一些矩陣的構造計算,如矩陣快速冪等等。

    如果要搞演算法崗位,除了上述的一些應用演算法,主要還是以機器學習、深度學習方面的演算法為主。

  • 7 # 極客宇文氏

    看你想成為怎樣的程式設計師了

    首先“精通”二字一般的程式設計師都不敢亂用,在簡歷是往往都是寫“熟悉”。因為精通實在太難,沒有個十年八年,配不上這個詞。

    而“高深”的演算法,更是一般程式設計師不會觸碰的,尤其是寫業務程式碼的工作有幾年的程式設計師,別說高深的演算法了,能把常見的排序演算法全部手敲出來的都不多。

    原因很簡單,現在的軟體開發行業,普遍不需要自己寫演算法,你只需要用別人封裝的資料結構,就能滿足大部分功能開發的需求。對於業務程式碼的程式設計師,排序什麼的幾乎用不上。

    這就是精通高深演算法的現狀。

    然而高深的演算法如果能精通對程式設計師有多大影響,我可以說如果程式設計師能做到那一定是具有極高成就。到了這個地步相比也不用當程式設計師了,人家有別的名字——資深演算法工程師。

  • 8 # 飯特稀406

    這個問題首先看你怎麼定義“演算法”。

    純粹意義上的演算法指的是那些滿足單核CPU計算效率的數學邏輯,比如常見的排序演算法,加密演算法等。不客氣滴說,在真實的應用開發中並沒有多少機會讓你單獨去面對,即便你面對了也不會有好結果,因為好的演算法都是千錘百煉出來的,而且一旦寫了出來就基本上“全人類”共享,你就管呼叫就好了。但是我能理解那些喜歡在面試中出演算法題的考官,因為通常喜歡研究演算法的人都不會太笨,記憶力也不會太差,因此雖然演算法在實際開發中沒什麼鳥用,但是能解答出來的人基本上都夠聰明。注意,雖然解答不出來的人也未必就笨,但是在人才供大於求,又沒有其它有效的從眾多面試者中快速找出聰明者的辦法的情況下,考演算法不失為一種寧可錯過千人,也不選錯一人的辦法。但是放到人才供給不足的市場上,這種方法可能讓你招不到人。

    廣義上的“演算法”還包括對程式的整體效率具有重要影響的設計單元,比如功能函式的合理安排,執行緒的使用效率,執行緒鎖的適應範圍,訊息佇列的優先順序,甚至記憶體的分配與回收等等,這些更多涉及的是程式的結構/架構的演算法就至關重要了,其實一個優秀的程式設計師大部分時間都是在思考這些問題,甚至所花時間並不比堆疊業務程式碼的時間少,但是對這部分的演算法的考查一直是面試中經常被忽視的。

    還有一類演算法,就是現在機器學習領域中常提到的“演算法”,嚴格滴說那叫“建模”,真正的機器學習演算法參考第一條,你沒什麼機會去寫的,重要的是會用,懂得後面的原理就行,建模的過程,或者說實現所謂“演算法”的過程其實是個調參的過程。在你瞭解原理的前提下這部分並不是很難,難的是原理。

    所以演算法重不重要這個問題很難講,看你的目的和定義,簡而言之對鍛鍊思維能力和提高對程式的理解上來講,或許都重要;對純粹業務開發來講,結構演算法比數學邏輯演算法重要;對應付面試來講,數學邏輯演算法比結構演算法重要。對機器學習來講,兩者都不重要,統計學基礎最重要。

  • 9 # 稼軒說機器學習

    1. 演算法重要嗎?

    題主,看到你的問題,我想你的潛臺詞是在說,“現在計算機的效能已經這麼強大了,而且還有摩爾定律作支撐,會越來越強大,即使只用簡單的邏輯,或者不那麼優秀的演算法,運算時間照樣也差不了多少”。對嗎?

    說起來有點慚愧,其實最開始我也是這麼認為的。當我還在讀研期間,我導師給我說過這樣一句話,讓我受益匪淺。他是這樣說的:

    “永遠都要記住,計算機的效能不是留給程式設計師用的。”

    我恍然大悟,冥冥之中彷彿看到一個公式:

    計算機效能 = 常數 = F(使用者)+ F(程式設計師)

    歸根結底,使用者也是希望透過伺服器的算力,得到他想要的東西,而程式設計師編寫程式,也需要消耗部分算力,如果程式設計師用的越多,使用者得到的就越少,如果使用者得到的少了,體驗差了,怎麼留的住使用者呢?

    尤其是在如今,強調產品思維的網際網路環境下,使用者就是天,就是上帝,作為生產者的程式設計師,怎麼能去與使用者爭算力呢?我想,講到這裡,要表達的東西已經講清楚了。

    演算法,很重要,不光是真正的演算法工程師,即使是普通的走業務流程的SDE,學會演算法也非常重要。

    2. “高深”的演算法重要嗎?

    題主說到高深的演算法,我不太知道題主確切的指代的是什麼。

    現在說到的演算法,已經分為了兩塊,一塊是Algorithm,也就是我們傳統的演算法,另一塊是method,也就是現在最熱門的機器學習演算法。

    對於第一塊Algorithm,視崗位而定,如果是普通的研發崗,掌握最基本的圖,樹,連結串列等資料結構與演算法就可以了,如果是演算法工程師,其實是多多益善的。

    對於第二塊Method,不論是偏向應用的機器學習工程師,還是偏向research的機器學習工程師,都是要經常追論文,追會議的,出了什麼新鮮的方法,或者是能夠提升效果的小trick,都需要持續跟進,畢竟現在網際網路企業,很多都是結果為導向,對結果負責。沒有好的方法,怎麼能得到好的效果呢?

    3. 怎樣學演算法?

    這個學法主要還是看你是不是科班出身。

    如果你是科班的話,大可以把從前的教科書撿起來。最好的回顧與總結的書是下面這本,演算法導論。

    如果你不是科班出身,這個問題就比較複雜了。老實說,非科班出身學習資料結構與演算法還是有一定難度的,有時候會難到讓你從入門到放棄。所以,我推薦你先從MOOC網路上的一些公開課開始學起,比如說,非常著名的MIT的演算法導論公開課。

    這裡我就不放連結了,怕有廣告嫌疑,有需要請自行搜素。

    4. 結語

    其實資料結構與演算法,就是解決一個抽象化的實際生活中的問題,這對於培養理性唯物的思維習慣也是很有幫助的。希望題主能夠越學越好:)

  • 10 # abcdefghi98765432101

    演算法本身概念很寬泛。

    演算法劃分為最基礎演算法和資料結構,這個是要求必會。

    再複雜點就是動態規劃,貪心,回溯,這幾個演算法本身到不是特別難,難在變化的題特別多,對於常人,可能刷題更有效。這幾個演算法除了貪心能找到應用場合。動態規劃和回溯都找不到具體應用場合,我曾經問過專門搞這塊的人,這幾個演算法啥場景用,說半天也沒說出來,就說有用。我當時研究一些開源軟體,比如linux核心,tcpip,都沒看到這些演算法用武之地。就自以為這些演算法都是理論演算法,學者弄著玩的。

    直到有次看了一本書,講資料庫實現的,提到動態規劃演算法用在查詢最佳化。其實當時有本國內的書講查詢最佳化如何實現,把程式碼鋪開列印書上,胡亂寫些註釋,並沒有說明白演算法如何應用這個關鍵問題。當時給我觸動挺深。後來留意到發現很多基礎軟體裡面大量使用演算法,我們國內一般只是呼叫而已。opencv ffmpeg原始碼,全是演算法。國內水平就是照著開源用,或者改。

    演算法有個特點就是容易忘,畢竟工作用的不多,越複雜演算法忘的越厲害,曾經下功夫研究過的演算法實現,過了幾年再看有點陌生。還有的演算法確實燒腦,學起來就沒學透。

    再就是涉及演算法實現,特別複雜演算法儘可能使用權威開源的版本。比如紅黑樹,我前後找了三個部落格版本都是錯的,最後移植linux原始碼版才透過測試,太坑人。應用工程,還是嚴謹些。可以在一個好版本做二次開發。

  • 11 # 網際網路程式設計佈道師

    先說答案:不是必須精通演算法!!!!

    不是所有的程式設計師都需要精通演算法,比如前端開發的程式設計師對於演算法來說就沒有多大要求,但是一個程式設計師能走多遠,最大的決定因素就是---演算法!!!

    特別是最近比較火熱的 人工智慧 區塊鏈 大資料等對演算法要求還是蠻高的。

    因為人工智慧 區塊鏈 大資料等需要大量的演算法計算。

    所以從事這類工作的程式設計師基本都要求很高的學歷就是因為需要很高數學功底。

  • 12 # 百戰君

    作為一個程式設計師,需要精通高深的演算法嗎?

    具體問題具體分析。一般情況是不需要的,比如開發MIS系統的程式設計師是不需要掌握高深演算法的,平時工作基本用不到。

    但是在實現一些特殊需求時,往往才覺得書到用時方恨少,後悔平時不學習一些高深的演算法。比如資訊保安方面,檔案加密,內聯網資料加密,網路應用和資料庫查詢最佳化等需要自己編寫演算法,因為網上能查到的相關資料基本上都是理論性的,或者比較零碎,需要自己進一步整理、編寫和最佳化。

    我現在做機器視覺方面的程式設計,每個主要功能模組都需要自己寫演算法,說不上多高深,但是急著用,經過不斷積累,基礎搭好了,感覺越來越輕鬆。現在應用演算法,感覺只是把以前函式的概念換個稍稍高大上的叫法而已。比較而言,演算法更多地使用了數學工具。

    因此,作為一個程式設計師,精通高深的演算法是好事,但部分程式設計師如果不精通演算法,也是可以的。

  • 中秋節和大豐收的關聯?
  • 如何裝修辦公室比較美觀?