程式設計能力主要是演算法嗎？

dboy2016-12-19 21:27:28

程式設計是一個世界，演算法是這個世界的高山大河。但世界不只高山大河，有不起眼的平地，不壯觀的村子，交錯的道路，立體無限的空間。

演算法不只是哪種排序方式大O最好，還是當下哪個方法更合適。演算法不只是課本上的那些經典，更是正在發生的沒寫進課本的，解決生產問題的那些。

程式設計等於資料結構加演算法是學校老師愛說的，他們要簡化教學模型。

但你自己要學會擁抱世界的混亂，這才是程式設計師真正面對的。

知乎使用者2016-12-19 21:52:55

不是，只是演算法之外的能力很難進行標準化考核，所以很多時候只能考演算法。

二律背反2016-12-19 22:08:19

程式設計：搭積木

基礎程式設計能力：能把積木按照圖紙搭得又快又好

高階程式設計能力：熟悉每個積木快的效能（即熟悉基本的資料結構和基本的演算法 ——- 熟悉，表示“知道怎麼回事但不需要能親自用程式碼寫出來，能用虛擬碼描述清楚即可”）、能設計出最符合要求又易於操作的搭積木的圖紙

演算法：來我們研究下每個積木塊的內部細節，誰能把這些細節做得更優誰就是演算法高手

ACM競賽：來來來！我們來研究下這些幾萬年都不會用到的、幾百年內也難以商業化的積木的內部細節！！！（請輕噴）

科研機構/學校：我們會研究所有積木快包括那些幾百年內也難以商業化的積木的內部細節

大多數公司：我們是搭積木的

少數公司：我們主要也是搭積木的不過我們的積木比較專業所以我們也會做一些針對性很強的一般公司不會用到的積木快的內部細節研究

知乎使用者2016-12-29 18:25:00

不。程式設計是一個系統的工程，其中包含非常多種方面的能力。而對於程式設計所要解決的不同型別的任務而言，所需要的能力的側重點也完全不一樣。如果要列舉一下的話，我認為至少有如下。

程式設計的思想。也就是計算機解決問題的基本思路和模式，比如對於各種選擇，迴圈，遞迴控制過程的掌握。通常來說在人們學習第一門程式語言的時候實際上就是在學習這方面的技能。可以說面向過程，面向物件，函數語言程式設計等也是這個類別裡面。

對於程式語言的語法，規範，最佳實踐等的掌握。對於已經有1的基礎的，學習一點點基礎的語法即可很快的對另一門新的語言上手，這也是很多人說學習一門新的語言很簡單的原因。但是需要知道，每一門程式語言都有自己的細微的特點，要達到充分的掌握並非常熟練的使用，還是需要花費很多的功夫來學習的。

能夠對於要解決的特定的問題選擇更好的時間和空間開銷的解決方案的能力。通常來說也就是資料結構與演算法的能力。雖然演算法可能是一個非常宏大的概念（任何用計算機程式設計解決問題的方法你都可以叫做演算法），但是這裡我們可能主要側重於對於一個問題的時間和空間複雜度的分析和最佳化。

對於標準庫，系統API，以及第三方類庫的瞭解和熟練的使用。需要能夠知道這些庫的具體邏輯，能夠有能力快速的在文件中查詢到自己需要使用的合適的API，或者選擇使用合適的庫。

能夠合理的組織程式碼，達到易讀，易擴充套件，易於變更等。能夠對軟體專案的開發過程當中的各種方面進行合理的組織和管理。通常就是設計模式和軟體工程。

能夠對計算機系統本身有足夠的瞭解，對程式設計過程中直接或者間接使用的工具有足夠的瞭解。通常說來著意味著對於計算機組成，作業系統，編譯原理，網路原理等計算機系統基礎的深入學習。雖然計算機體系的設計都盡力的把下層封裝成一個黑箱，使得上層可以不用考慮黑箱中的細節。但是這種封裝其實不可能完全隔絕這種差異。很多時候你都需要對更底層的東西有更好的瞭解來幫助你設計上層的系統。這對於效能的提升和問題的排查實際上都有著很積極的作用。

對於要解決的問題相關的特定領域的知識。對於不同種類平臺的應用開發，計算機科學裡面的各個子領域如人工智慧，圖形學等。這涉及到你如何能夠應用程式設計的能力來解決實際的問題。

能夠熟練的使用一臺計算機，包括但不限於熟練的安裝各種軟體，解決系統問題，配置奇奇怪怪的開發環境。

有足夠好的英文閱讀能力，有足夠強的自學能力，有足夠強的在網際網路上有效的檢索資訊的能力。

有進行抽象的複雜邏輯思維的能力。

對於任何真實世界中的問題而言，都必然是一種系統的工程。這都涉及到綜合運用你擁有的能力和資源，對其進行合理的最佳化配置，對於要完成的目標進行必要的取捨。對於每一種不同的具體任務而言，對於以上每一種能力的要求都是不一樣的。簡單化的描述程式設計能力主要應該是什麼，都是不恰當的說法。

