初學IT程式設計難，主要有兩種原因，一是心態，二是程式碼量。

這個浮躁的社會，已經很少有人能真正靜下心來學習做學問了，總想速成，總想著快速變現，掙錢才是王道。既然是想以IT技術謀生，技術都沒學會，自身都沒有積累足夠的價值，談何變現？

《某某語言21天入門與精通》成為暢銷書，《3個月成就全棧工程師》，竟然也有很多人趨之若鶩。瞭解精通一門程式語言的含義嗎？C、java3個月精通，簡直是奇才！清楚棧是什麼了嗎？

動不動就就精通、全棧工程師培訓！然而，到最後，猛然回首，發現自己的技術，連入門都沒達到。所以，如果真對IT技術有興趣，就拋開雜念，好好鑽研技術，不說精通，成為行業的優秀者都會發展很好了。真正掌握了技術，再來談價值！

還有，就是程式碼量。

合格程式設計師程式碼量需要達到1萬行，而優秀的程式設計師程式碼量通常保守10萬行，你的程式碼量呢？在沒有一定的程式碼量之前，不要說程式設計難。C語言也好，python、java也罷。

因為沒有實踐寫程式碼，說明沒有入門，程式碼量不夠，說明對技術瞭解不深。IT程式設計是一門技能，既然是技能，就需要訓練，只有足夠的訓練量才能使技術嫻熟。

而要說明的是，這裡的程式碼量，不僅僅是程式碼的數量，而且還包括程式碼的質量。10行程式碼能解決的問題，你寫了50行；實現一個普通需求就在網上搜人家的原始碼，還沒弄清楚程式碼，只要能實現功能就貼上複製，這樣的程式碼量，不要也罷！

程式碼量，在一定程度上衡量程式設計師的技術水平。而這個量，是程式設計師經過思考，設計，實現的程式碼數量。

如果題主是一個能堅持的人，其實程式碼是不難的，關鍵是要找到一個切入點，而不是盲目的學習，因為程式設計涉及到非常多的知識學科，但是入門的話可以先從一個學起，從一個主題學起，比如目標是做個安卓手機APP，實現一個簡單的動畫功能，那麼就可以先從Java語言學，然後再學習安卓開發，當然也可以先吧安卓開發環境搭建好，找一些demo先跑起來看看效果，增強一下自信，學習本身就是一個枯燥且有趣的事情，要學會堅持學會發現樂趣，希望你能學會.

程式碼不難學，難學的是否擁有從接觸這行到能堅持下去的決心大不大。

可以告訴這位同學，你學習時不妨把程式碼看成是學習內功心法，古有宗師需要成大師者，無一不是透過日夜刻苦修煉方可成功，寫程式碼也是一樣的道理。在我們這行，寫程式碼的能力就是不斷的在工作生活中，提升出來的，只有你多寫多看一些比自己厲害的人的作為參照、不斷的提高自己寫程式碼的邏輯思維、抽象能力等等，才能使自己編碼變得厲害。

寫程式碼，如果想做程式設計師的話，一定要靜下心來學習一段時間，如果有機會入職一家公司工作可以進去磨鍊一下，因為自己自學的效果和進度不如投身在工作以後透過專案來提升，總結起來就是：在職業前期不要三心二意的學習，踏實刻苦的投入精力到編寫程式碼，提升編碼能力、多多敲寫程式碼，將程式碼編寫訓練成一種“自我反射”即可(達到遇到一個邏輯問題可以隨時透過程式碼去編寫的程度)。

祝這位朋友能早日達到程式碼“大師”的水平，加油！

有志者事競成，別人說簡單不一定就簡單，你感興趣想去學就容易，要是一時興起就算了。

程式語言本身的難度並不高，但是要想透過程式語言來解決一定的問題，尤其是數學問題，就有一定的難度了，當然這往往都是專業領域的工程師才會面對的問題，普通人學習程式語言大多都是為了完成某一個具體的功能，所以涉及到演算法和資料結構的地方並不多，難度自然也就比較低了。

表面看程式設計師們看似一帆風順，實際上他們都飽嘗過學習程式設計的痛苦，只是他們都壓抑著沒有說出來。每個時期的學習都是不一樣的。

初學新手手把手輔導的蜜月期

每個即將進入程式設計行業的人都滿懷期待，這很正常。一方面，你在剛學的時候總聽流言說程式設計如何如何難，但它們就像老奶奶講的嚇人故事，是用來唬孩子們去學習社會科學而已。而另一方面，“學習程式設計”運動已經取得了很多成就，它打破障礙並向人們展示程式設計其實也沒那麼可怕。 先要學會運用軟體，像 Codecademy、Treehouse和 Code School 這樣觸手可得的工具，它們可以確保你不僅能學會程式設計，還能成為一名熟練的開發者。

