如何正確高效的學習程序開發(fā)

1、如何正確高效的學習程序開發(fā) 程序開發(fā)是一種非常類似于學習的一種藝術(shù)形式或一種運動的技能，通過用心練習，不斷地從別人那里學習，才會編寫的更好。以下是學習啦分享給大家的高效的學習程序開發(fā)的方法，希望可以幫到你! 1. 主動學習新的技術(shù)和非技術(shù)兩方面的知識 不好的程序員只有在實在不行的時候才開始進行知識學習。良好的程序員會主動學習新的技術(shù)知識。 偉大的程序員不僅會自行學習新的技術(shù)知識， 而且還會學習非技術(shù)方面的知識，對各種知識都有一種開放的心態(tài)，而不會象有的人那樣固步自封。 具體點說，不好的程序員只有在參加了采用WPF的項目時才開始學習 XAML;良好的程序員一年前就學習了XAML，因為他感覺它很有

2、意思;而偉大的程序員還閱讀了WPF應用程序的設(shè)計指南、可用性(usability)理論或者什么類似的學習課程，因而他能夠制作出卓爾不群的UI。 2. 務實而不教條 嚴格遵守那些不成文的“編程規(guī)則”往往是一種奢侈品，沒有多少開發(fā)人員能夠承受得起。如果你們的規(guī)格不是由頂尖的開發(fā)人員編寫的，也不是在頂尖的開發(fā)人員指導下編寫的，我就可以向你保證，你可能也承受不起。 我經(jīng)常能夠碰到一些程序員，他們無法或者拒絕做某個任務只是因為完成這個任務的做法通常不為最佳實踐所接受。 業(yè)務需求很少會受到實現(xiàn)需求所采用的技術(shù)的制約;沒有人會說，“這我們不應該把這個需求寫到規(guī)格說明書里，因為要實現(xiàn)這個需求，程序員就不得不寫

3、一段很臭的代碼?！?在結(jié)束的那一天，程序員的任務是要生成一個有效的應用程序，而絕不是要求在技術(shù)方面達到十全十美。我可不是在為垃圾代碼做辯護。 我想說的是，總會在有些時候，你會寫出一些代碼，這些代碼你永遠不會作為范例向別人展示做事的正確方法。 如果只有一種寫法，那么這種代碼就不是糟糕的代碼 但要保證你已窮盡了其它所有可能的方案。 3. 懂得如何通過研究找到答案 通過研究找到答案可不僅僅只是在搜索引擎中鍵入幾個關(guān)鍵字那么簡單， 也不是到Stack Overflow或者MSDN forums這類網(wǎng)站發(fā)個問題帖。 我就碰到過在搜索引擎里根本搜不到答案的問題，然后我Stack Overflow 或者MS

4、DN forums里發(fā)的所有問題貼都沒有一個像樣的答案，不過我還是解決了我所碰到的問題使得工作得以繼續(xù)。我不是師 我只是懂得如何找到答案，如何找出問題的根本原因。 有許問題都屬于情景式的問題，如果你依賴于搜索引擎或者論壇，就會在各種鏈接中浪費大量的時間而最終無法得到真正的答案。 要學習如何進行根本原因分析，學習底層系統(tǒng)方面的知識才能夠找到其它的線索和解決方案，還要學習如果在對問題有個全局性的認識后才對其進行深入分析。 1. 遵循單一責任原則 在程序員的代碼庫中，是最重要的形式?？梢灾赜玫拇a越多，編寫的代碼就越少，它們的可靠性也就越高。遵循單一責任原則的小功能代碼就更有可能被重用。 2.最小化

5、共享狀態(tài) 你應該最小化函數(shù)之間的隱式共享狀態(tài)，無論它是文件作用域變量還是對象的成員字段，都支持顯式的值作為參數(shù)。當代碼明確了該函數(shù)需要什么來產(chǎn)生期望的結(jié)果時，代碼就變得更容易理解和重用。 這種情況下，你應該優(yōu)先選擇靜態(tài)無狀態(tài)變量，而不應該選擇對象上的成員變量。 3.本地化的副作用 理想的副作用(例如：控制臺打印、日志記錄、改變?nèi)譅顟B(tài)、文件系統(tǒng)操作等等)應該放在單獨的模塊中，而不是分散在整個代碼中。功能上的副作用常常違反單一責任原則。 4. 優(yōu)先使用不可變對象 如果一個對象的狀態(tài)在其構(gòu)造函數(shù)中被設(shè)置一次，并且再也不會發(fā)生變化，那么調(diào)試就變得容易得多了，因為一旦構(gòu)造正確，它仍然有效。這是減少軟件

