從大一入學開始就有好多同學跟我討論過程式設計該怎麼學
我呢，也沒什麼資歷，寫過的程式碼不多，用過的語言也很少，到現在還沒有寫過大工程，物件導向程式設計學過也沒咋用，都忘光了，主要就是寫程式導向面向演算法的程式還稍多一點，既然大家信得過我跟我討論這個問題，那我就盡我所能盡我所知給剛接觸程式設計的朋友們提一點個人的建議吧
首先最重要的就是多寫寫程式碼，感覺資訊類的學科有一個和其他工科一樣的特點，它的學習和應用是一個共通的過程，用的時候才會發現有的地方該怎麼寫，發現有什麼東西不會就可以去學，要是光學不寫的話肯定過兩天就忘了。計算機語言的語法相較於自然語言的確較死板，卻也有其靈活之處，這些靈活的地方，什麼時候該怎麼用，是著書者最想帶給讀者的，卻也是他們做不到的，因為這是一個很經驗性的東西，是一個在實踐中積累下來的結果。很多人找我要過程式設計練習平臺，我每次都是推薦的http://noi.openjudge.cn/，這個平臺是對全社會免費開放的，題目質量還是挺高的，數量也不少，而且難度梯度比較小，覆蓋面廣，對於沒有競賽需求的本科生（不管是不是資訊類）大學四年用這一個OJ就足夠了。
還有就是多和別人交流，多看看別人寫的程式碼，然後你就會發現，“哦原來這個地方應該這麼寫”或者說“這個地方還能這麼寫”，這還是很有啟發性意義的。做到這一點就要在平時多結交一些同樣喜歡程式設計的朋友，這樣就可以和他們分享程式設計過程中遇到的困難或者收穫的感悟；另外開源網站是一個很好的平臺，開源即公開原始碼，好吧其實就是往上面放程式碼，比如Github，現在開源網站上的程式碼很多其實是直接被當做黑箱演算法封裝起來引用的，這是開源網站的一種意義所在，但遠遠不是全部，交流和分享、促成思維火花的碰撞其實才是開源網站的本意所在；開源網站上能看到的往往只是程式碼，那麼在部落格上你就可以獲得你想要的一切，從講解到例項，以及程式碼，國內知名的部落格平臺有部落格園和CSDN，在這些平臺上可以搭建自己的部落格，也可以閱讀上面的優質文章或是和其他博主交流，很多資深程式設計師更是會選擇搭建獨立域名的獨屬於自己的部落格，以在頁面設計、訪問功能等方面獲得更大的自由度，達成更好的效果。
然後是程式碼除錯的問題，好多人都反應程式碼寫不對，調也調不出來。首先寫不對是不可避免的，程式碼寫的再多也難免有些地方出錯，不過多寫寫程式碼對避免犯一些低階錯誤還是很有幫助的。其實在實際應用中很少有一次就能寫對的程式碼，所以除錯是每個程式設計師必備的技能，具體的除錯方法這裡就不再贅述了，如果有需求的話可以私戳我，我會單獨再出一期。很重要的一點是，一定要自己動手調自己的每一個程式碼，嘗試使用一切可以使用的手段，模擬各種可能出現的情況，構造各種不同的資料，除錯的結果不是調對，而是要保證程式碼的執行完全符合你的演算法設計，因為這就意味著你的程式碼已經完全實現了你的具體演算法所期望它實現的功能，除錯就可以算是完成了。
程式碼調多了其實就會形成一種反向推演的能力，剛開始調程式碼肯定就是根據程式碼流程一步一步去查哪裡出了問題，調多了之後就可以根據程式碼的執行結果，結合資料的特點，去推斷程式碼哪裡出了問題，再針對性的進行檢驗。比如說我原來跟研究生學長寫的AI下過五子棋，科普一下，五子棋的狀態量很小，以現代計算機的算力配合不錯的演算法是可以完全覆蓋的，也就是說人類在理論上根本沒有戰勝電腦的可能，但我下了兩盤發現AI在邊界處理上出了問題，並最終利用這個bug戰勝了AI。開個玩笑，如果影視作品中AI試圖征服人類的情節真的發生，那麼人類反抗軍的中堅力量一定是程式設計師，因為只有演算法的設計者最懂演算法的弱點；另外就是有一次填表的時候，填日期，我填的7.10，七月十號，但是每次編輯完成之後總是自動變成了7.1，我就覺得這表格是不是對填入內容的長度有限制，結果後來看7.11，7.12都沒事，就想到這個程式可能是把7.10看做小數來處理的，自動把末尾的0忽略了。這兩個程式對我來說都是完全的黑箱，我沒有參與過其中的任何演算法設計和程式碼編寫的過程，也未曾編寫過內容相關的程式，但依靠執行情況，結合以往除錯程式的經驗，我們仍然可以對錯誤之處做出較為準確的判斷，更別說是自己實際參與設計甚至編寫的程式碼了。所以說，調程式碼的確是一件很折磨人的事，但它並非沒有意義，對程式碼除錯敏銳度的提升也並非無解。
就先這麼多吧，只是一些個人的觀點而已，可能用處也不大，希望每個接觸程式設計的人都能愛上程式設計，駕馭程式設計！