初學者學編程，是看項目源碼學習，還是看著書一步步敲代碼見效？

01-03

因為看著學習叢書敲代碼，總感覺思維固化，敲代碼還不如手寫練字，在白紙上默寫代碼好

看書+敲代碼。

正兒八經的項目源碼不是為了給菜鳥看的，你還是找點學習坡度比較正常的入手比較好。

學習從書看過一兩本就可以了，學習編程還是要靠動手實踐。

自己設想一個小程序，不找示例，嘗試自己實現出來，比如俄羅斯方塊。

分階段吧，以下按順序，

1. 看書敲代碼(模仿)

2. 做題(書本練習)

3. 大作業(超過500行，完成有點複雜功能的程序)

4. 繼續寫代碼，積累超過2000行的作業級別的代碼，

5. 學點軟體架構知識，模塊化設計的理論，編碼風格規範，

6. 看別人的優秀項目吧，開源的庫/工具/小遊戲，不一定太大規模(有很多幾千行代碼，非常優秀的項目)，

去做自己開源吧，

這時，你已經不是初學者了

單一的看書敲代碼，或者默寫代碼，又或者只看源碼效果都不好。因為少了「理解」和「及時反饋」這兩個環節。

以前我看書或者看別人寫的代碼，覺得自己明白了。可是到了自己寫的時候，忘得很快，或者不知道為什麼別人要選擇這種方法。
如果題主不幸選了一本有長代碼但是內容很枯燥的課本。。。我真是理解你的心情。你回憶一下，純記憶的效果怎樣？能不能在不看書的情況下寫出不出錯的代碼？給別人解釋為什麼要這麼做？其中的好與不好在哪裡？
如果只是看源碼而不是動手參與的話，與看書一樣達不到理解的地步。但是有意思的項目可以極大增加人的好奇心和求知慾，好過看書。

對我最有效的辦法---做項目+問問題。

同類的還有：codechef, codecademy, uva online judge, codeforces, codecharts. 看你口味。

遇到問題可以搜stackoverflow。這個社區會友善幫忙搞定error，還會告訴你可以提高的解法。如果問題清晰的話回復很快，這種反饋會加深你的理解，提高你的代碼品味，好過自己悶頭寫。因為自己寫的時候，往往沒有error就覺得沒問題了，很難察覺設計的不好的地方。工作之後你會明白，讓別人看懂你的代碼比代碼沒錯重要一萬倍。
等你順利進階之後，可以Google 「github most interesting [programming language] beginner project. 接著升級。
搜公開課，例如 udacity, coursera, edx 等等，選一個喜歡的課題，比如web development, machine language 等等。其實很多introduction的課程不需要編程基礎，題主要是更喜歡有人設計好的課程，可以試下效果如何。
以上辦法對我是很有效的，只是假設對題主也會有效。如果題主覺得學編程痛苦，也許得更重要的是發掘另一種更好更適合自己的方法，而不是痛苦的繼續努力。
這麼多方法，那種最合適呢？你自己都試一下就好了。如果找到了好辦法，效率猛增；如果這個辦法不適合你，你很快就會知道。

知乎的第一個回答給這裡吧，如果你已經學習了基本的語法規則和常用命令，給你個網站Problems - Project Euler 自己去慢慢玩吧，搞不定就Google

關鍵就兩個字『理解』

編程類的書籍，一般來說深度低一些，初學者可以從這裡出發，但是你跟著敲，也是得動腦子，不然你照著書敲10遍，沒理解進自己的腦子，知識還是書里的知識，不是你的。

看項目源代碼的話，如果你到了看得懂，能理解的程度，自然是優秀的項目源代碼能帶來的收貨更大。

最後，編程是個動手活，最終還是要付諸實踐，切勿做嘴巴選手。

自己做個小的項目比較好。

理解的基礎下敲代碼，只看代碼就不敲就想學會編程的都是耍流氓

剛開始學，就看項目源碼的話.........................................、.、.可能程序入口都找不到的
。

基本的還是先練習敲，等你後面著手做項目時候，先看源代碼，找找思路，然後自己試著編，源代碼是給你思路用的，學習前人是怎麼編的

光看書不寫的話寫出來的代碼過編譯器都很困難= =

我們那時候學ics 沒有ide 就是用vi寫完了gcc編譯

很多人到現在都不會調error

編程能力還是要通過做項目來提高的