承志2016-12-30 00:25:08

問題相關：本科玩過ACM競賽，畢業之後做了開發，見過很厲害的開發也見過很厲害的演算法，算是有一點點眼界，厚著臉皮來達下這個問題。

以下回答純屬個人理解，不喜勿噴，說答主是菜雞也沒關係。

我講下我自己的故事吧，我儘量說生動一點，希望能夠幫到你。

我從大一開始就一直玩ACM，由於分心比較多，訓練也不算最刻苦的，所以在學校裡實力也就還行。因為一直沒放棄，多少有點積累，也算是拿了一點小獎。

憑著曾經ACM拿過的獎和一點點的運氣，在15年的時候拿到了阿里演算法崗的實習。直到我拿到實習offer之後，我才發現，原來演算法崗的實習要求和我理解的會的並不一樣。做過的人都知道，ACM比賽涉及到的其實是效能演算法。在規定的時限和空間內計算出要求的結果。並且這個結果是固定的。

而現在市面上大多數的演算法崗位，所涉及到的都是智慧演算法。也即是所謂的大資料演算法，這個詞逼格比較高，所以大家都愛用。這類演算法的特點呢，是基於海量的資料進行統計或者預測。就我個人的理解而言，更偏向於統計。這類問題一般來說沒有最優解，只有近似解，透過最佳化模型和方法，可以獲得更好的效果。

以上這些是我進了阿里之後，發現自己什麼也不會慢慢學習領悟到的。在我實習期間我做的事情，基本上都基於阿里的odps大資料平臺。利用平臺本身的高並行性計算能力，對於淘系內海量的資料進行篩選和處理。說得low一點，其實就是寫類SQL語句，巢狀Python寫的機器學習演算法指令碼進行資料處理。最後根據結果，修正引數，達到更好的效果。

原本我感覺實習期間的表現都還不錯，雖然機器學習方面的領悟還不夠，但是自己學得還是挺快的，而且搞過ACM，腦子好使，以後慢慢總能上道的。然而，不知道是我運氣好還是運氣差，我遇到了十年一遇的“擁抱變化”。我成了兩千多人中另尋下家的實習生中的一員，為了不至於餓死，在我投簡歷的時候我遇到了一個問題。

究竟是做開發還是做演算法？

比較逗的是，當時自己心智還不全，這種二選一的問題實在是糾結。在阿里待得久了，寫完SQL跑很久的日子真的是有些倦了。感覺對這樣的日子不太喜歡，太浪費時間。但是機器學習也學了，而且說實話開發那些除了Java會一點之外幾乎一竅不通。最後猶豫了很久，決定兩者都試一下，拿到哪個offer就幹哪個。當時覺得自己實在是太機智了。

開發我投的是現在的公司，演算法崗是當時的HRG內推的創業公司。（

我當時的HRG還是挺好的，阿里的hr也不像知乎裡說得這麼誇張。雖然我不記得她的花名了，不過還是很感謝她當時願意幫我

）

然而，不幸的是，這兩家我都拿到了offer……

經過了仔細思量和權衡，最終選擇了蘑菇街，具體的心路歷程在我的另一篇答案裡有寫。蘑菇街，網易，阿里校招offer選擇？ - 小狼MOUT 的回答 - 知乎

其實還是有點小後悔，自己本科搞了四年的演算法說放棄就放棄了，選了一條之前不太喜歡也不太擅長的路。

在我實習的時候，這種情緒來得尤為厲害。為什麼呢？因為感覺做的事情和我預期的完全不一樣。身邊的都是一群不懂演算法的人，寫的也是之前不太喜歡的Java語言。我不知道怎麼樣形容，也不是說覺得同事low，只是有一點點落空。

特別是當時帶我的師兄打開了debugger，單步跟蹤查錯的時候。我用詫異的眼神看了他一眼，因為在ACM玩家眼裡，debug應該都是用肉眼完成的。之前因為受到一些學長的引導，覺得開發要簡單很多，應該很快就能勝任，加上acmer的手速都比較快，所以當時的心態是比較激進的。

當然，沒過多久，我也用上了debugger。開發和演算法不同，程式崩潰的原因實在是太多了，程式碼有問題只是其中很小的一部分。很多錯不用debug根本無法排查。

然而當我畢業完了之後再次回到公司，現實立刻給了我一個下馬威。師兄太忙了，被調去了其他事情，之前巨大的專案丟給了我。我不僅要負責所有的需求，並且所有的問題也要一併承擔，從排查到修復，只能我一個人搞定。

SSM框架、公司的各種框架、網路架構、tomcat、maven這些我都幾乎一無所知，甚至連git也不是那麼熟練，更別說JVM那些比較高階的了。我感覺我之前搞ACM積累下來的程式碼能力完全成了空白，當時一度是比較低落甚至是有些悲觀的。

然後呢，然後我是怎麼剋制的呢？

不得不說，我遇到了一個很好的leader。他會給我們分享很多很多的技能，從他擅長的排查故障到JVM、多執行緒和一些框架等等。他分享完會讓我們做些總結，我比較聽話，每次都會總結。

