⑴ 為什麼很多人會覺得IT門檻低
門檻很高！！！！！編程很難！！！！
⑵ 做加工中心組裝跟操作編程哪個有前途
組裝可以向設備調試、維修方向發展。目前來看，搞加工中心維修，真能幹活的，收入還是相當高的，年薪10多萬一般沒有問題。當然～向這方向發展，也是要代價的，要努力鑽研，成天就想混日子，一輩子就是個打下手的小工。
搞操作編程，干好了，當然待遇也很好，也是了不起的人才。但是實際情況是，在這方面干成專家高手還是比較困難的。一個問題是知識基礎，還有一個問題是工作中面對的實際條件，經常制約你的視野。比方說，我也很想搞搞五軸聯動機床啊，但是我這里沒有這種機器，單位也不可能去買。我也很想乾乾高精尖的產品，也想給宇宙飛船和航空母艦的關鍵零部件出力啊，但是企業實際情況是～全都乾的傻大粗的東西。 干這個，如果工作環境不是太好，可能需要在努力鑽研的基礎上，多次跳槽技術才會比較全面扎實。
其實數控機床編程這個東西，編程還是相對比較簡單的，學起來不算復雜，難的是工藝經驗的積累，基本工藝原則的靈活掌握。程序員算不得啥，工藝掌握深了，工藝專家價值很大。所以我說要多次跳槽加努力鑽研，就是要用過更多類型的機器，干過更多類型的產品。
其實，不管幹哪一行，只要努力鑽研，努力學習，都會干出成績，都可以成為很有用的人才。樓上說搞組裝就是個鉗工，鉗工很差勁嗎？優秀的鉗工，難找得要命，高薪也聘請不到。最好的機器，終究要依靠優秀的鉗工才能誕生。要是干成實打實的鉗工高級技師，恐怕也是蠻可以吹牛的事吧。
⑶ 編程看不懂代碼，迷茫。
其實看不懂才是正常的，看懂才是不正常的。即使已經學習編程多年，即使做軟體開發多年。
總結一下你問題的核心——源代碼。
很多人在說多練習、多學習基本上都與源代碼有關。
但是，這對你軟體開發能力沒有太實質性的提高。
首先我們要清楚，編程或者編程語言的作用時什麼？它不是為了編程而編程。我們為了實現某種軟體功能，需要通過編程來實現。而軟體是為了解決實際人無法解決或花費很大成本的工作，由軟體可以很容易解決或成本比較低。
而編程和編程語言只是實現這個軟體的一種工具、方法。
為什麼說「看不懂才是正常的」？
現在隨便一款具有實際功能的軟體，就需要幾百、幾千甚至幾萬個源代碼文件，而每個源代碼又有幾百、幾千甚至幾萬行源代碼。計算機源代碼不是小說，從頭看到尾就行了，源代碼內部會形成復雜的關系，函數之間互相調用、函數使用公共變數、類之間的繼承等等。在這么復雜的系統里，能把源代碼看懂是非常困難的。
同時通過閱讀源代碼來理解這個軟體的完整功能，這種方法效率低、收效低。
源代碼是通過某種編程語言書寫，而源代碼中必然包含與這種編程語言相關的語言特徵，而這些特徵往往與這款軟體的功能沒有實際上的關系。也就說，源代碼中包含了大量對我們理解軟體功能沒有用，甚至反作用的信息。就好像我們要在一萬本書里找一本我們需要的書中的一頁。想想效率多麼低。
軟體設計資源也是分層次，它是在不同的工作階段產生，例如前期有軟體需求信息，之後有軟體設計信息，而源代碼幾乎是最某端的產品。
而有時很多人要了解的是軟體設計信息，但是我們卻要通過閱讀源代碼來了解軟體設計信息，而在這個過程中閱讀者必須將源代碼中很多多餘的信息給去掉，則能總結成軟體設計信息。想了解軟體需求信息也是同理。
總之很多時候我們在一個層次上去了解另外一個層次上的信息，這難度是非常難的。看源代碼只應該解決與這個源代碼相關的細節問題。
宏觀問題由宏觀方面解決，微觀問題由微觀方面解決。而源代碼是微觀內容，而軟體設計信息、設計意圖等屬於宏觀內容。
至於你看不懂源代碼沒有關系。
並且寫源代碼也不是問題，寫源代碼不是為了寫而寫。只要清楚你寫什麼，寫本身就不是難度。而軟體開發中需要寫什麼呢？就軟體開發前期階段的分析和設計。而分析和設計的結果就是軟體的解決方案，而這種解決方案就是寫源代碼的依據。
《UML2.0實戰教程(Trufun)》
《面向對象分析與設計(UML.2.0版)》
《UML與軟體建模》
不知道你有沒有看過UML語言（統一建模語言），它是現在面向對象設計理論方法最常見的語言。雖然它叫語言，但是它不是編程語言，它與軟體分析和設計有關的語言，是用於描述軟體解決方案的語言。
《UML2.0實戰教程(Trufun)》中就簡單的介紹了使用UML進行面向對象設計的方法。而它所形成的軟體解決方案，就可以通過某種方法轉換成編程語言。《UML與軟體建模》第十二章中有介紹。