如何正確高效的學習程式開發
程式開發是一種非常類似於學習的一種藝術形式或一種運動的技能，通過用心練習，不斷地從別人那裡學習，才會編寫的更好。以下是小編分享給大家的高效的學習程式開發的方法，希望可以幫到你!
高效的學習程式開發的方法
1. 主動學習新的技術和非技術兩方面的知識
不好的程式設計師只有在實在不行的時候才開始進行知識學習。良好的程式設計師會主動學習新的技術知識。
偉大的程式設計師不僅會自行學習新的技術知識， 而且還會學習非技術方面的知識，對各種知識來源都有一種開放的心態，而不會象有的人那樣固步自封。
具體點說，不好的程式設計師只有在參加了採用WPF的專案時才開始學習XAML;良好的程式設計師一年前就學習了XAML，因為他感覺它很有意思;而偉大的程式設計師還閱讀了WPF應用程式的設計指南、可用性***usability***理論或者什麼類似的學習課程，因而他能夠製作出卓爾不群的UI。
2. 務實而不教條
嚴格遵守那些不成文的“程式設計規則”往往是一種奢侈品，沒有多少開發人員能夠承受得起。如果你們的規格說明書不是由頂尖的開發人員編寫的，也不是在頂尖的開發人員指導下編寫的，我就可以向你保證，你可能也承受不起。
我經常能夠碰到一些程式設計師，他們無法或者拒絕做某個任務只是因為完成這個任務的做法通常不為最佳實踐所接受。
業務需求很少會受到實現需求所採用的技術的制約;沒有人會說，“這我們不應該把這個需求寫到規格說明書裡，因為要實現這個需求，程式設計師就不得不寫一段很臭的程式碼。”
在結束的那一天，程式設計師的任務是要生成一個有效的應用程式，而絕不是要求在技術方面達到十全十美。我可不是在為垃圾程式碼做辯護。
我想說的是，總會在有些時候，你會寫出一些程式碼，這些程式碼你永遠不會作為範例向別人展示做事的正確方法。
如果只有一種寫法，那麼這種程式碼就不是糟糕的程式碼 ——但要保證你已窮盡了其它所有可能的方案。
3. 懂得如何通過研究找到答案
通過研究找到答案可不僅僅只是在搜尋引擎中鍵入幾個關鍵字那麼簡單， 也不是到Stack Overflow或者MSDN forums這類網站發個問題帖。
我就碰到過在搜尋引擎里根本搜不到答案的問題，然後我Stack Overflow 或者MSDN forums裡發的所有問題貼都沒有一個像樣的答案，不過我還是解決了我所碰到的問題使得工作得以繼續。我不是魔術師 —— 我只是懂得如何找到答案，如何找出問題的根本原因。
有許問題都屬於情景式的問題，如果你依賴於搜尋引擎或者論壇，就會在各種連結中浪費大量的時間而最終無法得到真正的答案。
要學習如何進行根本原因分析，學習底層系統方面的知識才能夠找到其它的線索和解決方案，還要學習如果在對問題有個全域性性的認識後才對其進行深入分析。
高效的學習程式開發的建議
1. 遵循單一責任原則
在程式設計師的程式碼庫中，函式是最重要的抽象形式。可以重用的程式碼越多，編寫的程式碼就越少，它們的可靠性也就越高。遵循單一責任原則的小功能程式碼就更有可能被重用。
2.最小化共享狀態
你應該最小化函式之間的隱式共享狀態，無論它是檔案作用域變數還是物件的成員欄位，都支援顯式的值作為引數。當代碼明確了該函式需要什麼來產生期望的結果時，程式碼就變得更容易理解和重用。
這種情況下，你應該優先選擇靜態無狀態變數，而不應該選擇物件上的成員變數。
3.本地化的副作用
理想的副作用***例如：控制檯列印、日誌記錄、改變全域性狀態、檔案系統操作等等***應該放在單獨的模組中，而不是分散在整個程式碼中。功能上的副作用常常違反單一責任原則。
4. 優先使用不可變物件
如果一個物件的狀態在其建構函式中被設定一次，並且再也不會發生變化，那麼除錯就變得容易得多了，因為一旦構造正確，它仍然有效。這是減少軟體專案複雜性的最簡單方法之一。
5.多用介面少用類
使用介面***或在C++中使用模板引數或概念***的函式比在類上執行的函式更容易被重用。
6. 將好的原則應用於模組
尋找機會，將軟體專案分解為更小的模組***例如：庫和應用程式***，以鼓勵模組級的重用。模組的一些關鍵原則是：
依賴最小化
每個專案都應該有一個明確的功能
不要重複
你應該努力使你的專案小而明確。
7. 避免繼承
在面向物件程式設計中，特別是在虛擬函式中，繼承在可重用性方面往往是一個死死穴。我幾乎沒有成功地編寫或使用那些能覆蓋類的庫。
8. 在設計和開發過程中進行測試
我並不是測試驅動開發的鐵桿擁護者，但隨著開始編寫程式碼，測試程式碼會自然而然地遵循許多指導原則。它還可以幫助我們更早地發現很多錯誤。但是，要避免編寫無用的測試程式碼，良好的編碼意味著更高級別的測試***例如：整合測試或單元測試以及功能測試***，而且在揭示缺陷方面更有效。
9. 優先選擇而不是手寫標準庫
我無法告訴你我多久才能見到一個std::vector 或std::string更好的宣告，但這幾乎總是浪費時間和精力的。除了顯而易見的事實，你正在引入一個bug***參見技巧10***，其他程式設計師不太可能重用你的程式碼，因為這不是那些被廣泛理解、支援和測試的程式碼。
10. 避免編寫新的程式碼
這是每個程式設計師都應該遵循的：“The best code is the code that isn’t written”***最好的程式碼是不用被複寫的程式碼***。你擁有的程式碼行數越多，你的缺陷就越多，發現和修復bug的難度就越大。
在編寫一行程式碼之前，問自己，是否有一個工具、函式或庫已經完成了你所需要的工作?你真的需要那個功能而不是呼叫另一個已經存在的函式嗎?
攻克這些障礙才能高效學習程式設計
1.不正確的學習動機
在談及壁壘之前，我想先著重說明學習動機的重要性。不要只是為了程式設計而學程式設計，也不要因為聽說它很酷，很划得來就來學程式設計。
你得因為要解決問題而學習程式設計，你得因為想要自動化和改善生活而學習程式設計，你得因為想要構建應用程式以造福社會來學習程式設計。
如果你只是喜歡程式設計，並希望以此作為職業的話，那麼在之後的學習過程中，你可能會有一種強烈的衝動想要放棄。這通常發生在事情變得艱難，學習體驗變得痛苦的情況下。這時你會告訴自己，你不喜歡程式設計了，程式設計操作不適合你，覺得自己天生就成不了程式設計師。
這就是為什麼你應該考慮圍繞著完成專案設定目標的原因。如果你的心裡有計劃，或者你想要解決更高層次的問題，那麼你可以對自己說：“這可能不是一次愉快的經歷，但是我真的想要解決這個大問題，所以我一定要克服這個障礙。”
2.不知道從什麼技術入手
很多人會問：“我應該先學什麼程式語言?”之所以會提出這個問題，是因為他們不知道自己為什麼要學習程式碼。
一旦你下定決心去完成一個特定的專案，那麼從什麼語言入手這個問題就變成一件很容易的事情：
如果你想構建iOS app，那麼你需要學習Objective C或Swift。
如果你想構建Android app，那麼你需要學習Java。
如果你想構建Web app，那麼你需要學習JavaScript。
其實現在我們可以使用JavaScript來建立任何型別的專案——無論是簡單的web和移動app，還是高階的硬體專案。大多數行業中都有它的身影：音樂、醫療、遊戲、時裝。這種語言非常值得學習。
如果你還是不能確定要選擇哪種語言，那麼不妨諮詢下某個程式設計師的意見。只要你確定要構建什麼專案，那麼他就能很快地為你推薦適合你使用的技術。
另外，知識都是相通的，所以，不要過於拘謹，選擇語言這一步驟幾乎沒什麼風險。
3.不能學以致用，以及責備自己
選擇好技術堆疊之後，剛開始學習理論總是很輕鬆的，而且網上也有許許多多免費和付費的線上課程。
很快大多數學習者掌握了理論知識，甚至完全可以自己來解釋某個程式碼片段的工作原理。理論只是概念的有限集合。任何人都可以在幾天之內記住它，如果她/他真的想的話。那麼，關鍵的問題是什麼?
學習者碰到的最大問題在於，實際應用理論來解決問題並編寫新程式碼的時候。這中間的差距實際上就是技能空白。
比如說游泳。你可以閱讀大量的技術文章，然後解釋得就像一個專業教練。但是，要想實際應用這些理論，就需要大量的實踐、鬥爭和錯誤——你肯定會吞下大量的水!
然而更糟糕的是你開始責備自己。或者認為自己不夠聰明，或者覺得自己沒有天賦。這其實跟聰明天賦沒有關係，你只是需要練習技能的過程：
1.選擇一個複雜的專案。理想情況下，這專案得能夠激發你的興趣。
2.將這個任務分割成既小又獨立的任務。例如，“實現登入頁面”是一個很大的任務。解決一個任務不應該超過20行左右的程式碼。下面這些提示有助於成功做到這一點：
如果你不能解決這個任務，那麼進一步將它分割成更小的任務。
一個任務一次不應該使用太多的理論概念。
3.一次專注一項任務，而不是並行解決多工。不要跳到下一個任務，除非你已經徹底測試過當前任務，並確信沒有問題。
如果你不這麼做，而此時應用程式又出現了問題，那麼你就不知道你正在並行解決的多工中到底是哪個出了問題，尋找起來就麻煩多了。
4.確保自己在開始任務之前知道所有必要的理論知識。有時候，你可能不知道需要學習什麼理論，這很正常，所以你需要向他人尋求幫助：程式設計師朋友，導師，或類似StackOverflow的社群。
5.最後，你解決了任務。在解決任務的過程中，你可能會碰到很多問題，你需要做的就是吸取教訓，這也是下面要說的要點：
4.不吸取解決任務中獲得的經驗教訓
最好的情況是，你解決了任務並且結果證明非常有效。此時，很多人往往就直接開展下一個任務。但是如果你這樣做的話，那麼你浪費了一個絕佳的學習機會。
希望你能夠用以下問題來挑戰自我，幫助自己成長：
哪些邊界情況會導致我的程式碼失敗?即使現在還沒有失敗，有哪些應用程式狀態可能會破壞程式碼?
我的程式碼是否足夠整潔?對其他開發人員，甚至是自己而言，程式碼是否易於理解和改變?因為以後可能需要修復隱藏在這段程式碼中的問題，或者根據其他產品規格改變程式碼。
我的方法是最好的嗎?有沒有其他選項是我可以選擇使用的?各個方案的利弊?這任務是否值得用不同的方式解決?
此模組與其他模組是如何互動的?是否會對其他模組造成負面影響?是否容易被其他模組影響?
然而，很多時候，你會進退維谷：
5.你不知道如何處理一個任務
你不知道從哪裡開始?你可能會隨機地去嘗試，或者從其他地方複製一些你自己也不明白的程式碼。但是，這是沒有幫助的。即使你複製來的程式碼有效也沒用。因為當你今後再一次碰到類似的任務，你依然不能解決。
如果你想妥善解決任務，那麼首先你得知道你為什麼卡殼。下面是一些可能的原因：
1.沒有很好地掌握這些理論知識：
語言語法
庫或API的工作原理，某個具體方法或類的工作原理
程式設計正規化***例如：非同步程式設計***
系統運作***例如：HTTP請求是理解Web開發的關鍵***
如果是上述情況，那麼可以去複習理論知識，如果依然摸不著頭腦，也可以去找人尋求幫助。
2.任務太大了，那就分解為一個個小任務。
3.也有可能是因為你讀得太快，忽略了一些你以為熟悉其實似是而非的概念，所以無法理解任務要求。
1.程式設計師勵志故事
2.建立正常的記憶程式
3.右腦開發讓學習變輕鬆
4.自學勵志故事
5.學習程式設計的有效方法