學習編程必須注意的點:這些錯你犯了多少

很多同學都在學習編程的時候會遇到這樣那樣的錯誤,有的錯誤可能暫時還沒意識到對以後的影響,這裏也是幫助大家總結了一下:

1. 不要毫無計劃地寫代碼,思考、調研、計劃、編碼、測試、修改,一個都不能少;

2. 不要寫代碼前過度計劃,在一頭鑽進代碼前做點計劃是好事,但是即便是好事,也可能物極必反。

3. 請勿低估代碼質量的重要性,如果你只能夠關注你所寫的代碼的一個方面,那麼肯定是可讀性。

4. 使用實現功能的最簡單方案,你的任務不是找出問題的一個解決方案,而是找出問題的最簡單的解決方案;

5. 適時放棄,當你開始懷疑一個解決方案的時候,你就應該考慮拋棄它,並且重新思考這個問題。不管你已經在這個解決方案中投入了多少精力。像 GIT 這樣的版本控制系統能夠幫助你分開管理和嘗試多種不同的解決方案,把它利用起來吧;

6. 擅用 Google,除非你正在使用一種極其前沿的技術,否則當你遇到一個問題時,很可能別人早就遇到過同樣的問題了,並且也找到了解決方案了。給自己省點時間,先 Google 一下;

7. 做好封裝,基本的想法就是你想你的代碼高內聚和低耦合,意思是說保持相關的代碼在一起(在一個類中),降低不同類之間的相互依賴;

8. 寫好規劃再寫代碼,儘可能編寫目前正在實現的方案所需的最少量代碼;

9. 要懂算法,使用合適的數據結構;

10. 不要寫重複性代碼,要用好配置文件,不要使用沒必要的條件語句和臨時變量;

11. 做好代碼註釋,但是不要給傻子都知道的代碼寫註釋;

12. 一定要寫好測試,如果可能的話,甚至在開始寫代碼實現需求之前,你就應該開始預估和設計需要測試校驗的情況了。測試驅動開發 (Testing-driven development, TDD)不是什麼花俏的炒作,它是會實實在在會對你思考功能特性、尋找更好的設計方案產生積極影響的。

13. 不要覺得代碼運行起來就是正確的,有些時候代碼的 bug 可能並不是顯而易見的;

14. 要能夠質疑既有代碼,作爲一個初學者,總是應該假定那些你讀不懂的、且沒有文檔註釋的代碼很可能就是糟糕的代碼。質疑之,詢問之,使用 git blame 揪出罪魁禍首!

15. 不要過度迷戀最佳實踐,我覺得“最佳實踐”其實是害人的,它暗示着你不需要深入研究它,這就是有史以來最佳實踐,不用質疑!

16. 不要過度迷戀性能優化,如果你在運行代碼之前就在優化它了,那很可能你就是在過早優化代碼了,也很可能你正在費時費力做的優化是完全沒必要的。

17. 爲你的開發任務挑選合適的工具,你可以使用最原始的工具建造房子,然後享受甜蜜時光。你也可以花費一些時間和金錢去了解先進的工具、更快地建造更好的房子。工具在不斷地改進中,你要樂意去學習它們、使用它們。

18. 要理解好代碼問題和數據問題之間的關係,即使是程序中最小的 bug 也會導致它所管理的數據去到一種不可預測的狀態。尤其是當所有數據校驗都完全在這個有 bug 的程序中進行時。

19.對代碼審查保持正確的態度,應該把每一次代碼複審當作是學習的機會,歡迎他們、感激他們、從中學習,最重要的,當你從你的代碼複審人員那裏學習到東西的時候,要感謝他們;

20. 不要過度使用共享狀態,一個新手可能會嘗試使用定時器來解決這個共享變量的競態條件問題,特別是當他們必須處理一個數據鎖的問題時。這是危險的標誌,別這麼做,注意它,在代碼複審中指出它,永遠也不要接受這樣的代碼。

21. 正視 Error,Error 是好東西。Error 意味着你在進步,意味着你可以通過簡單的後續修改就獲得更多的進步。專業程序員喜愛 Error。新手則痛恨 Error;

22. 學會休息,任何人的大腦都需要休息,身體也需要休息。

最近也是很多的同學在糾結學習上的問題,我這裏也是很開心大家給予的信任,這裏也是幫助大家整理了一些c/c++相關的基礎知識點幫助大家打好基礎,也準備了一些小遊戲小項目的資料講解,感興趣的可以私聊分享。希望大家這個假期都能有所收穫。成功一直都是給那些有準備的人。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章