6、項目復雜性的最簡單方法之一。 5.多用接口少用類 使用接口(或在C+中使用模板參數(shù)或概念)的函數(shù)比在類上運行的函數(shù)更容易被重用。 6. 將好的原則應用于模塊 尋找機會，將軟件項目分解為更小的模塊(例如：庫和應用程序)，以鼓勵模塊級的重用。模塊的一些關(guān)鍵原則是： 依賴最小化 每個項目都應該有一個明確的功能 不要重復 你應該努力使你的項目小而明確。 7. 避免繼承 在面向?qū)ο缶幊讨?，特別是在虛函數(shù)中，繼承在可重用性方面往往是一個死死穴。我?guī)缀鯖]有地編寫或使用那些能覆蓋類的庫。 8. 在設(shè)計和開發(fā)過程中進行測試 我并不是測試驅(qū)動開發(fā)的鐵桿擁護者，但隨著開始編寫代碼，測試代碼會而然地遵循許多指導原則。

7、它還可以幫助我們更早地發(fā)現(xiàn)很多錯誤。但是，要避免編寫無用的測試代碼，良好的編碼意味著更高級別的測試(例如：集成測試或單元測試以及功能測試)，而且在揭示缺陷方面更有效。 9. 優(yōu)先選擇而不是手寫標準庫 我無法告訴你我多久才能見到一個std:vector 或std:string更好的聲明，但這幾乎總是浪費時間和精力的。除了顯而易見的事實，你正在引入一個bug(參見技巧10)，其他程序員不太可能重用你的代碼，因為這不是那些被廣泛理解、支持和測試的代碼。 10. 避免編寫新的代碼 這是每個程序員都應該遵循的：“The best code is the code that isnt written”(最

8、好的代碼是不用被復寫的代碼)。你擁有的代碼行數(shù)越多，你的缺陷就越多，發(fā)現(xiàn)和修復bug的難度就越大。 在編寫一行代碼之前，問自己，是否有一個工具、函數(shù)或庫已經(jīng)完成了你所需要的工作?你真的需要那個功能而不是調(diào)用另一個已經(jīng)存在的函數(shù)嗎? 1.不正確的學習動機 在談及壁壘之前，我想先著重說明學習動機的重要性。不要只是為了編程而學編程，也不要因為聽說它很酷，很劃得來就來學編程。 你得因為要解決問題而學習編程，你得因為想要自動化和改善生活而學習編程，你得因為想要構(gòu)建應用程序以造福社會來學習編程。 如果你只是喜歡編程，并希望以此作為職業(yè)的話，那么在之后的學習過程中，你可能會有一種強烈的沖動想要放棄。這通常發(fā)

9、生在事情變得艱難，學習體驗變得痛苦的情況下。這時你會告訴自己，你不喜歡編程了，編程操作不適合你，覺得自己天生就成不了程序員。 這就是為什么你應該考慮圍繞著完成項目設(shè)置目標的原因。如果你的心里有計劃，或者你想要解決更高層次的問題，那么你可以對自己說：“這可能不是一次愉快的經(jīng)歷，但是我真的想要解決這個大問題，所以我一定要克服這個障礙。” 2.不知道從什么技術(shù)入手 很多人會問：“我應該先學什么編程語言?”之所以會提出這個問題，是因為他們不知道自己為什么要學習代碼。 一旦你下定決心去完成一個特定的項目，那么從什么語言入手這個問題就變成一件很容易的事情： 如果你想構(gòu)建iOS app，那么你需要學習Obj

