什麼才算是真正的編程能力?

問題：什麼才算是真正的編程能力？

還在讀書，也在實驗室幫忙做了些東西，自己也搭過幾個網站。在周圍人看來似乎好像我很厲害，做了那麼多東西，但是我發現這些東西雖然是我做的，但是實際上我手把手自己寫的代碼卻並沒有多少，很多都是用開源的東西，我寫的代碼無非是把別人的東西整合下，類似於膠水一樣的工作。

我之前所認為的編程是全手動一行一行敲代碼，但是現在我發現哪怕是工程上也有很多人是複製黏貼來解決問題的，並且提倡不要重複造輪子。

但是靠穀歌和複製別人的輪子，雖然我做出了很多東西，可是我並不覺得自己能力上有提升，倒是利用搜索引擎的能力的確提升了不少。而學校裏另外一波搞ACM的人，他們每天刷題練算法，或許倒是的確提升了點編程能力，但是對工程幾乎一竅不通。

所以我現在就很困惑，所謂的編程能力到底是什麼，我該如何提升自己的編程能力？

回答者：劉賀

非常好的一個問題。這可能是我在知乎見到過的問編程有關的問題中問得最好的一個了。我非常喜歡這個問題。

計算機科學有兩類根本問題。一類是理論：算法，數據結構，複雜度，機器學習，模式識別，等等等。一類是係統：操作係統，網絡係統，分布式係統，存儲係統，遊戲引擎，等等等等。

理論走的是深度，是在追問在給定的計算能力約束下如何把一個問題解決得更快更好。而係統走的是廣度，是在追問對於一個現實的需求如何在眾多的技術中設計出最多快好省的技術組合。

搞ACM的人，隻練第一類。像你這樣的更偏向於第二類。其實挺難得的，但很可惜的是第二類能力沒有簡單高效的測量考察方法，不像算法和數據結構有ACM競賽，所以很多係統的苗子都因為缺少激勵和正確引導慢慢就消隱了。

所以比爾蓋茨才會說，看到現在學編程的人經常都把編程看作解各種腦筋急轉彎的問題，他覺得很遺憾。

做係統，確實不提倡“重複發明輪子”。但注意，是不提倡“重複發明”，不是不提倡“重新製造”。恰恰相反的，我以為，係統的編程能力正體現在“重新製造”的能力。

能把已有的部件接起來，這很好。但當你恰好缺一種關鍵的膠水的時候，你能寫出來嗎？當一個已有的部件不完全符合你的需求的時候，你能改進它嗎？如果你用的部件中有bug，你能把它修好嗎？在網上繁多的類似功能的部件中，誰好誰壞？為什麼？差別本質嗎？一個開源代碼庫，你能把它從一個語言翻譯到另一個語言嗎？從一個平台移植到另一個平台嗎？能準確估計自己翻譯和移植的過程需要多少時間嗎？能準確估計翻譯和移植之後性能是會有提升還是會有所下降嗎？

係統編程能力體現在把已有的代碼拿來並變成更好的代碼，體現在把沒用的代碼拿來並變成有用的代碼，體現在把一個做好的輪子拿來能畫出來輪子的設計藍圖，並用道理解釋出設計藍圖中哪些地方是關鍵的，哪些地方是次要的，哪些地方是不容觸碰的，哪些地方是還可以改進的。

如果你一點不懂理論，還是應該學點的。對於係統性能的設計上，算法和數據結構就像在自己手頭的錢一樣，它們不是萬能的，但不懂是萬萬不行的。

怎麼提高係統編程能力呢？土辦法：多造輪子。就像學畫畫要畫雞蛋一樣，不是這世界上沒有人會畫雞蛋，但畫雞蛋能馴服手指，感受陰影線條和筆觸。所以，自己多寫點東西吧。寫個編譯器？渲染器？操作係統？web服務器？web瀏覽器？部件都一個個換成自己手寫的，然後和已有的現成部件比一比，看看誰的性能好，誰的易用性好？好在哪兒？差在哪兒？為什麼？

更聰明一點的辦法：多拆輪子。多研究別人的代碼是怎麼寫的。然而這個實踐起來經常很難。原因：大部分工業上用的輪子可能設計上的思想和技術是好的，都設計和製造過程都很爛，裏麵亂成一團，讓人乍一看毫無頭緒，導致其對新手來說非常難拆。這種狀況其實非常糟糕。所以，此辦法一般隻對比較簡單的輪子好使，對於複雜的輪子，請量力而行。

輪子不好拆，其實是一個非常嚴重的問題。重複發明輪子固然是時間的浪費，但當輪子複雜而又不好拆的時候，尤其是原來造輪子的人已經不在場的時候，重新發明和建造輪子往往會成為無奈之下最好的選擇。這是為什麼工業界在明知道重複發明/製造輪子非常不好的情況下還在不斷重複發明/製造輪子的根本原因。

