伯樂線上小編注：本文綜合整理自知乎同名問答帖。題主的問題補充如下：
還在讀書，也在實驗室幫忙做了些東西，自己也搭過幾個網站。在周圍人看來似乎好像我很厲害，做了那麼多東西，但是我發現這些東西雖然是我做的，但是實際上我手把手自己寫的程式碼卻並沒有多少，很多都是用開源的東西，我寫的程式碼無非是把別人的東西整合下，類似於膠水一樣的工作。
我之前所認為的程式設計是全手動一行一行敲程式碼，但是現在我發現哪怕是工程上，也有很多人是複製黏貼來解決問題的，並且提倡不要重複造輪子。
但是靠谷歌和複製別人的輪子，雖然我做出了很多東西，可是我並不覺得自己能力上有提升，倒是利用搜尋引擎的能力的確提升了不少。而學校裡另外一部分在搞ACM的人，他們每天都在刷題練演算法，但單憑我個人的感受感覺他們似乎對工程上有些東西並不瞭解，或許演算法的能力才算是實打實的程式設計能力？那”膠水”的能力和整合輪子的能力算不算程式設計能力呢?
所以我現在就很困惑，所謂的程式設計能力到底是什麼，我該如何提升自己的程式設計能力？
下面是 劉賀 的回覆：（伯樂線上已徵得同意）
非常好的一個問題。這可能是我在知乎見到過的問程式設計有關的問題中問得最好的一個了。我非常喜歡這個問題。
電腦科學有兩類根本問題。一類是理論：演算法，資料結構，複雜度，機器學習，模式識別，等等等。一類是系統：作業系統，網路系統，分散式系統，儲存系統，遊戲引擎，等等等等。
理論走的是深度，是在追問在給定的計算能力約束下如何把一個問題解決得更快更好。而系統走的是廣度，是在追問對於一個現實的需求如何在眾多的技術中設計出最多快好省的技術組合。
搞ACM的人，只練第一類。像你這樣的更偏向於第二類。其實挺難得的，但很可惜的是第二類能力沒有簡單高效的測量考察方法，不像演算法和資料結構有ACM競賽，所以很多系統的苗子都因為缺少激勵和正確引導慢慢就消隱了。
所以比爾蓋茲才會說，看到現在學程式設計的人經常都把程式設計看作解各種腦筋急轉彎的問題，他覺得很遺憾。
做系統，確實不提倡“重複發明輪子”。但注意，是不提倡“重複發明”，不是不提倡“重新制造”。恰恰相反的，我以為，系統的程式設計能力正體現在“重新制造”的能力。
能把已有的部件接起來，這很好。但當你恰好缺一種關鍵的膠水的時候，你能寫出來嗎？當一個已有的部件不完全符合你的需求的時候，你能改進它嗎？如果你用的部件中有bug，你能把它修好嗎？在網上繁多的類似功能的部件中，誰好誰壞？為什麼？差別本質嗎？一個開原始碼庫，你能把它從一個語言翻譯到另一個語言嗎？從一個平臺移植到另一個平臺嗎？能準確估計自己翻譯和移植的過程需要多少時間嗎？能準確估計翻譯和移植之後效能是會有提升還是會有所下降嗎？
系統程式設計能力體現在把已有的程式碼拿來並變成更好的程式碼，體現在把沒用的程式碼拿來並變成有用的程式碼，體現在把一個做好的輪子拿來能畫出來輪子的設計藍圖，並用道理解釋出設計藍圖中哪些地方是關鍵的，哪些地方是次要的，哪些地方是不容觸碰的，哪些地方是還可以改進的。
如果你一點不懂理論，還是應該學點的。對於系統效能的設計上，演算法和資料結構就像在自己手頭的錢一樣，它們不是萬能的，但不懂是萬萬不行的。
怎麼提高系統程式設計能力呢？土辦法：多造輪子。就像學畫畫要畫雞蛋一樣，不是這世界上沒有人會畫雞蛋，但畫雞蛋能馴服手指，感受陰影線條和筆觸。所以，自己多寫點東西吧。寫個編譯器？渲染器？作業系統？web伺服器？web瀏覽器？部件都一個個換成自己手寫的，然後和已有的現成部件比一比，看看誰的效能好，誰的易用性好？好在哪兒？差在哪兒？為什麼？
更聰明一點的辦法：多拆輪子。多研究別人的程式碼是怎麼寫的。然而這個實踐起來經常很難。原因：大部分工業上用的輪子可能設計上的思想和技術是好的，都設計和製造過程都很爛，裡面亂成一團，讓人乍一看毫無頭緒，導致其對新手來說非常難拆。這種狀況其實非常糟糕。所以，此辦法一般只對比較簡單的輪子好使，對於複雜的輪子，請量力而行。
輪子不好拆，其實是一個非常嚴重的問題。重複發明輪子固然是時間的浪費，但當輪子複雜而又不好拆的時候，尤其是原來造輪子的人已經不在場的時候，重新發明和建造輪子往往會成為無奈之下最好的選擇。這是為什麼工業界在明知道重複發明/製造輪子非常不好的情況下還在不斷重複發明/製造輪子的根本原因。
程式本質是邏輯演繹的形式化表達，記載的是人類對這個世界的數字化理解。不能拆的輪子就像那一篇篇丟了曲譜的宋詞一樣，能讀，卻不能唱。
鄙人不才，正在自己研究怎麼設計建造一種既好用又好拆的輪子。您沒那麼幸運，恐怕是等不到鄙人的技術做出來併發揚光大了。在那之前，多造輪子，多拆好拆的小輪子，應該是提高程式設計能力最好的辦法了。
以上。嗯。
（文章屬個人觀點，與本人工作僱主無關。）
（小編轉註：http://zhuanlan.zhihu.com/shanhu 這是劉賀的專欄。）
下面是 mu mu 的回覆：（伯樂線上已徵得同意）
懂得取捨。
在有限的時間內，幾乎沒有系統可以做到完美。要快，要安全，高併發，易擴充套件，效率高，容易讀，高內聚，低耦合…
大到一個網站，小到幾個class，工程師都要清楚，要取什麼，舍什麼，這並不是那麼容易的事。我們都有自己的性格，有的求新，有的求穩，有的求快，但具體到一個專案時，知道如何取捨對這個專案最好，很重要。
學校裡的作業，沒人在意你是不是寫在一個大的main()裡面，能跑就行。但做專案的時候，太多的東西要考慮，有時候，寧可簡單易讀，也不用快那麼一點點；有時候，要做太多看不到的工作，卻絲毫馬虎不得；有時候，寫了不如不寫，留白也是一個學問。
曾經接手個專案，裡面幾乎所有的class，每個都有interface，各種繼承，各種實現，理由是靈活性高，易擴充套件。真的易擴充套件嗎？
我不知道。沒多久，客戶的需求就改了，各種拎不清的繼承實現都化為烏有，一大半要重寫。
問題在哪裡？
不是程式設計不好，而是取捨的不好。在那個階段，為30%的需求，花200%的努力，追求設計的滴水不漏，卻捨棄快速實現，取得反饋的時機，這就是失誤。需求總會變，客戶看到越早，修改越早，影響越小。
很聰明的人，也可能做出很難用的系統，不一定是程式設計不好，可能是不願，或不屑於取捨。不同的階段，不同的專案，要取捨的東西也不同。程式設計只是手段，目的是解決問題，能力高不高，要看問題解決的好不好。不在於使用了什麼高階演算法，或是複雜的框架。
懂得如何取捨並不容易，需要對問題。