10、ective C或Swift。 如果你想構(gòu)建Android app，那么你需要學習Java。 如果你想構(gòu)建Web app，那么你需要學習JavaScript。 其實現(xiàn)在我們可以使用JavaScript來創(chuàng)建任何類型的項目無論是簡單的web和移動app，還是高級的硬件項目。大多數(shù)行業(yè)中都有它的身影：音樂、醫(yī)療、時裝。這種語言非常值得學習。 如果你還是不能確定要選擇哪種語言，那么不妨咨詢下某個程序員的。只要你確定要構(gòu)建什么項目，那么他就能很快地為你推薦適合你使用的技術(shù)。 另外，知識都是相通的，所以，不要過于拘謹，選擇語言這一步驟幾乎沒什么風險。 3.不能學以致用，以及責備自己 選擇好技術(shù)堆棧之后，

11、剛開始學習理論總是很輕松的，而且網(wǎng)上也有許許多多和付費的在線課程。 很快大多習者掌握了理論知識，甚至完全可以自己來解釋某個代碼片段的工作原理。理論只是概念的有限集合。任何人都可以在幾天之內(nèi)記住它，如果她/他真的想的話。那么，關(guān)鍵的問題是什么? 學習者碰到的最大問題在于，實際應用理論來解決問題并編寫新代碼的時候。這中間的差距實際上就是技能空白。 比如說。你可以閱讀大量的技術(shù)文章，然后解釋得就像一個專業(yè)教練。但是，要想實際應用這些理論，就需要大量的實踐、斗爭和錯誤你肯定會吞下大量的水! 然而更糟糕的是你開始責備自己。或者認為自己不夠聰明，或者覺得自己沒有天賦。這其實跟聰明天賦沒有關(guān)系，你只是需要練

12、習技能的過程： 1.選擇一個復雜的項目。理想情況下，這項目得能夠激發(fā)你的。 2.將這個任務分割成既小又獨立的任務。例如，“實現(xiàn)登錄頁面”是一個很大的任務。解決一個任務不應該超過20行左右的代碼。下面這些提示有助于成功做到這一點： 如果你不能解決這個任務，那么進一步將它分割成更小的任務。 一個任務一次不應該使用太多的理論概念。 3.一次專注一項任務，而不是并行解決多任務。不要跳到下一個任務，除非你已經(jīng) _測試過當前任務，并確信沒有問題。 如果你不這么做，而此時應用程序又出現(xiàn)了問題，那么你就不知道你正在并行解決的多任務中到底是哪個出了問題，尋找起來就麻煩多了。 4.確保自己在開始任務之前知道所有必

13、要的理論知識。有時候，你可能不知道需要學習什么理論，這很正常，所以你需要向他人尋求幫助：程序員朋友，導師，或類似StackOverflow的社區(qū)。 5.最后，你解決了任務。在解決任務的過程中，你可能會碰到很多問題，你需要做的就是吸取教訓，這也是下面要說的要點： 4.不吸取解決任務中獲得的教訓 最好的情況是，你解決了任務并且結(jié)果證明非常有效。此時，很多人往往就直接開展下一個任務。但是如果你這樣做的話，那么你浪費了一個絕佳的學習機會。 希望你能夠用以下問題來挑戰(zhàn)自我，幫助自己成長： 哪些邊界情況會導致我的代碼失敗?即使現(xiàn)在還沒有失敗，有哪些應用程序狀態(tài)可能會破壞代碼? 我的代碼是否足夠整潔?對其他

14、開發(fā)人員，甚至是自己而言，代碼是否易于理解和改變?因為以后可能需要修復隱藏在這段代碼中的問題，或者根據(jù)其他產(chǎn)品規(guī)格改變代碼。 我的方法是最好的嗎?有沒有其他選項是我可以選擇使用的?各個方案的利弊?這任務是否值得用不同的方式解決? 此模塊與其他模塊是如何交互的?是否會對其他模塊造成負面影響?是否容易被其他模塊影響? 然而，很多時候，你會進退維谷： 5.你不知道如何處理一個任務 你不知道從哪里開始?你可能會隨機地去嘗試，或者從其他地方復制一些你自己也不明白的代碼。但是，這是沒有幫助的。即使你復制來的代碼有效也沒用。因為當你今后再一次碰到類似的任務，你依然不能解決。 如果你想妥善解決任務，那么首先你得知道你為什么卡殼。下面是一些可能的原因：