1. 程式人生 > >我們應該怎樣來提高自己的程式設計能力?

我們應該怎樣來提高自己的程式設計能力?

    故天將降大任於是人也,必先苦其心志,勞其筋骨,餓其體膚,空乏其身,行拂亂其所為,所以動心忍性,曾益其所不能。      --《孟子》

       我曾經很是厭倦敲程式碼的日子,因為覺得,我所寫的程式,無論大小 ,其實都是拿別人的模組,按照自己的實際需要,稍微改動一下,再組合成來實現功能即可。我覺得這是一件沒有意思的事情,就像反覆的搬磚一樣。曾經我以為這是因為我“喜新厭舊”的性格使然,對自己這種厭倦程式設計的想法很內疚,直到看到了下面這篇來自知乎的文章 ,我才明白,其實自己的程式設計能力,在以前所重複使用輪子的時候慢慢提高,在折除別人的程式碼中得到了潛移默化。這是一個菜鳥必經的過程,就像你從嬰兒時期,模仿別人走路和講話,到最後自己自由奔跑和演講!以下是文章:

 

*********************************************************************************************************************************************************************

       電腦科學有兩類根本問題。一類是理論:演算法,資料結構,複雜度,機器學習,模式識別,等等等。一類是系統:作業系統,網路系統,分散式系統,儲存系統,遊戲引擎,等等等等。

       理論走的是深度,是在追問在給定的計算能力約束下如何把一個問題解決得更快更好。而系統走的是廣度,是在追問對於一個現實的需求如何在眾多的技術中設計出最多快好省的技術組合。
       搞ACM的人,只練第一類。像你這樣的更偏向於第二類。其實挺難得的,但很可惜的是第二類能力沒有簡單高效的測量考察方法,不像演算法和資料結構有ACM競賽,所以很多系統的苗子都因為缺少激勵和正確引導慢慢就消隱了。所以比爾蓋茨才會說,看到現在學程式設計的人經常都把程式設計看作解各種腦筋急轉彎的問題,他覺得很遺憾。
       做系統,確實不提倡“重複發明輪子”。但注意,是不提倡“重複發明”,不是不提倡“重新制造”。恰恰相反的,我以為,系統的程式設計能力正體現在“重新制造”的能力。能把已有的部件接起來,這很好。但當你恰好缺一種關鍵的膠水的時候,你能寫出來嗎?當一個已有的部件不完全符合你的需求的時候,你能改進它嗎?如果你用的部件中有bug,你能把它修好嗎?在網上繁多的類似功能的部件中,誰好誰壞?為什麼?差別本質嗎?一個開原始碼庫,你能把它從一個語言翻譯到另一個語言嗎?從一個平臺移植到另一個平臺嗎?能準確估計自己翻譯和移植的過程需要多少時間嗎?能準確估計翻譯和移植之後效能是會有提升還是會有所下降嗎?
       系統程式設計能力體現在把已有的程式碼拿來並變成更好的程式碼,體現在把沒用的程式碼拿來並變成有用的程式碼,體現在把一個做好的輪子拿來能畫出來輪子的設計藍圖,並用道理解釋出設計藍圖中哪些地方是關鍵的,哪些地方是次要的,哪些地方是不容觸碰的,哪些地方是還可以改進的。 如果你一點不懂理論,還是應該學點的。對於系統性能的設計上,演算法和資料結構就像在自己手頭的錢一樣,它們不是萬能的,但不懂是萬萬不行的。
       怎麼提高系統程式設計能力呢?土辦法:多造輪子。就像學畫畫要畫雞蛋一樣,不是這世界上沒有人會畫雞蛋,但畫雞蛋能馴服手指,感受陰影線條和筆觸。所以,自己多寫點東西吧。寫個編譯器?渲染器?作業系統?web伺服器?web瀏覽器?部件都一個個換成自己手寫的,然後和已有的現成部件比一比,看看誰的效能好,誰的易用性好?好在哪兒?差在哪兒?為什麼?
       更聰明一點的辦法:多拆輪子。多研究別人的程式碼是怎麼寫的。然而這個實踐起來經常很難。原因:大部分工業上用的輪子可能設計上的思想和技術是好的,都設計和製造過程都很爛,裡面亂成一團,讓人乍一看毫無頭緒,導致其對新手來說非常難拆。這種狀況其實非常糟糕。所以,此辦法一般只對比較簡單的輪子好使,對於複雜的輪子,請量力而行。
       輪子不好拆,其實是一個非常嚴重的問題。重複發明輪子固然是時間的浪費,但當輪子複雜而又不好拆的時候,尤其是原來造輪子的人已經不在場的時候,重新發明和建造輪子往往會成為無奈之下最好的選擇。這是為什麼工業界在明知道重複發明/製造輪子非常不好的情況下還在不斷重複發明/製造輪子的根本原因。程式本質是邏輯演繹的形式化表達,記載的是人類對這個世界的數字化理解。不能拆的輪子就像那一篇篇丟了曲譜的宋詞一樣,能讀,卻不能唱。

 

文章來源:https://blog.csdn.net/jiangjieqazwsx/article/details/48057277