程序本質是邏輯演繹的形式化表達，記載的是人類對這個世界的數字化理解。不能拆的輪子就像那一篇篇丟了曲譜的宋詞一樣，能讀，卻不能唱。

鄙人不才，正在自己研究怎麼設計建造一種既好用又好拆的輪子。您沒那麼幸運，恐怕是等不到鄙人的技術做出來並發揚光大了。在那之前，多造輪子，多拆好拆的小輪子，應該是提高編程能力最好的辦法了。

以上。嗯。

（文章屬個人觀點，與本人工作雇主無關。）

回答者：mu
peng，less is more

懂得取舍。

在有限的時間內，幾乎沒有係統可以做到完美。要快，要安全，高並發，易擴展，效率高，容易讀，高內聚，低耦合...

大到一個網站，小到幾個class，工程師都要清楚，要取什麼，舍什麼，這並不是那麼容易的事。我們都有自己的性格，有的求新，有的求穩，有的求快，但具體到一個項目時，知道如何取舍對這個項目最好，很重要。

學校裏的作業，沒人在意你是不是寫在一個大的main()裏麵，能跑就行。但做項目的時候，太多的東西要考慮，有時候，寧可簡單易讀，也不用快那麼一點點；有時候，要做太多看不到的工作，卻絲毫馬虎不得；有時候，寫了不如不寫，留白也是一個學問。

曾經接手個項目，裏麵幾乎所有的class，每個都有interface，各種繼承，各種實現，理由是靈活性高，易擴展。真的易擴展嗎？

我不知道。沒多久，客戶的需求就改了，各種拎不清的繼承實現都化為烏有，一大半要重寫。

問題在哪裏？

不是編程不好，而是取舍的不好。在那個階段，為30%的需求，花200%的努力，追求設計的滴水不漏，卻舍棄快速實現，取得反饋的時機，這就是失誤。需求總會變，客戶看到越早，修改越早，影響越小。

很聰明的人，也可能做出很難用的係統，不一定是編程不好，可能是不願，或不屑於取舍。不同的階段，不同的項目，要取舍的東西也不同。編程隻是手段，目的是解決問題，能力高不高，要看問題解決的好不好。不在於使用了什麼高端算法，或是複雜的框架。

懂得如何取舍並不容易，需要對問題的深刻理解，對技術的胸有成竹，和身後無數個踩過的坑。但重要的是有取舍的意識，主動思考取舍什麼，這樣學的才會快。

回答者：李遙，A
Programmer

既然說的是編程能力，那首先就先把學術相關的能力排除才能說的清楚

接下來是我對編程的定義：所謂編程，就是預先設計好方案來指揮行為可預測的係統來自動（與臨時手動相對）達到的想要的結果。從廣義上說，企業家對一個公司的運作方式進行設計，然後這個公司自動運行產生利潤也是一種編程

那麼編程能力體現在兩點

1.對可預測係統的理解：理解越深，預測能力越強，自己的智慧才越好發揮。這就是為什麼學習軟件編程最快的方式之一是“造輪子”

2.如何把自己的目標轉化成指揮方案，這其實就是“做應用題”的能力，我們從小學就在練習這個能力。現實世界的應用題可不會告訴你用什麼知識點去建模，也不會透露全部必要條件，因此增強這個能力需要深刻理解現實世界的運作方式。在軟件行業，這被稱作“理解垂直行業的業務邏輯”

順帶說一下，所謂“Hacking”，其實就是在深刻理解一個係統的基礎上，用最小的代價改變這個係統來達到自己的目的。“Hacking”之所以看起來出人意料，就是因為理解越深刻，需要的做的改動越少。如果理解不深刻，那就要從頭造一個係統了，那就不聰明了

回答者：丁盛豪，網絡媒體HeckPsi.com創始人

謝 @花滿樓 邀請。

對於編程能力這個問題其實我也想過很久，這個東西確實非常難界定。單純靠算法水平、編程速度、工程經驗都很難說是編程能力。

雖然這個東西的影響因素非常龐大，但從我日常的工作來看，其實我覺得衡量編程水平最靠譜的方法是觀察這個程序員 Debug 的能力。

程序從本質上來說就是 輸入 -> 處理 -> 輸出 的過程，而中間的處理就像是一個巨大的黑盒子。而這個黑盒子的本身就是程序，在大多數情況下你並不能看到這個黑盒子的全貌。從常識上寫一個不存在 bug 的程序是一件 幾乎 不可能完成的任務。即使是敲個最簡單的 Hello World 程序，你也很難保證編譯器不給你抽幾下風。尤其是當這個程序變得非常龐大時，寫程序這件事的本身就是 盲人摸象 的過程。程序員必須要有相當好的 全局觀 ，才能保證自己的程序良好運行而不出問題，並能在出了問題之後能夠做出迅速的定位和修複。