而且最重要的是，這些入門工具就像教小孩過馬路那樣，引導你學習那些令人頭疼的變數和條件語句，以及初級程式設計語法。當你不斷完成遊戲般的挑戰時，你的自信會隨之大增。說不定你最後就學會了程式設計！學會程式設計並不難，基本上你已經是一名開發者了。一切才剛剛開始……

手把手輔導的蜜月期，這個階段充滿了樂趣，面對看似棘手的問題，那些高質量資源的鼎力相助讓你輕鬆取勝。雖然你主要學的是基礎語法，但完成的工作會讓你很有成就感。

充滿迷惑的下滑期

在這個階段你會痛苦地發現，手把手輔導的階段結束後，事情變得更困難了，實際上你沒法獨立做任何事。在你試圖重新振作時，你面對的首要挑戰不僅是要反覆除錯，而且你還不懂怎麼問問題。

絕望的迷茫期

這個階段漫長而又孤獨。在這個沙漠中幾乎沒有路，每個方向都看似正確，但你卻總是在繞圈，你極度渴望找到辦法逃出生天。警惕“狂燥中出現的海市蜃樓，它們就像是沙漠的迷魂曲，將引誘你誤入歧途。

煎熬的上升期，這個階段裡你終於找到了一條路走出沙漠，並且總體清楚瞭如何建立應用程式。但你的程式碼仍然很封閉，到處都是漏洞，就像紙糊的房子一樣搖搖欲墜。你的網站可以執行並且你已經掌握了幾種有效的模式，這些都讓你的信心大增，而且你的朋友們都在稱讚你的網站很酷，但實際上你知道底層連自己都不忍直視。你根本不知道該如何寫出“可釋出”的成熟程式碼。

小心了！你即將踏出懸崖，多少英雄在此折腰淪為“程式設計太難”一族。這錯誤的一步發生在你第一次在鍵盤前坐下，開啟文字編輯器並試圖從零開始建立一個工程，但你卻不用任何很讚的線上編輯器，也不用別人的程式碼框架或尋求有用的提示。

也許你能照著自學教程依葫蘆畫瓢，但是沒有人可以一步登天，而且從某種意義上來說，你要徒手從一個空白的文字檔案開始簡直是異想天開。

困惑的下滑期

你開始建立工程。你抓耳撓腮卻只找到了一個勉強能用的方案，但總覺得哪裡不對。為了你的星河戰隊（也就是你的大工程）能表現不錯，你陷入了和bug的戰爭之中。似乎只有透過一鍵谷歌才能解決每一個問題，你那些過去能搞定問題的自信蕩然無存。任何人寫的程式都可能有bug，但我們還是希望你能有所進步，因為最不可能的地方也能成就最偉大的成功

儘管艱難，最終你一定會成功。那時的你心情澎湃，渾身充滿力量，絕望的荒漠已經過去，而令你困惑迷茫也成了遙遠的回憶。終於，你是真的在走上坡路：你的學習速度更勝從前，也更理解如何學習程式設計。儘管歷盡艱難，但你會經歷足夠多的最佳實踐，把那些寶貴的知識凝結成產品級的技能集。這個可怕的上升期會比你預想的要長，也會讓你感覺看不到頭，因為你已經離終點如此之近，但你肯定會到達的。如果你在正確的道路上足夠堅持，一定會有人願意付薪水給你，讓你繼續學習。工作機會是你的了！

這個問題提的很對，程式碼就是很難寫，因為就是故意的，原因，如果用中文寫程式，因為中國的語言多種多樣，比程式碼表達能力還要，強，用中文人人都會，寫程式碼，可是自主權，也就是晶片，外華人掌握著呢，他能讓你輕而易舉的學會嗎？

所以啊！只要是這些漢奸倒了臺，中文程式碼，中國晶片馬上就出來

首先要有興趣，沒興趣再簡單也白搭，有興趣再難也不是問題。

所以先要培養興趣

其次，現在網際網路上有很多學習資料，入門已經不是一件難事，挑選一種程式語言，Python，Js，java都可以，學一門語言，做一個簡單的專案，由淺到深，再由深到廣

如果您是初學者，建議直接學C#吧，先從命令或者winform開始學，因為winform是圖形介面，拖拉控制元件就可以做出簡單功能，當你有些小成就了，興趣自然也就更高了。

看你要基於什麼目的學程式設計了，C語言 是一種可移植性和多系統平臺的程式語言 JAVA 是一種功能強大可移植性強的開發語言 HTML 是一種超文字標記語言 Java Script 是一種基於客戶端的指令碼語言 程式語言，顧名思義就是一種語言，是用於交流的，程式就是計算機的語言和人類語言的翻譯者，我最近是在學python ，它很簡單，可以我有java的底子，透過它來解決很多演算法問題

講的直白點，程式碼這東西就是將生活中的流程進行抽象的結晶，透過程式碼的形式表現出來。事實上，我們每一個人都有學習程式設計的潛質，因為程式碼邏輯就是來自於生活呀。建議多瞭解資料結構，對抽象思維很有幫助。

