如何正確高效的學(xué)習(xí)程序開發(fā)
程序開發(fā)是一種非常類似于學(xué)習(xí)的一種藝術(shù)形式或一種運(yùn)動(dòng)的技能，通過用心練習(xí)，不斷地從別人那里學(xué)習(xí)，才會(huì)編寫的更好。以下是學(xué)習(xí)啦小編分享給大家的高效的學(xué)習(xí)程序開發(fā)的方法，希望可以幫到你!
高效的學(xué)習(xí)程序開發(fā)的方法
1. 主動(dòng)學(xué)習(xí)新的技術(shù)和非技術(shù)兩方面的知識(shí)
不好的程序員只有在實(shí)在不行的時(shí)候才開始進(jìn)行知識(shí)學(xué)習(xí)。良好的程序員會(huì)主動(dòng)學(xué)習(xí)新的技術(shù)知識(shí)。
偉大的程序員不僅會(huì)自行學(xué)習(xí)新的技術(shù)知識(shí)， 而且還會(huì)學(xué)習(xí)非技術(shù)方面的知識(shí)，對(duì)各種知識(shí)來源都有一種開放的心態(tài)，而不會(huì)象有的人那樣固步自封。
具體點(diǎn)說，不好的程序員只有在參加了采用WPF的項(xiàng)目時(shí)才開始學(xué)習(xí) XAML;良好的程序員一年前就學(xué)習(xí)了XAML，因?yàn)樗杏X它很有意思;而偉大的程序員還閱讀了WPF應(yīng)用程序的設(shè)計(jì)指南、可用性(usability)理論或者什么類似的學(xué)習(xí)課程，因而他能夠制作出卓爾不群的UI。
2. 務(wù)實(shí)而不教條
嚴(yán)格遵守那些不成文的“編程規(guī)則”往往是一種奢侈品，沒有多少開發(fā)人員能夠承受得起。如果你們的規(guī)格說明書不是由頂尖的開發(fā)人員編寫的，也不是在頂尖的開發(fā)人員指導(dǎo)下編寫的，我就可以向你保證，你可能也承受不起。
我經(jīng)常能夠碰到一些程序員，他們無(wú)法或者拒絕做某個(gè)任務(wù)只是因?yàn)橥瓿蛇@個(gè)任務(wù)的做法通常不為最佳實(shí)踐所接受。
業(yè)務(wù)需求很少會(huì)受到實(shí)現(xiàn)需求所采用的技術(shù)的制約;沒有人會(huì)說，“這我們不應(yīng)該把這個(gè)需求寫到規(guī)格說明書里，因?yàn)橐獙?shí)現(xiàn)這個(gè)需求，程序員就不得不寫一段很臭的代碼。”
在結(jié)束的那一天，程序員的任務(wù)是要生成一個(gè)有效的應(yīng)用程序，而絕不是要求在技術(shù)方面達(dá)到十全十美。我可不是在為垃圾代碼做辯護(hù)。
我想說的是，總會(huì)在有些時(shí)候，你會(huì)寫出一些代碼，這些代碼你永遠(yuǎn)不會(huì)作為范例向別人展示做事的正確方法。
如果只有一種寫法，那么這種代碼就不是糟糕的代碼 ——但要保證你已窮盡了其它所有可能的方案。
3. 懂得如何通過研究找到答案
通過研究找到答案可不僅僅只是在搜索引擎中鍵入幾個(gè)關(guān)鍵字那么簡(jiǎn)單， 也不是到Stack Overflow或者M(jìn)SDN forums這類網(wǎng)站發(fā)個(gè)問題帖。
我就碰到過在搜索引擎里根本搜不到答案的問題，然后我Stack Overflow 或者M(jìn)SDN forums里發(fā)的所有問題貼都沒有一個(gè)像樣的答案，不過我還是解決了我所碰到的問題使得工作得以繼續(xù)。我不是魔術(shù)師 —— 我只是懂得如何找到答案，如何找出問題的根本原因。
有許問題都屬于情景式的問題，如果你依賴于搜索引擎或者論壇，就會(huì)在各種鏈接中浪費(fèi)大量的時(shí)間而最終無(wú)法得到真正的答案。
要學(xué)習(xí)如何進(jìn)行根本原因分析，學(xué)習(xí)底層系統(tǒng)方面的知識(shí)才能夠找到其它的線索和解決方案，還要學(xué)習(xí)如果在對(duì)問題有個(gè)全局性的認(rèn)識(shí)后才對(duì)其進(jìn)行深入分析。
高效的學(xué)習(xí)程序開發(fā)的建議
1. 遵循單一責(zé)任原則
在程序員的代碼庫(kù)中，函數(shù)是最重要的抽象形式?？梢灾赜玫拇a越多，編寫的代碼就越少，它們的可靠性也就越高。遵循單一責(zé)任原則的小功能代碼就更有可能被重用。
2.最小化共享狀態(tài)
你應(yīng)該最小化函數(shù)之間的隱式共享狀態(tài)，無(wú)論它是文件作用域變量還是對(duì)象的成員字段，都支持顯式的值作為參數(shù)。當(dāng)代碼明確了該函數(shù)需要什么來產(chǎn)生期望的結(jié)果時(shí)，代碼就變得更容易理解和重用。
這種情況下，你應(yīng)該優(yōu)先選擇靜態(tài)無(wú)狀態(tài)變量，而不應(yīng)該選擇對(duì)象上的成員變量。
3.本地化的副作用
理想的副作用(例如：控制臺(tái)打印、日志記錄、改變?nèi)譅顟B(tài)、文件系統(tǒng)操作等等)應(yīng)該放在單獨(dú)的模塊中，而不是分散在整個(gè)代碼中。功能上的副作用常常違反單一責(zé)任原則。
4. 優(yōu)先使用不可變對(duì)象
如果一個(gè)對(duì)象的狀態(tài)在其構(gòu)造函數(shù)中被設(shè)置一次，并且再也不會(huì)發(fā)生變化，那么調(diào)試就變得容易得多了，因?yàn)橐坏?gòu)造正確，它仍然有效。這是減少軟件項(xiàng)目復(fù)雜性的最簡(jiǎn)單方法之一。
5.多用接口少用類
使用接口(或在C++中使用模板參數(shù)或概念)的函數(shù)比在類上運(yùn)行的函數(shù)更容易被重用。
6. 將好的原則應(yīng)用于模塊
尋找機(jī)會(huì)，將軟件項(xiàng)目分解為更小的模塊(例如：庫(kù)和應(yīng)用程序)，以鼓勵(lì)模塊級(jí)的重用。模塊的一些關(guān)鍵原則是：
依賴最小化
每個(gè)項(xiàng)目都應(yīng)該有一個(gè)明確的功能
不要重復(fù)
你應(yīng)該努力使你的項(xiàng)目小而明確。
7. 避免繼承
在面向?qū)ο缶幊讨?，特別是在虛函數(shù)中，繼承在可重用性方面往往是一個(gè)死死穴。我?guī)缀鯖]有成功地編寫或使用那些能覆蓋類的庫(kù)。
8. 在設(shè)計(jì)和開發(fā)過程中進(jìn)行測(cè)試
我并不是測(cè)試驅(qū)動(dòng)開發(fā)的鐵桿擁護(hù)者，但隨著開始編寫代碼，測(cè)試代碼會(huì)自然而然地遵循許多指導(dǎo)原則。它還可以幫助我們更早地發(fā)現(xiàn)很多錯(cuò)誤。但是，要避免編寫無(wú)用的測(cè)試代碼，良好的編碼意味著更高級(jí)別的測(cè)試(例如：集成測(cè)試或單元測(cè)試以及功能測(cè)試)，而且在揭示缺陷方面更有效。
9. 優(yōu)先選擇而不是手寫標(biāo)準(zhǔn)庫(kù)
我無(wú)法告訴你我多久才能見到一個(gè)std::vector 或std::string更好的聲明，但這幾乎總是浪費(fèi)時(shí)間和精力的。除了顯而易見的事實(shí)，你正在引入一個(gè)bug(參見技巧10)，其他程序員不太可能重用你的代碼，因?yàn)檫@不是那些被廣泛理解、支持和測(cè)試的代碼。
10. 避免編寫新的代碼
這是每個(gè)程序員都應(yīng)該遵循的：“The best code is the code that isn’t written”(最好的代碼是不用被復(fù)寫的代碼)。你擁有的代碼行數(shù)越多，你的缺陷就越多，發(fā)現(xiàn)和修復(fù)bug的難度就越大。
在編寫一行代碼之前，問自己，是否有一個(gè)工具、函數(shù)或庫(kù)已經(jīng)完成了你所需要的工作?你真的需要那個(gè)功能而不是調(diào)用另一個(gè)已經(jīng)存在的函數(shù)嗎?
攻克這些障礙才能高效學(xué)習(xí)編程
1.不正確的學(xué)習(xí)動(dòng)機(jī)
在談及壁壘之前，我想先著重說明學(xué)習(xí)動(dòng)機(jī)的重要性。不要只是為了編程而學(xué)編程，也不要因?yàn)槁犝f它很酷，很劃得來就來學(xué)編程。
你得因?yàn)橐鉀Q問題而學(xué)習(xí)編程，你得因?yàn)橄胍詣?dòng)化和改善生活而學(xué)習(xí)編程，你得因?yàn)橄胍獦?gòu)建應(yīng)用程序以造福社會(huì)來學(xué)習(xí)編程。
如果你只是喜歡編程，并希望以此作為職業(yè)的話，那么在之后的學(xué)習(xí)過程中，你可能會(huì)有一種強(qiáng)烈的沖動(dòng)想要放棄。這通常發(fā)生在事情變得艱難，學(xué)習(xí)體驗(yàn)變得痛苦的情況下。這時(shí)你會(huì)告訴自己，你不喜歡編程了，編程操作不適合你，覺得自己天生就成不了程序員。
這就是為什么你應(yīng)該考慮圍繞著完成項(xiàng)目設(shè)置目標(biāo)的原因。如果你的心里有計(jì)劃，或者你想要解決更高層次的問題，那么你可以對(duì)自己說：“這可能不是一次愉快的經(jīng)歷，但是我真的想要解決這個(gè)大問題，所以我一定要克服這個(gè)障礙。”
2.不知道從什么技術(shù)入手
很多人會(huì)問：“我應(yīng)該先學(xué)什么編程語(yǔ)言?”之所以會(huì)提出這個(gè)問題，是因?yàn)樗麄儾恢雷约簽槭裁匆獙W(xué)習(xí)代碼。
一旦你下定決心去完成一個(gè)特定的項(xiàng)目，那么從什么語(yǔ)言入手這個(gè)問題就變成一件很容易的事情：
如果你想構(gòu)建iOS app，那么你需要學(xué)習(xí)Objective C或Swift。
如果你想構(gòu)建Android app，那么你需要學(xué)習(xí)Java。
如果你想構(gòu)建Web app，那么你需要學(xué)習(xí)JavaScript。
其實(shí)現(xiàn)在我們可以使用JavaScript來創(chuàng)建任何類型的項(xiàng)目——無(wú)論是簡(jiǎn)單的web和移動(dòng)app，還是高級(jí)的硬件項(xiàng)目。大多數(shù)行業(yè)中都有它的身影：音樂、醫(yī)療、游戲、時(shí)裝。這種語(yǔ)言非常值得學(xué)習(xí)。
如果你還是不能確定要選擇哪種語(yǔ)言，那么不妨咨詢下某個(gè)程序員的意見。只要你確定要構(gòu)建什么項(xiàng)目，那么他就能很快地為你推薦適合你使用的技術(shù)。
另外，知識(shí)都是相通的，所以，不要過于拘謹(jǐn)，選擇語(yǔ)言這一步驟幾乎沒什么風(fēng)險(xiǎn)。
3.不能學(xué)以致用，以及責(zé)備自己
選擇好技術(shù)堆棧之后，剛開始學(xué)習(xí)理論總是很輕松的，而且網(wǎng)上也有許許多多免費(fèi)和付費(fèi)的在線課程。
很快大多數(shù)學(xué)習(xí)者掌握了理論知識(shí)，甚至完全可以自己來解釋某個(gè)代碼片段的工作原理。理論只是概念的有限集合。任何人都可以在幾天之內(nèi)記住它，如果她/他真的想的話。那么，關(guān)鍵的問題是什么?
學(xué)習(xí)者碰到的最大問題在于，實(shí)際應(yīng)用理論來解決問題并編寫新代碼的時(shí)候。這中間的差距實(shí)際上就是技能空白。
比如說游泳。你可以閱讀大量的技術(shù)文章，然后解釋得就像一個(gè)專業(yè)教練。但是，要想實(shí)際應(yīng)用這些理論，就需要大量的實(shí)踐、斗爭(zhēng)和錯(cuò)誤——你肯定會(huì)吞下大量的水!
然而更糟糕的是你開始責(zé)備自己?；蛘哒J(rèn)為自己不夠聰明，或者覺得自己沒有天賦。這其實(shí)跟聰明天賦沒有關(guān)系，你只是需要練習(xí)技能的過程：
1.選擇一個(gè)復(fù)雜的項(xiàng)目。理想情況下，這項(xiàng)目得能夠激發(fā)你的興趣。
2.將這個(gè)任務(wù)分割成既小又獨(dú)立的任務(wù)。例如，“實(shí)現(xiàn)登錄頁(yè)面”是一個(gè)很大的任務(wù)。解決一個(gè)任務(wù)不應(yīng)該超過20行左右的代碼。下面這些提示有助于成功做到這一點(diǎn)：
如果你不能解決這個(gè)任務(wù)，那么進(jìn)一步將它分割成更小的任務(wù)。
一個(gè)任務(wù)一次不應(yīng)該使用太多的理論概念。
3.一次專注一項(xiàng)任務(wù)，而不是并行解決多任務(wù)。不要跳到下一個(gè)任務(wù)，除非你已經(jīng)徹底測(cè)試過當(dāng)前任務(wù)，并確信沒有問題。
如果你不這么做，而此時(shí)應(yīng)用程序又出現(xiàn)了問題，那么你就不知道你正在并行解決的多任務(wù)中到底是哪個(gè)出了問題，尋找起來就麻煩多了。
4.確保自己在開始任務(wù)之前知道所有必要的理論知識(shí)。有時(shí)候，你可能不知道需要學(xué)習(xí)什么理論，這很正常，所以你需要向他人尋求幫助：程序員朋友，導(dǎo)師，或類似StackOverflow的社區(qū)。
5.最后，你解決了任務(wù)。在解決任務(wù)的過程中，你可能會(huì)碰到很多問題，你需要做的就是吸取教訓(xùn)，這也是下面要說的要點(diǎn)：
4.不吸取解決任務(wù)中獲得的經(jīng)驗(yàn)教訓(xùn)
最好的情況是，你解決了任務(wù)并且結(jié)果證明非常有效。此時(shí)，很多人往往就直接開展下一個(gè)任務(wù)。但是如果你這樣做的話，那么你浪費(fèi)了一個(gè)絕佳的學(xué)習(xí)機(jī)會(huì)。
希望你能夠用以下問題來挑戰(zhàn)自我，幫助自己成長(zhǎng)：
哪些邊界情況會(huì)導(dǎo)致我的代碼失敗?即使現(xiàn)在還沒有失敗，有哪些應(yīng)用程序狀態(tài)可能會(huì)破壞代碼?
我的代碼是否足夠整潔?對(duì)其他開發(fā)人員，甚至是自己而言，代碼是否易于理解和改變?因?yàn)橐院罂赡苄枰迯?fù)隱藏在這段代碼中的問題，或者根據(jù)其他產(chǎn)品規(guī)格改變代碼。
我的方法是最好的嗎?有沒有其他選項(xiàng)是我可以選擇使用的?各個(gè)方案的利弊?這任務(wù)是否值得用不同的方式解決?
此模塊與其他模塊是如何交互的?是否會(huì)對(duì)其他模塊造成負(fù)面影響?是否容易被其他模塊影響?
然而，很多時(shí)候，你會(huì)進(jìn)退維谷：
5.你不知道如何處理一個(gè)任務(wù)
你不知道從哪里開始?你可能會(huì)隨機(jī)地去嘗試，或者從其他地方復(fù)制一些你自己也不明白的代碼。但是，這是沒有幫助的。即使你復(fù)制來的代碼有效也沒用。因?yàn)楫?dāng)你今后再一次碰到類似的任務(wù)，你依然不能解決。
如果你想妥善解決任務(wù)，那么首先你得知道你為什么卡殼。下面是一些可能的原因：
1.沒有很好地掌握這些理論知識(shí)：
語(yǔ)言語(yǔ)法
庫(kù)或API的工作原理，某個(gè)具體方法或類的工作原理
編程范式(例如：異步編程)
系統(tǒng)運(yùn)作(例如：HTTP請(qǐng)求是理解Web開發(fā)的關(guān)鍵)
如果是上述情況，那么可以去復(fù)習(xí)理論知識(shí)，如果依然摸不著頭腦，也可以去找人尋求幫助。
2.任務(wù)太大了，那就分解為一個(gè)個(gè)小任務(wù)。
3.也有可能是因?yàn)槟阕x得太快，忽略了一些你以為熟悉其實(shí)似是而非的概念，所以無(wú)法理解任務(wù)要求。
猜你喜歡：
如何正確高效的學(xué)習(xí)程序開發(fā)
