什麼纔是真正的編程能力？

文章轉載自「開發者圓桌」一個關於開發者入門、進階、踩坑的微信公衆號

問：搭過幾個網站，在周圍人看來彷佛好像我很厲害，作了那麼多東西，可是我發現這些東西雖然是我作的，可是實際上我手把手本身寫的代碼卻並無多少，不少都是用開源的東西，我寫的代碼無非是把別人的東西整合下，相似於膠水同樣的工做。

 

我以前所認爲的編程是全手動一行一行敲代碼，可是如今我發現哪怕是工程上也有不少人是複製黏貼來解決問題的，而且提倡不要重複造輪子。

 

可是靠谷歌和複製別人的輪子，雖然我作出了不少東西，但是我並不以爲本身能力上有提高，卻是利用搜索引擎的能力的確提高了很多。而學校裏另一部分在搞ACM「ACM程序設計大賽是大學級別最高的腦力競賽，素來被冠以"程序設計的奧林匹克"的尊稱。」的人，他們天天都在刷題練算法，但單憑我我的的感覺感受他們彷佛對工程上有些東西並不瞭解，或許算法的能力纔算是實打實的編程能力？那"膠水"的能力和整合輪子的能力算不算編程能力呢?

 

因此我如今就很困惑，所謂的編程能力究竟是什麼？該如何提高本身的編程能力？

 

答：以問題爲導向，編程只是手段，歸根結底仍是解決問題的能力。

 

分清楚方向

 

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

 

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

 

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

 

因此比爾·蓋茨纔會說，看到如今學編程的人常常都把編程看做解各類腦筋急轉彎的問題，他以爲很遺憾。

 

以問題爲導向

 

真正的編程能力其實並非對語法細節的理解，也不在於手寫或者複製粘貼，更不在於對什麼操做系統的使用，或者經常使用庫的api的記憶。

 

而是找出解決方法的能力，把現實問題轉換爲代碼邏輯的能力。這個是最重要的。語法很好學，只要看一看，再不行網上搜一搜都有，可是解決問題的能力，在網上搜不到，找不來，誰也幫不了。只能在長期的分析問題解決問題的過程當中獲得。

 

在工做中，見過太多面試的時候打高分，把什麼const char*, char const*, char*const i+++++i 這種奇技淫巧玩的爛熟，解決問題的時候束手無策的。只能你清晰明瞭的告訴他流程他才能實現。這樣的人，要是不思進取，沉浸在這種不少公司禁用的語法技巧裏沾沾自喜，可能永遠只能是個代碼流水線工人。

 

也有不少人面試的時候各類語法都模棱兩可，提起作過的項目和程序，卻可以條理清楚，頭頭是道。給他一個問題，他幾分鐘就給出還不錯的解決方案。這樣的人，隨便什麼語言，什麼語法，什麼庫，對他來講都是工具。他知道與否，都能最終解決問題。

 

其實無論是複製黏貼也好，本身手寫也好，關鍵的是解決問題。編程最終仍是個生產工具，目的是解決問題，不能解決問題的，一切都是空中樓閣，毫無價值。

懂得取捨

 

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

 

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

 

問題在哪裏？

 

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

 

很聰明的人，也可能作出很難用的系統，不必定是編程很差，多是不肯，或不屑於取捨。不一樣的階段，不一樣的項目，要取捨的東西也不一樣。編程只是手段，目的是解決問題，能力高不高，要看問題解決的好很差。不在於使用了什麼高端算法，或是複雜的框架。

 

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

 

該如何提高本身的系統編程能力呢？

 

算法和數據結構有ACM競賽很容易評估能力的提高，而系統編程能力更多的表現爲問題解決能力和綜合知識應用能力，更加難以的評估和測量。所以，這裏只討論系統編程能力的提高問題。

 

作系統，確實不提倡「重複發明輪子」。但注意，是不提倡「重複發明」，不是不提倡「從新制造」。偏偏相反的，我覺得，系統的編程能力正體如今「從新制造」的能力。

 

能把已有的部件接起來，這很好。但當你剛好缺一種關鍵的膠水的時候，你能寫出來嗎？當一個已有的部件不徹底符合你的需求的時候，你能改進它嗎？若是你用的部件中有bug，你能把它修好嗎？在網上繁多的相似功能的部件中，誰好誰壞？爲何？差異本質嗎？一個開源代碼庫，你能把它從一個語言翻譯到另外一個語言嗎？從一個平臺移植到另外一個平臺嗎？能準確估計本身翻譯和移植的過程須要多少時間嗎？能準確估計翻譯和移植以後性能是會有提高仍是會有所降低嗎？

 

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

 

若是你一點不懂理論，仍是應該學點的。對於系統性能的設計上，算法和數據結構就像在本身手頭的錢同樣，它們不是萬能的，但不懂是萬萬不行的。

 

怎麼提升系統編程能力呢？土辦法：多造輪子。就像學畫畫要畫雞蛋同樣，不是這世界上沒有人會畫雞蛋，但畫雞蛋能馴服手指，感覺陰影線條和筆觸。因此，本身多寫點東西吧。寫個小玩意？編譯器？渲染器？操做系統？web服務器？web瀏覽器？部件都一個個換成本身手寫的，而後和已有的現成部件比一比，看看誰的性能好，誰的易用性好？好在哪兒？差在哪兒？爲何？

 

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

 

輪子很差拆，實際上是一個很是嚴重的問題。重複發明輪子當然是時間的浪費，但當輪子複雜而又很差拆的時候，尤爲是原來造輪子的人已經不在場的時候，從新發明和建造輪子每每會成爲無奈之下最好的選擇。這是爲何工業界在明知道重複發明/製造輪子很是很差的狀況下還在不斷重複發明/製造輪子的根本緣由。

 

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