到了這個時候，我才發現，其實開發要學的東西並不比演算法少。原本這就是兩個領域，架構、設計模式、面向容器或者是環境的調優等等，深挖起來可以挖的東西實在是太多。很多技術實力很深的人並不懂什麼演算法，甚至連排序都寫不出來，但這並不意味著可以否定他的程式設計技能。

舉個簡單的例子，這例子是我主管跟我講的。比如同一個需求，他實現和我實現同樣都是實現。然後會有什麼不同呢？我來實現，雖然都實現了，但是所有的東西都是寫死的。以後有類似的需求進來，還需要另外搞一套。如果是他寫，雖然花的時間差不多，但是就會做成可配置的，以後只需要改改配置，就能在其他的地方複用。這些還只是一個方面，還有穩定性、程式碼複用率等等講究。

言歸正傳，繼續講故事。當時受到主管的影響吧，自己遇到問題的時候也會多思考，這種問題出現的原因是什麼，解決的原理和方法是什麼，而不是簡單地把問題幹掉。其實開發的套路相對比較固定，問題的種類也就大概那麼一些。多踩個幾次坑，也就慢慢有經驗了。

在我努力學習技術的這段時間我發現了一個事情，就是同樣的東西我理解起來總要比別人快上一些。就比如我們公司無線端框架的原始碼，沒有人給我講過裡面的構造，就透過文件和啃程式碼，我能理出其中的設計模式。再比如業務需要用到狀態機，我大概在網上看個概念，就結合自己的業務進行實現。

不僅僅是後端這些，在我學前端ES和react甚至iOS開發的時候，也經常會有這種感覺。就有一種這東西原理好像在哪裡見過，一點就透的感覺。

為了這件事情我還奇怪了很久，直到後來和朋友的一次談話提醒了我。有過一個演算法崗的朋友，機器學習很牛的人。一直聲稱自己不會寫程式碼，以前我完全不信，能把機器學習翫這麼溜跟我說不會寫程式碼？不是搞笑麼？

直到後來我自己學了機器學習之後有一次幫一個線上獵頭公司面了幾個演算法崗的實習生，看著他們簡歷裡少得可憐的開發專案，以及隨便問幾個簡單的思維問題都想不出一個很好的答案。不就像我當時實習的時候，面對一大堆開發問題一籌莫展的樣子麼？

恍然大悟，原來朋友所言非虛。這才發現之前陷入了一個誤區，之前一直有一招先吃遍天的想法，認為演算法厲害到一定程度，程式設計肯定也厲害。

那時才一下子明白過來：演算法能力從來就不等於程式設計能力，程式設計能力是一個比較空泛的概念，裡面涵蓋的東西太多，和方方面面都有交集。甚至有些研究統計和數學的教授雖然不懂程式碼也可以看做是半個程式猿，畢竟他們對程式需要的邏輯和所需的技能掌握到了非常高深的地步。翻下語法書就能上手寫程式碼，你能說他們沒有程式設計能力麼？

所以問題程式設計能力的主要是不是演算法本身就是一個偽命題，單單什麼是程式設計能力就可以說上半天，都不一定有人能夠說得清楚。而且一個集合大到了一定程度，很難分清到底什麼是主什麼是次。

那麼你可能又要問了，為什麼演算法不是程式設計能力的主要部分，各個公司還那麼看重呢？

這個問題就要簡單很多了，原因也比較多。

首先，開發能力不是很好衡量。單單從面試問幾個問題，或者看一看你做過的專案並不能很快並且精準地衡量出一個人的開發水平。我可能之前在的專案組接的專案比較水，但是我的架構寫得特別清晰，程式碼質量很高。但是你只看簡歷說不定就會覺得這個專案沒啥技術含量。但是演算法就不同了，一些複雜的算法理解起來就很有難度。你能理解並且掌握，本身就已經說明了實力。更不用說ACM之類的演算法還能拿來比賽，你什麼實力，和其他人比一比就知道了。（微軟、谷歌等公司都是這麼幹的，而且都有自己舉辦的比賽）

其次，雖然不能說演算法是程式設計能力的主體，但是它真的對人鍛鍊作用比較大。有點像是武俠小說裡的內功，同樣的三年時間，你學三年劍法就可以當街殺人。我練三年內功啥也不是，但是，假如再給三年時間，我們再練三年，結果說不定就完全不一樣了。例子可能不是特別恰當，但是大概這麼個意思。

一些演算法對於解決業務和架構問題非常有借鑑意義，學過演算法的人上手什麼的都要比沒有學過的人快很多，這也就是為什麼我感覺當時學那些都比較快。

對於企業來說，演算法比較容易透過比賽等途徑衡量，並且也客觀反映了一個人在程式設計上的潛力。而且做過ACM的人一般都在程式的效能上比較有追求，比如儘可能地減少記憶體開銷降低複雜度等等。像是谷歌這樣的公司將演算法當做敲門磚，可能也有看重這些的原因吧。