所以觀察一個程序員能否 迅速Debug 的過程就是一個很好的判斷依據。我舉個例子來說，我幾周前給手機刷了機，第二天早上準備去晨跑，發現手機 GPS 不工作。於是我立刻分析了出現問題可能的地方：

GPS 模塊硬件 -> GPS 驅動 -> 係統配置 -> GPS 權限 -> 軟件兼容性

由於想起剛刷了機，基本可以排除硬件問題。而軟件之前同樣在其它 Android 5.1 機器上跑過，同時跑了下 Google Maps 也不能定位，排除兼容性問題。原生係統的權限係統非常簡單，基本排除是權限。出問題的可能是第三方 ROM 的驅動有問題或者配置文件。觀察到 A-GPS 基站輔助定位也不工作，基本排除 GPS 驅動問題。確認是配置文件有問題，檢查 /etc/gps.conf 竟是空文件。於是就在手機上用文本編輯器順手碼了一段配置，重啟後問題修複。

這就是一次非常流暢準確的對一個未知的 Bug 定位和修複的過程。

由於 Bug 的未知性，可以很好避免一些你在判斷時可能遇到的 作弊 情況，我們知道現在很多人為了麵試無所不用其極。就算是以前非常經典的麵試問題，現在也很不靠譜。現在你問 “如何理解麵向對象編程？” 和你對答如流的人可能並不真正理解 OOP，不過背的很熟而已。以前覺得算法是個很好驗證水平的切入點，自從 LeetCode 背題流的出現，這招現在也不怎麼靠譜。而 Debug 是個無法 提前準備的東西，所以對於編程能力的校驗通常很準確。

而且，Debug 的過程中會接觸到自己很多不熟悉的知識。由於編程本身就是一個 Engineering，正常的過程就是在 碼字 -> 出問題 -> 學習 -> 修改 的過程中循環。如果你對算法不熟悉，那麼遇到程序性能問題的時候你硬著頭皮也要用學習算法知識來解決掉。所以這是一項非常綜合的能力，是程序員 知識、智力、經驗 的綜合體現。

至於如何提升編程能力？

多寫、多錯、多學。沒有捷徑，捷徑隻不過是作弊。作弊能幫你找到工作，但並不能真正解決問題。

回答者：陳浩駿，call
me Reid / 會寫Java的猴子

MIT算法導論第一堂課:

每天都編程 x年後一定會變成專家 (忘了x多少 不是重點

輪子多造多模仿 能力自然提升

什麼發展都是從量到質的 要相信

現在我也是搞係統編程 除了看source code和造輪

也是可以有空刷刷acm的

而且隻有幫助沒有壞處喔

係統編程一旦考慮到效能問題 離不開經典的一些算法的

顯然大部分的我們都不會成為高手如溫趙輪

但是成為編程好手 進個好公司 錢多賺些 生活舒服些 應該是普遍程序員的共同目標

不要想太多 拚命code就是了

共勉

如此。

回答者：vczh，專業造輪子 https://github.com/vczh-libraries
都不知道宣傳不要重複造輪子的人是懷著什麼險惡的用心，原話明明是不要重新發明輪子。

這是什麼意思呢？就是說你要多看論文多看書，少抄代碼。

回答者：達達，服務端程序員

程序員就是把人類的需求語言翻譯成計算機語言的人，所以可以通用譯事三難：“信、達、雅”。

回答者：Kim
Leo

其實，搭網站，寫MIS/CMS/ERP這些，就算是一行行的寫代碼，結果也隻能是你的領域知識不斷提升，對於“編程能力”的提升沒有多少的。就像是你根本無法解釋在你寫的係統中哪個地方應用了動態規劃一樣。

所以相對來說你所需要的是一些計算機科學內的領域知識。

還有，假如你寫了代碼要給別人看和給其他程序員用，應該就開始慢慢考慮接口和設計了。

或者你需要的是一本分析模式？

回答者：JX
Consp

看看別人的輪子的形貌（主要是接口，其次是效率）之後自己造一個輪子

其實 STL 源碼剖析 和 modern c++ design 不錯，唯一問題是選擇了 c++ 做教學語言

有興趣可以學點認知和設計來了解好的接口長得是怎樣的

回答者：海濤，軟件開發需要低成本、快速響應

第1層：能做成東西（能運行）

第2層：做的東西能長時間或高負荷地運行

第3層：做的東西能長時間在高負荷下運行

第4層：能預先知道什麼才是客戶/行業需要的功能，並以最符合的代價（金錢、硬件、期限、人力）實現