很多人不明白程式碼意味著什麼，程式碼意味著要隨時理清這一坨：

讀程式碼：找到圖中兩個節點之間的可能路徑。

改程式碼：替換一個節點，完整地保證那個節點和每個節點之間的連通性，正確性。

寫程式碼：新增一個節點，然後（其實不管你怎麼）連到原圖中。

產品經理：我其實根本就不關心這些線是怎麼連起來的。

以上，讀程式碼是NP難度，寫程式碼，不好意思，對很多人是P級別的。

首先，就不說寫的爛的程式碼了，只說寫的好的程式碼。寫的好的程式碼，依然是很難閱讀的。寫的好的程式碼，一般是遵循一些原則。而這些原則，很難從最後的程式碼中反推出來。這些原則一般都是 declarative knowledge，而我們看到的程式碼大多是 imperative code。即使是 functional program 或者 declarative language 的 code，一般也是用低階的抽象來描述高階的原則。

舉一個類比，目前體育比賽中很多規則的修改，都是借鑑以往比賽中一些舊規則導致比賽比較沉悶，或者被運動員鑽空子的經驗教訓。但是單單去看這些規則，你無法反推出來它們是為了避免什麼情況。

所謂的「讀懂寫的比較好的程式碼」，一般是從程式碼以外的途徑瞭解作者的意圖。然後再掌握作者貫徹這些意圖的一些基本習慣。遵循原則的程式碼已經如此難以閱讀，事實比這個還糟糕。任何原則應用於具體問題，都有例外。所以在任何程式碼中，都有遵循原則的程式碼和例外的程式碼。好的程式碼只是減少後者的比例，而無法完全杜絕。

好的程式碼，讀起來容易，但這是有前提的——就是你得跟作者有相同的知識背景。當然這一般是達不到的。就算人家有註釋，說不定你得把註釋當成關鍵字，好好地Bing一把，學他個三五個月，你才能理解作者的意圖。

自我開始程式設計以來，我一直覺得讀別人的程式碼的難度，要幾倍於自己寫程式碼。一直以來我都很困惑，難道是我技藝不精，所以讀別人的程式碼很困難麼。其實不是，我能看懂程式碼中的每一句話，並沒有我不認識的語法，但連在一起就不懂為什麼作者要這麼安排程式碼了。後來我漸漸有了一些想法，程式碼是程式設計師給計算機的命令，是作者思考過後的產物，但思考的過程卻沒有體現在程式碼上，這就好比一道數學題，只有一個最終答案，所有的計算過程都被省略掉了，自然難以理解作者的意圖。

一段程式碼一開始寫出來，後來發現存在問題，陸陸續續地改過好幾版是很常見的事情。最終版本中可能每個小的細節，都是作者花了很多時間試錯的結果，但這個試錯的過程並沒有直接地體現在程式碼上。另一方面，程式碼中往往存在一些「隱含前提」，例如假定函式的引數已經在傳入之前被以某種方式處理過了，這個假定很可能於另一個檔案的某行程式碼有關，這種聯絡很難引起閱讀者的注意。當然，好的設計可以緩解這個問題，但很難被徹底地解決。程式碼的歷史會被儲存在版本控制系統裡，但說實話，按我的經驗，很少真的有人去翻版本歷史，因為正確地使用版本控制工具相比起寫程式碼是一項比較不受重視的技能，在這種情況下翻歷史是非常耗時的。

當然，有些人會將一些細節以註釋的形式新增到程式碼中，但註釋也只能承載很小的一部分資訊，因為維護註釋也是一項很高的成本，我個人一向是反對添加註釋來解釋程式碼的。所以閱讀程式碼實際上並沒有看上去那麼輕鬆，為了徹底理解一段程式碼，很有可能你需要付出和編寫這段程式碼差不多的努力，來了解這段程式碼的歷史和前提。前面提到的是閱讀「好的程式碼」的情況，比如大多數活躍的開源專案，如果是面對質量較差的程式碼情況就更為糟糕了。所以我的觀點是，讀程式碼絕對不是一種好的學習方式，我認為學習一項技術應當先閱讀書籍，然後嘗試自己實踐，最後再參考程式碼質量較高開源專案。對於大多數專案而言，可能從未把「供他人學習」當作目標，只有當你自己實踐過，積累了一些經驗並且也遇到過一些困難的時候，你才能讀懂程式碼並且從中學到解決問題的技巧。而在開始實踐之前，最好的知識來源是書籍，因為書籍的內容是經過精心的安排的，最高目標就是供他人閱讀。

用熱力學來回答一下這個問題：因為從思路轉換成程式碼是熵增加的一個過程，要把程式碼重新整理成思路是熵減少的一個過程。

好比一副有序的撲克牌很容易變亂，已經變亂的撲克牌要變有序需要做更多的功。所以，寫程式碼容易，讀程式碼難。