那什么，最近心情不錯，好久沒寫文章了，所以有想法了就記得寫一些，以后自己也可以看看，順便鄙視一下現在自己的想法，各位看官不喜勿噴。
--------------------------- 我是分割線 -----------------------------------------
根據我自己的想法和理解，IT技術體系并不能單純地劃分為軟件和硬件（有些時候，持這種理解的人問的一些很嘲諷性的問題會讓人吐血的），硬件我并不是十分精深，模糊中我認為純粹的硬件應該分為模型和電路系統這兩個部分，模具制作應該是屬于模型的，PCB板屬于兩者都有，電路設計是畫PCB的基礎和前置條件，理應屬于電路系統。兩部分難度不分上下：模型需要更多的考慮環境和人的因素，電路則更傾向于技術知識。但是根據我看到的一些情況，往往懂技術的人不少，但真正能結合模型去思考電路（也就是根據實際情況，使用者的習慣，質量，外觀等因素）的人在大學生中真的不多見。如果在本科階段就能在技術之上結合模型相關的考慮，那么這個做底層硬件的人算是真的“硬起來”了，在就業過程中應該會很受歡迎的。
有人經常會想單片機到底屬于哪一塊的東西。我這里的劃分僅僅是憑著“代碼”來作為依據，并沒有太大的實踐指導意義，僅僅是為了更方便的說明問題，做一個歸檔罷了。單片機在我眼里屬于軟件的最底層，但是考慮到軟件都是建立在硬件之上的，即使是最底層的軟件，也應該在硬件之上（上下并不止價值和難度，只是指在架構中處于的邏輯位置）。往往處于架構結合部的技術都是屬于難度非常大的，但是單片機是個例外。也許時光倒退個幾十年，單片機的確是一個難點，但是到了現在，單片機的難點正在逐步因為其自身性能的提高，軟硬件技術體系的完善所侵蝕。功能越來越完善的IDE、越來越豐富的片上資源、功能完備文檔健全的API、統一封裝的功能模塊等，這些因素使單片機編程越來越成為一個引導新手入行的工具：現今軟件的難度主要表現在大規模系統代碼設計、技術選擇和架構上，單片機的應用特殊性注定其代碼規模有限（單顆處理芯片）；硬件系統中的封裝思想愈加完善，底層模擬實現逐漸被API屏蔽。不過任何事情想要精通還是很有難度的，單片機也是如此，屬于入門容易，精深有難度。這個難度主要體現在代碼規模的膨脹和為了充分利用硬件資源而進行的代碼改革優化。代碼規模的膨脹需要編程者向純粹上層軟件體系學習架構、設計模式、算法優化等領域的知識；硬件資源的發揮也在于編程者對模塊底層實現、單片機的底層實現有一個充分的了解，主要表現為基礎知識數字模擬電路以及他們的引申知識（諸如EDA，高頻模擬電路或者類似通信等專精的電子領域知識，關于單片機和這些相關技術的學習我建議去http://www.zg4o1577.cn/ 里面的教程比較人性化）。另外我個人建議對于并發，多核編程有所了解會有助于跟上時代的步伐，畢竟這已經不再是 80C51橫行天下的時代了。
一路往上走，單片機之上應該是嵌入式系統相關的東西了。我在專注于嵌入式的學習之后和一同學習的兄弟探討嵌入式系統，覺得嵌入式系統的難點關鍵在于廣，而一個真正的大牛會在廣的基礎上對這些廣泛的知識做進一步深入的研究而達到精神，并且對于某幾項技術做到專精。因為嵌入式系統其實也是建立在MCU、CPU 之上的，上文所述的知識體系對嵌入式系統學習者同樣有效。但是與純粹的單片機編程相比，嵌入式系統的難度還體現在系統。除了要對軟件體系的基礎——操作系統要有著十分精通的了解以外，基于操作系統環境下的編程代碼規模成幾何倍數的膨脹，同時帶來的還有測試和調試難度變大，手工測試已經無法滿足要求，而自動化測試代碼覆蓋率也很難保障。基于操作系統的編程在學習過程中十分復雜（一旦掌握了開發起來倒也沒那么痛苦），要了解各種API，操作系統的各種調度機制和其架構體系（不然怎么寫驅動）。而對于專業領域上還有一系列讓人望而生畏的東西，比如說智能算法，圖像分析，穩定性實時性要求等等。我在這里沒事掰著指頭算都要算很久，就不一一列舉了。但是我著重要提到的是，嵌入式系統這個名詞中系統二字代表的并不是操作系統，而是指更加廣泛意義上的系統。具體解釋有興趣的去翻翻系統論（與控制論，信息論并稱三論）。一旦從模塊級上升到系統級，考慮的問題各種各樣，有興趣的去翻翻軟件工程吧，雖然寫著是軟件工程，對于硬件也同樣適用，個人覺得對于工程二字都不怎么了解的人有何臉面自稱工程師。那么需求工程、架構設計、編碼規范、編碼管理、系統測試、項目發布等領域的知識多少也要懂一點的（沒人愿意一輩子當小工吧）。然后別忘了還有人機交互，這個界面其實十分十分關鍵，開發過程中你至少得花30%以上的精力在這上面。
像android,windows phone,ios之類環境下編程如果僅僅是做個應用丟APP去賣的那種的話，根本算不上嵌入式系統（別以為寫了個非PC程序就算是搞嵌入式了，差別太大了），也就是一般的計算機編程加點佐料而已。
在往上走一點，那應該是傳統意義上的計算機編程了。這是一個十分蛋疼的東西，因為涵蓋面過分廣大了導致很多人都快累死了也搞不明白那是啥。還是老規矩從下往上說。最下面的應該是BIOS，這個不能被忽視，就跟嵌入式的bootloader為代表的引導程序一樣，是整個體系不可缺少的一部分，當然PC上的 BIOS我沒有太多的了解，也就不班門弄斧了。我只是想提一下匯編這門語言的重要性。我大一大二的時候經常性有學長跟我說，匯編這種東西都快被淘汰了，沒有搞頭啊，不如把時間放在別的方面。我覺得這是一個誤區。對于所有有志向在軟件編程上有所成就的人來說，代碼的效率，功能往往是重點中的重點，而匯編正是效率和功能最佳的伙伴。我這么說不是讓人都用匯編去提高效率實現功能，這對于這個時代來說成本太高，根本不科學。我要說的是，學習匯編這個過程能夠幫助所有學習軟件的人能更好的理解硬件，理解底層。有了理解后，產生的代碼自然而然會對一些效率上的硬件障礙有所規避（比如經典的乘2操作），對于這點無論是用什么上層編程語言來編寫代碼都是一樣的。此外，會匯編，你懂的，可以干很多壞事的（為了網絡環境的和諧這些請自己領悟了）。
（時間有限，我寫得累死了，下面開始稍微簡潔一點，等哥滿狀態復活了在以后的日子逐一論述）
BIOS之上是操作系統，這個其實跟嵌入式很相通的，最多操作系統種類有所區別，然后要求、性能也有所區別。這里關鍵是要了解操作系統的運行機制，一些系統級常用算法數據結構啥的（別覺得沒用，這些東西才是好東西，自己做稍微有點規模的系統時候有用得很，畢竟是一群大師的智慧結晶）。我堅信一個不懂得操作系統運行機制的人寫的代碼也好的有限。
操作系統之上的東西又海了去了，比如網絡啦，數據庫啦，并發啦，人機交互啦，測試啦等等（發現沒，哥說的都是通用型的技術，絕對不搞技術陣營化，微軟跟甲骨文鬧多大都跟咱沒關系，微軟倒閉了地球也照樣轉的，別到時候哪家公司倒閉了自己也跟著失業）。這些是純粹技術上的東西。這個時代比較流行的就是這些啦。網絡大家都懂的，多扯也沒意義，學TCP/IP協議族有多惡心看過的人都知道，但是看過跟沒看過區別還是十分大的。一些眼花繚亂的技術比如P2P之類的都是基于基礎的網咯體系的，看基礎知識總沒錯的。數據庫也是當今軟件不能少的東西，但是關鍵能力還是在于數據庫架構能力，數據庫管理維護能力，表結構設計能力等，在此基礎之上可以去搞某一種數據庫的專精（甲骨文是好東西）。并發是經常被無視的，但是沒有并發哪有現在的軟件體系，其重要性各位看官自己心里都應該明白。人機交互對于我們這些代碼男來說是最痛苦的，但這年頭就屬它最重要，第一映像嘛。這個跟把妹釣凱子一樣，長著一副*絲樣，就算有顆高富帥的心路人也不會搭理你。
另外一塊就是WEB技術體系咯，近十年最火的東西。照理說我應該多扯一點這方面的，因為內容真的很多，但我個人對其的看法是眼花繚亂前路迷茫。這并不是指的是WEB技術即將會沒落，而是對開發時程序員的狀態和技術體系的運作模式表現出一種模棱兩可的態度。WEB技術體系是當今發展速度最快的技術體系，百花齊放，各種框架和技術實現爭奇斗艷，更新換代十分快，單拿出某個具體技術進行品頭論足實在沒什么意義。任何人看到這種現狀第一反應就是好累，這種生活是一種看不到盡頭的生活。我只能說，多關注WEB技術的底層，框架的范式型實現規則和技術，通用型技術架構，交互模式，高并發后臺支撐容器，容災等等東西。最后的總結在于：會個具體技術當敲門磚開路不錯，最重要的還是學習新東西的速度，速度跟不上，別人討厭你不說，自己也會活得很累很痛苦。
最后我扯一下項目管理的東西，這并不是一項需要很多精力去翻書查資料去研究的技術，但的確是最為重要的東西，即使沒有一顆成為管理者的心，學一下這些東西也能讓自己更能被管理，理解管理者需要面對的困難會有助于交流，從而使整個項目推進更加順利，思想更加統一，也能為自己爭取到更多機會，從更高的層面看待整個世界，也會有種豁然開朗，一切盡在掌握的快感。
句句肺腑，也算對自己的一個總結。
哥累了，以后再補。