如何提升程式技巧?這問題很大程度上是個開放性的問題,IT產業界可能還沒有出現統一的答案。每個人的學習和思考方式的差異,可能心中的答案都無法不徑相同。以下就總結一些個人和網頁中比較流行和大眾的看法,為程式設計師和開發者提供一些意見和建議,為朋友們的程式設計學習之路提供幫助。
1. 計劃
在程式開始之時,制定一個計劃,擬定設計框架並實現它。並重複該操作。透過編寫程式碼是學習程式碼的做好方式。 你將在錯誤中不斷的學習、提升自己,相比於看書完成專案更有激勵性同時也帶你帶來更多的樂趣。設計階段就要想好各個模組、物件間的關係和交互,控制、資料如何流動等重要細節。如果有模式或最佳實務可用,就用上。程式設計時,思路一定要清晰,首先就是層次結構要明確,這樣才能弄清楚程式碼區塊之間的關係,使得程式碼區塊組成的結構也更趨於合理。做一件事,通常會分解為多個大步驟,每個大步驟可以分解為多個小步驟,小步驟還可以繼續分解,這樣的結構就是層次結構。最終程式碼區塊所屬的步驟在什麼層上一定是清晰的,如果這個層次被打亂了,那麼程式出現bug的機率極大。
2. 學習基礎的程式語言
學習基礎程式語言,它們能夠幫助你理解基層架構。例如C語言,或是組合語言。
學習電腦是如何執行程序,知道作業系統是如何運作的,這是程式設計師最基本的要求。如果你想好好了解基礎語言,你可以閱讀有關電腦結構,作業系統,嵌入式系統,驅動程式作業系統開發等等的書籍。
3. 書寫程式碼
#在部落格上練習書寫程式碼。你也可以在不同的問答網站上回答問題。同時你也可以寫一些教學(DreamInCode)。當你編寫程式碼時,你會想著要正確編寫,為能夠解釋其中的問題和技術。編寫程式碼也能夠體現你的程式設計知識,提供你英語文法,這些在程式設計中都是很重要的。注重程式碼質量,不要寫看著就亂糟糟的程式碼,不要用 asdf 這樣的命名。
4. 加入一個開源專案
#加入一個開源專案的優點是什麼?你可以和其他人(在私人專案中獨自工作過)一起工作,當你遇到不熟悉的程式碼時,你將會去研究,學習理解一個不熟悉的程式碼庫(這應該是很有挑戰性的)
5. 學習如何閱讀代碼
一些大神們的回答都會提到多讀源碼,當然每個人還會列出其他的一些內容,讀源碼是十分核心的提升程式設計能力的方法,程式設計能力本身就是核心。等程式能力上去了,讀程式碼的時候讀到不對的地方就會感到硌牙,設計模組設計不好就會覺得難受,然後debug自然而然就順當多了。 。 。
讀取高品質的原始碼有什麼好處呢? 這和大量的閱讀對於寫作有什麼好處是十分類似的,寫程式也有語感。創作自己的東西之前首先就是閱讀別人創作的東西。多看了高手們是怎麼寫程式碼的,試著去理解高手們寫程式碼時在想什麼,久而久之自己就會模仿就會慢慢地學會如何像大神一樣寫程式碼。等閱讀量和寫作量累積到一定程度,許多業界所謂的設計規範,模組流程會自然而然的理解並遵照執行,因為這已成習慣。
6. 專注於思考與測驗
在動手寫程式碼之前需要先想一想,理一理思路,拿出紙和筆,認真想出方案。放鬆大腦保持頭腦清晰。從一開始就要考慮各種出錯的情況,如 I/O 錯誤,外部模組錯誤,使用者誤操作等等。首先,從Bug產生的可能情況來看,越是複雜的工程,產生Bug的數量就會越多,而且實際情況是,這兩者之間的關聯是非線性的。所以一定要害怕程式碼的複雜度。對於短小的程式碼而言Bug顯然會比較容易調通一些。一個非常重要的工作就是進行單元測試。對於每個單一的函數、模組、程式等,依序進行測試。去產生一組範圍內的數據,確保每個函數、模組、程式都能夠在任何情況下回傳正確的結果。
測試的另一個重要意義是為了防止重疊Bug。一個程式有多個Bug,他們一起存在在你程式中時,互相發生了奇怪的作用,導致只有某些特定的數據下才會出錯。而當你調通其中一個的時候,你所有數據都出錯了。你下意識就會以為自己之前的修補出了問題。雖然這種情況聽起來非常扯,但是實際上,經常遇到這樣的問題。
除了單元測試,一個非常重要的技巧是封裝封裝再封裝。把所有可能需要重複呼叫的東西都封裝成介面、抽象類別、方法或函數。這樣所帶來的好處是不言而喻的。一旦出了問題,可以一次修改掉所有的程式碼。而且調試程式的時候程式碼非常短,可以輕易確定出問題的究竟是哪個部分。
7. 閱讀好的程式設計書
#從書中你將學到很多,雖然實踐很重要,但透過閱讀好的且具有挑戰性程式設計書籍是你改變思考方式重要的一步。當然,你可以選擇一些難度較低的書籍,但要避免選擇那些「傻瓜」書籍,即稱能夠在24小時或是21天內教會一切的書籍,從這些書中無法學習到提高程式設計技巧的內容。
8. 嘗試解決一些難題
你應該試著去解決程式碼問題;程式設計師在程式設計過程中總是嘗試用最少的步驟來解決遇到的難題,而在這過程中,你可以學到語言的更深奧和更特殊的功能,從而你會不得不思考程式碼的創造性。
9. 其他一些重要的事情
1)最遲在進行系統聯調前,準備好單元測試案例(最好是一邊寫程式碼一邊寫單元測試案例),然後根據系統聯調和生產環境的回饋不斷的完善單元測試用例集。幾個迭代下來以後,被單元測試覆蓋的模組就能保持相當好的表現,並且你能很放心的去重構那些模組。
2)在開始寫程式碼前,先寫文檔,特別是如果專案中不只你一個人寫程式碼的話,文檔就更重要。它能幫助你釐清思路,提前發現一些邏輯坑。註釋是防“君子”不防“小人”,對於不遵守規則的調用者,需要有防備,因此,通過斷言(或者檢查判斷)來保證所要求的前提已被滿足也很重要。另外,自己的程式碼區塊執行完畢後是否達到預期的目的,也可以透過斷言或檢查邏輯來判斷。這方面,契約式程式設計的一些想法和做法可以藉鏡。很多時候,程式bug的產生是因為內部某些隱式條件的不滿足,這更多的體現為呼叫者並不清楚被呼叫者對他的要求。因此,不要吝嗇註釋,透過規範的註釋把這些要求表達清楚,會使得bug顯著減少。
3)次要日誌寫日誌檔裡,用好流行的日誌類別,而不要用簡陋的printf。重要日誌最好寫資料表裡,這樣可以使用SQL和資料庫軟體的功能去管理\分析\使用這些日誌資料。