1樓：
任何程式設計的問題都可以通過引入乙個中間層來解決，所以在實際開發中，為了解決某乙個問題常常會產生乙個新的問題，當你在網際網路、書籍中都找不到這個問題的答案的時候，你應該慶幸，因為解決了這個問題，就是你生命中的乙個進步，所以首先我想告訴你，從實踐中找到答案，所謂「紙上得來終覺淺」；
其次，孔夫子教導我們「學而不思則惘」，我們在學習的時候要注意思考和總結，試著從不同的角度去理解同乙個問題，試著在不同的技術領域尋找共性的答案，那些和語言、和平台無關的東西常常可以伴隨我們一生，而流行的、熱門的常常如曇花一現，除了讓你疲於奔命以外對技術本身可能並沒有幫助，架構比框架更為重要，不要為了學習框架而學習框架。
2樓：李科男
這和你學了很多單詞句子還是不會說英語乙個道理，你要進入英語的環境，別人都在說英語，然後別人怎麼說，你照樣學著說就行，再然後你把別人說的話改一下自己說出來，最後你就自己會說了。要不給你來個專案試試:)
3樓：馮劍超
Guy Kawasaki 說過，real people ship,then find what's wrong with it,fix the problem and ship again
4樓：peter.z
我個人感覺是這樣的，看參考書或者學習資料，然後動手做東西，常常會遇到以下幾個難路虎：
1.設計問題。不是說設計有問題，而是設計功能的時候，因為並沒有具體專案中的需求啊，目的啊，領導排版啊，pm扯淡啊，所以來來回回定不下來，最後不了了之。
很多時候，想做的東西只有個大概的概念，具體的設計沒有計畫好，最後就導致了流產。比如功能做哪些，互動做哪些，後台怎麼做，前台怎麼展現。
2.非主要任務不定。比如想學ssh，看了半天書，最後特麼js框架選來選去沒有個中意的，流產···資料庫用關係還是nosql，流產····
3.難點突破沒動力。做專案，遇到了難點，那特麼是又專案壓力的，各種熬夜查資料，通宵debug，去年做mysql同步，曾經遇到個大bug，最後是三個人搞了三天，各種人工讀byte流排查才解決的，這種強度的難點解決，在自學的時候基本就是不想幹了，流產····
5樓：
簡單的說就是少個產品經理
題主你可能只是喜歡技術，技術給你帶來快感。技術宅的乙個弱點就是讓自己high就行了，管別人要啥。而需求通常來自他人(當然自己有需求更好，可你沒有，不然你也不會來問這個了)。
跟進一步的說，這是個世界觀問題，從自己的世界裡跳出來，看看別人需要什麼，用你的技術讓他們high，而這其中的風險是你自己可能就ED了。所以如何平衡又是另乙個大問題。不過，現在那是後來的事了。
現在的關鍵是找到乙個需求，用你掌握的技術去實現它！
6樓：張文超
開始學的時候把要求稍微放低一些，要寫個http伺服器，不妨先從基本socket開始學起，簡單的回聲伺服器，時間伺服器，多程序多執行緒，聊天室。總得有個循序漸進的過程，步子邁太大容易扯著蛋。才大二，時間還多，加油～
7樓：張卉
道術器三個方面，完全想以一己之力去做乙個專案的可能性很小！！所以認識到自己不足利用別人的成果，放大自己的優勢！！做個東西出來還是有可能的！！
比如我做前端和設計，程式思路薄弱，就需要充分利用別人的框架去解決伺服器端溝通的問題。。綜合到一起最雖然不是最優方案但最起碼是乙個可以運轉的專案b
8樓：老雕
這與學英語是乙個道理，我們從小學一直開始學英語，學了十幾二十年，到大學畢業，仍然大部分畢業生一提到口語，就是狗咬刺蝟——開不了口，英語不開口說，永遠學不會口語。同理，程式自己不編寫，永遠寫不出程式。。
9樓：顧亦琛
這個問題和「知道很多道理卻依然過不好一生」這個道理是一樣的。
因為書和道理都只是理論，是思維世界的東西。而做專案和過一生都是實踐，把觀念世界的東西變為現實，是一大飛躍，既然是飛躍，飛成功的畢竟是少數，大多數都跌倒在谷底了。
10樓：Code Diy
程式設計核心能力包括抽象能力和工程能力
抽象能力，從業務工程到邏輯理論的抽象。
工程能力，從程式設計理論到業務應用的組織
題主看技術書的思路側重於前類。
11樓：夏永鋒
可以看看這篇文章：關於技術的學習方法 。
關於學習，時間短與效果好始終是一對矛盾的統一體。
很多時候，要想在最短的時間內完成一件事情，最好的方法就是依葫蘆畫瓢，但這樣的話，即使完成了事情，也只是知其然而不知其所以然，長久來看，對於學習者的能力不會有多大的提高。
從長遠來看，要想自己基礎紮實，能力強，那就得一步一步的來，從基礎知識開始，一點一點的搞懂，但這種方式需要花費很多時間，短時間內效果不明顯。而且，可能效果沒有預期的那麼好。
那麼，如果做個權衡呢？
我想，也許最好的學習方式是：先依葫蘆畫瓢地實踐，獲得一些直觀感受，最好還有一些疑問。在實踐完成之後，在整理自己的疑問，以及實踐中涉及的知識要點，通過查閱圖書或者網路資料，逐個知識點鞏固，逐個解決疑問，並整理成文。
這個整理總結的過程可能需要較長的時間。
這種方式的優勢在於：1.能讓你快速地完成事情；2.實踐中用到的知識多半會在以後的實踐中經常用到，掌握的就是一些最重要的東西，而不會學習一些很少使用的深奧偏門知識。
12樓：臧大為
兄弟。你這個問題問的人膽寒。全世界能寫作業系統的人也沒有幾個啊！你寫不出來是正常的，你大二就自己隨便弄出來乙個豈不是中國的Linus Torvalds了？
13樓：豬小喵之喵爸
你看無數部游泳教學片，第一次下水了一樣不會。
做專案靠的是真刀真槍的實踐，沒有捷徑，能少走彎路就很不錯了。
乙個工作10年的碼農。
14樓：丁長老
程式設計開發這事情，真的和木工，雕工啊等傳統工匠沒多大區別，特別在學習，練習以及提公升能力這些方面。可能最大的區別，大家用的工具不一樣，別人是刀斧鑿子，我們用的是電腦。
程式設計不是純理論研究，更多的是實際操作，在入門練習上，也是要花費足夠的時間去練習的。這點是絲毫無法取巧的地方。
多多練習吧。
15樓：黃軒
同樣的感覺在讀大學的時候也有過！在大學的時候，我也看了好多技術的書，結果少於實踐，到最後發現哪怕自己再怎麼看，好像到自己想要做什麼的時候都覺得自己好像什麼東西都學的不深。開始工做後，覺得遇到新技術，還是自己看完後，根據合理的需求，做出點東西才行。
16樓：淺海蝦
xv6太煩雜了，不建議新手從這個入門。
不如從Hello, World!開始？
從命令列實現到http服務。
服務從單程序到多執行緒到支援CGI
這一路下來，相信你學到的比死看數書要實在。
記住，一定要實踐，空想沒有任何意義。
17樓：胡力
知識還是在實踐中不斷體現出來的，我覺得整體順序應是分為這樣的三步：
掌握基礎的技術知識，這些技術知識包括你做乙個簡易專案包括的各個點；
結合實際專案，記住專案需要從簡到難，前面專案可能80%都能完成，再逐步增加專案的難度；
不斷的再補充知識，專案實施過程中肯定還會遇到很多問題，很多不了解的技術點或理論到位了但是實踐中又出現狀況，根據這些問題，再從網上或書籍中尋找答案，帶著問題去學習，這樣效果才會最佳。
掌握知識是個迴圈反覆的過程，很多時候都不是一蹴而就，需要在實踐中不斷的試錯不斷的摸索。
18樓：
乙個前端的肺腑之言:多coding，多寫布局，多寫元件，多做專案/demo，別只看書，大體上先了解一下書本上的東西，然後在做專案的過程中遇到問題，自己上網搜尋，社群裡尋找答案，再帶著問題來看書，有奇效
19樓：神經病
實踐的思路和學習的思路實際上是反著來的
我們學所有東西都是先學定理再解決問題
實踐中則是先有問題，再分析問題，分解問題建立模型，確定思路，然後實現我覺得樓主欠缺的首先是發現現實中的問題，然後建立模型，實現
20樓：
看了書並不代表著書中的知識變成了你的一部分，就像牛吃了草一樣並不是馬上變成了牛奶，得消化，得反芻，得有乙個過程，年輕人，別太著急了，心急是吃不了熱豆腐的！！！
21樓：蒸汽賽朋克
你看，有些人通過思考，把所謂的思而不學則殆這一概念重新包裝為《暗時間》。
另外還有文章，《工作十年為何還比不上部分應屆生？》
有什麼書你看了很多遍？
乙隻泡 紅樓夢 小學六年級開始看每過幾年翻出來看一遍 百年孤獨 高二的時候三天時間看的第一遍大一第二遍大四第三遍 現在工作兩年了看書的時間少了但還是時不時拿出來看看 風絲嫋 白夜行 雪穗一生中用過好多姓氏，西本雪穗 唐澤雪穗 高宮雪穗 筱冢雪穗都是她的名字，就是沒有桐原雪穗。他們的世界沒有太陽，所以...
看了很多書，當時覺得學到了很多東西，可是過段時間就忘了，要怎麼樣才能把學到的東西內化於心呢？
林微 這個問題有些泛化，學到了很多東西具體是什麼樣的知識其實會有不同的去向，例如有一些學過的科學知識就會儲存在長時記憶中，當用到的時候會提取出來。舉個例子，有一年冬天我家人在廚房做飯，突然打不開玻璃推拉門了，我爸從廚房外面上手也沒辦法開啟，這時候家裡人都很著急，我這時候聽到動靜從房間裡出來，看到家人...
為什麼我看了很多書但是記住的卻很少？
平淡一生 要學會概括吧.每一章每一節的意思去記住這本書想告訴你什麼因為我學哲學的基本都是看的書要點多根本記不住.小學不是都有概括中心思想嘛你只要記住這本書你想要記住的部分也算是一次合格的讀書 不應該有人讀完一整本書就和沒看過一樣.一句話都記不來吧.那可能是真的方法有些問題. Alyssa 怎麼說，我...