- 更享受學習經歷
- 進步更快
- 碰到難題更執著，不輕言放棄
- 寫程式碼時更獨立
1.不正確的學習動機
在談及壁壘之前，我想先著重說明學習動機的重要性。不要只是為了程式設計而學程式設計，也不要因為聽說它很酷，很划得來就來學程式設計。
你得因為要解決問題而學習程式設計，你得因為想要自動化和改善生活而學習程式設計，你得因為想要構建應用程式以造福社會來學習程式設計。
如果你只是喜歡程式設計，並希望以此作為職業的話，那麼在之後的學習過程中，你可能會有一種強烈的衝動想要放棄。這通常發生在事情變得艱難，學習體驗變得痛苦的情況下。這時你會告訴自己，你不喜歡程式設計了，程式設計操作不適合你，覺得自己天生就成不了程式設計師。
這就是為什麼你應該考慮圍繞著完成專案設定目標的原因。如果你的心裡有計劃，或者你想要解決更高層次的問題，那麼你可以對自己說：“這可能不是一次愉快的經歷，但是我真的想要解決這個大問題，所以我一定要克服這個障礙。”
2.不知道從什麼技術入手
很多人會問：“我應該先學什麼程式語言？”之所以會提出這個問題，是因為他們不知道自己為什麼要學習程式碼。
一旦你下定決心去完成一個特定的專案，那麼從什麼語言入手這個問題就變成一件很容易的事情：
- 如果你想構建iOS app，那麼你需要學習Objective C或Swift。
- 如果你想構建Android app，那麼你需要學習Java。
- 如果你想構建Web app，那麼你需要學習JavaScript。
如果你還是不能確定要選擇哪種語言，那麼不妨諮詢下某個程式設計師的意見。只要你確定要構建什麼專案，那麼他就能很快地為你推薦適合你使用的技術。
另外，知識都是相通的，所以，不要過於拘謹，選擇語言這一步驟幾乎沒什麼風險。
3.不能學以致用，以及責備自己
選擇好技術堆疊之後，剛開始學習理論總是很輕鬆的，而且網上也有許許多多免費和付費的線上課程。
很快大多數學習者掌握了理論知識，甚至完全可以自己來解釋某個程式碼片段的工作原理。理論只是概念的有限集合。任何人都可以在幾天之內記住它，如果她/他真的想的話。那麼，關鍵的問題是什麼？
學習者碰到的最大問題在於，實際應用理論來解決問題並編寫新程式碼的時候。這中間的差距實際上就是技能空白。
比如說游泳。你可以閱讀大量的技術文章，然後解釋得就像一個專業教練。但是，要想實際應用這些理論，就需要大量的實踐、鬥爭和錯誤——你肯定會吞下大量的水！
然而更糟糕的是你開始責備自己。或者認為自己不夠聰明，或者覺得自己沒有天賦。這其實跟聰明天賦沒有關係，你只是需要練習技能的過程：
1.選擇一個複雜的專案。理想情況下，這專案得能夠激發你的興趣。
2.將這個任務分割成既小又獨立的任務。例如，“實現登入頁面”是一個很大的任務。解決一個任務不應該超過20行左右的程式碼。下面這些提示有助於成功做到這一點：
- 如果你不能解決這個任務，那麼進一步將它分割成更小的任務。
- 一個任務一次不應該使用太多的理論概念。
如果你不這麼做，而此時應用程式又出現了問題，那麼你就不知道你正在並行解決的多工中到底是哪個出了問題，尋找起來就麻煩多了。
4.確保自己在開始任務之前知道所有必要的理論知識。有時候，你可能不知道需要學習什麼理論，這很正常，所以你需要向他人尋求幫助：程式設計師朋友，導師，或類似StackOverflow的社群。
5.最後，你解決了任務。在解決任務的過程中，你可能會碰到很多問題，你需要做的就是吸取教訓，這也是下面要說的要點：
4.不吸取解決任務中獲得的經驗教訓
最好的情況是，你解決了任務並且結果證明非常有效。此時，很多人往往就直接開展下一個任務。但是如果你這樣做的話，那麼你浪費了一個絕佳的學習機會。
希望你能夠用以下問題來挑戰自我，幫助自己成長：
- 哪些邊界情況會導致我的程式碼失敗？即使現在還沒有失敗，有哪些應用程式狀態可能會破壞程式碼？
- 我的程式碼是否足夠整潔？對其他開發人員，甚至是自己而言，程式碼是否易於理解和改變？因為以後可能需要修復隱藏在這段程式碼中的問題，或者根據其他產品規格改變程式碼。
- 我的方法是最好的嗎？有沒有其他選項是我可以選擇使用的？各個方案的利弊？這任務是否值得用不同的方式解決？
- 此模組與其他模組是如何互動的？是否會對其他模組造成負面影響？是否容易被其他模組影響？
然而，很多時候，你會進退維谷：
5.你不知道如何處理一個任務
你不知道從哪裡開始？你可能會隨機地去嘗試，或者從其他地方複製一些你自己也不明白的程式碼。但是，這是沒有幫助的。即使你複製來的程式碼有效也沒用。因為當你今後再一次碰到類似的任務，你依然不能解決。
如果你想妥善解決任務，那麼首先你得知道你為什麼卡殼。下面是一些可能的原因：
1.沒有很好地掌握這些理論知識：
- 語言語法
- 庫或API的工作原理，某個具體方法或類的工作原理
- 程式設計正規化（例如：非同步程式設計）
- 系統運作（例如：HTTP請求是理解Web開發的關鍵）
2.任務太大了，那就分解為一個個小任務。
3.也有可能是因為你讀得太快，忽略了一些你以為熟悉其實似是而非的概念，所以無法理解任務要求。
6.你知道如何解決任務，但解決方案不管用
這是程式設計中最常見的情況，哪怕是那些經驗豐富的資深程式設計師也是如此。你的解決方案之所以不起作用最大的可能是你的程式碼中存在著bug。
如何修復？方法是除錯程式碼。這也是作為一個程式設計師需要學習的最重要的技能之一。這不是可以隨便湊合的事，也不是玩幸運猜猜猜遊戲。如何尋找bug是有具體步驟的。而且很多書中都有教這個技能。
不幸的是，這是很多新手程式設計師失去動力選擇放棄的難關。很少有課程會說明除錯的重要性。如果你不知道如何正確地除錯，那麼它就是不可戰勝無法攻克的難關。
很多人擔心會花太多時間用於除錯程式碼。這是正常的，在你第一年的程式設計規劃中這是不可避免的。
甚至，你還得學著去喜歡除錯。不妨將此看成是一個機會，一個修復錯誤提高程式設計能力的機會。當你解決了一個bug，可以問問自己這個問題：“我為什麼會犯這種錯誤？以後我該如何預防再犯？”
還有一個好主意是將找到的bug寫成程式設計日記，方便你總結和學習。
7.不知道如何接受幫助
當我們在學習程式碼，或除錯程式碼時，可以諮詢很多材料：書籍、課程、教程、導師，開發者社群等等。
在你學習這些資源時最常見的問題是，你並沒有完全瞭解幕後發生了什麼事情，也不知道概念是如何融入到更大的藍圖中的。
例如：你在某個問題上花了10小時，最後終於有人提供一個解決方案，你往往會採取“拿來主義”——採納解決方案之後就直接跳到一個任務中去。千萬別這樣做！相反：
- 思考自己之前的思維過程。問問自己，做錯了什麼，對於這個特定的解決方案有哪些是值得你先前的思路借鑑和改進的地方。
- 詢問他人的思維過程。她/他是如何解決的呢？向對方學習，吸取經驗。
8.不去應用你學到的理論
這篇文章也是理論知識，除非你能夠學以致用，否則它是不會發揮一絲一毫作用的——多多應用，直到它變成潛意思的例行程式。
程式設計其實就是通過形成良好的習慣來幫助你解決各種問題的過程。
評論(4)