大學畢業後筆者進入一家外企，做企業CRM系統開發，那時候開發效率最高的高級程式語言，毫無疑問是C#。恰逢公司也在擴張，招聘了不少.net程式員，筆者作為應屆生，也樂呵呵的加入到.net程式員行列中。 C#.net非常容易上手，之前在大學里，做過winform和webform開發，也曾經在老師那裡承接 ...
大學畢業後筆者進入一家外企，做企業CRM系統開發，那時候開發效率最高的高級程式語言，毫無疑問是C#。恰逢公司也在擴張，招聘了不少.net程式員，筆者作為應屆生，也樂呵呵的加入到.net程式員行列中。
C#.net非常容易上手，之前在大學里，做過winform和webform開發，也曾經在老師那裡承接過小項目，賺點外快。於是在工作崗位上駕輕就熟，很容易就上手了企業開發框架，僅一年多，筆者就成為公司的開(jia)發(ban)骨(feng)乾(xian)。
C#.net的網評比Java要差，筆者曾經在知乎上看到一個國外華裔程式員的文章，內容主要是國外的悠閑不加班的生活，文末一句：“忘了說 我是做.net的”引發了討論的高潮。知乎程式員中，寫Java、python、go、JavaScript幾乎成了政治正確，作為.net程式員的筆者很少在相關討論中活躍，但對java的印象已經有了改變。那時筆者所在的外企仍在大規模使用C#.net，筆者也就拒絕去接受網上的喧鬧的聲音，專心寫好代碼，學習設計模式和前端技術等等。
恰逢互聯網行業發展勢頭正勁，筆者自然順勢而為，加入了一家規模稍大的互聯網公司，當然還是寫C#。由於之前在外企任勞任怨，什麼活都願意攬過來乾，積累到不少很有用的研發知識和經驗，於是在跳槽過程中順風順水，基本人家問什麼，我都能答出來，於是相對輕鬆地加入了新公司，開啟了互聯網研發之路。正是親眼鑒證了互聯網研發模式，才讓筆者確定了轉型Java的決定。
新公司的框架很老舊，那時還在用.net framework2.0，業務代碼非常複雜龐大，某個十年業務的項目里的一個方法，居然有一千多行，單是閱讀代碼，就讓筆者心累，更心累的是，這一千行代碼的方法名，居然被叫作“外觀模式”（facade）……很難想象公司最核心的業務，跑在這麼臃腫煩復的代碼里。性能和效率都被看重的互聯網研發模式，終於開始和C#.net產生了矛盾：.net framework和iis不開源。系統在運行過程中遇到瞭如下幾個問題：
1、介面服務項目的訪問效率遇到瓶頸，基本只能上負載均衡加機器。
2、某些大項目要數十臺機器去承載日常訪問，運維難度加大（後續上了持續集成和平滑發佈，運維方便了很多）。
3、較少數情況，系統會出現一些疑難雜症，當產生問題的代碼在閉源工具包里，調試人員幾乎束手無策。（反編譯的代碼真難看囧……）
4、不斷增加機器，成本增加，這可不只是機器成本，人家不開源，收費也不便宜……
5、可定製化較差。某些極端場景下，我們希望程式能夠更大程度的消耗伺服器硬體資源，而伺服器程式都是別人的，人家為了安全都設定好“最佳閾值”了，很難更進一步壓榨伺服器資源。
6、缺乏開源社區支撐、大數據相關研發乏力……
7、國內部分互聯網公司提供的開放平臺工具，居然不提供C#的SDK……(根據http請求自己寫SDK)
諸如此類，不勝枚舉。
轉Java吧。
技術轉型的陣痛在所難免。公司內的介面研發和後臺管理系統研發是分開由不同人員負責，能夠同時開發介面和後臺系統的人並不多。筆者技術體系相對完善，在團隊中獲得不少尊重。也曾親自帶團隊做研發，寫完介面又帶兄弟研究ckeditor源碼並做定製化修改，忙的不亦樂乎。然而轉Java成了筆者當時的心病：本職工作做得很好，團隊不會允許貿然改用Java技術棧這種冒險行為。筆者已經私下學習了許久，卻不能直接上項目實際操練，非常可惜。
精誠所至金石為開，筆者終於等來了一個機會：成為公司新項目的主程式員，負責整個項目的後端架構、設計和研發。新項目人員不多，但都是各類技術中的優秀人才，包含ios、Android和H5研發人員，筆者為他們提供介面，並開發後臺管理系統提供給產品和運營同事。
獨立負責設計和研發，工作量雖大，自由度卻大了不少，於是筆者決定用Java來完成整個開發任務。項目leader對筆者的技術功底很是信任，不過仍希望團隊用C#.net追求穩健，但看在筆者執著堅持，也就同意了。為了降低技術轉型對新項目帶來的風險和進度影響，筆者還是做了一定妥協：用Java研發介面服務，後臺管理系統仍用C#.net。
介面研發期間筆者著實吃了不少苦頭，項目框架搭建問題層出不窮，spring的運用不純熟，導致經常在框架層面報錯。新項目的座位與公司Java開發團隊座位不在同一樓層，筆者幾乎每天都要爬幾次樓梯去Java研發團隊取經。好幾次遇到問題解決不了，都想放棄然後用回C#.net。項目leader多次看到此情景曾多次施壓，筆者跟項目經理坦(zhuang)言(bi)：“如果Java搞不定，我會在兩天內用C#.net把活幹完，不拖項目進度。”靠著這份堅持和韌勁，還有多次對Java研發團隊的叨擾，項目框架終於搭建完成，筆者也藉著多次的取經，弄清楚框架的原理，完成了對spring的實踐。擁有依賴倒置、控制反轉的編程思想和設計模式的運用經驗，理解Java框架的設計思路是很簡單的，在框架搭建結束後，業務代碼的輸出幾乎是行雲流水，在項目完成之際，筆者都忘記自己曾是個.net程式員。項目最終順利上線，並且僅用兩台機器就抗住了較高的併發，筆者對Java有了更多的信任和喜愛。
有.net的編程基礎，學習Java會相對容易，但必須逃離幾個陷進：
1、對基礎知識務必要重視：C#是一門非常出色的語言，它提供的語法糖讓複雜的業務表達起來也十分優雅，搭配伶俐的lambda表達式和linq，數據結構的基本原理在大部分場景下都被弱化，而數據結構和演算法正是編程的精髓。
2、對原理的渴望和求知欲：用C#編程，無法查看大部分程式集內的方法，只能自己上論壇找或反編譯，求知欲可能會逐漸弱化。而寫Java後，經常會自己ctrl+滑鼠進入方法查看源碼。這一點Java真是非常性感。
3、懶人思維不可取：C#.net對於鏈表數組等數據結構的排序和查詢都做了高度封裝，幾個表達式就能得到想要的結果，而Java的表達式則沒這麼伶俐。在Java世界里，自己弄明白原理，自己寫是更高效、更對得起自己的方案。
使用Java完成商用項目的開發，只是技術轉型的開始，只能算踏進門，算不得轉型成功。筆者仍花了很多時間學習Java的數據結構；學習Apache的公共工具包，偶爾點進去看看實現源碼；繼續學習設計模式及其應用。在一些評估用C#研發更容易的項目，筆者仍然堅持用Java去完成。為了能有更多Java項目練手，筆者申請進入了搜索引擎研發部門，通過了Java團隊架構師的技術面試，加入了渴望已久的團隊，最終能專職寫Java做搜索引擎服務。當然，離開了當初的部門，也就拋棄了在老團隊中的地位和榮譽，但筆者覺得很值。
在多年開發經歷中，筆者確實感悟 語言是互通的，萬變不離其宗。學習新語言只要下決心並付出努力，基本都能辦到。然而後續的挑戰則是更大規模的項目的設計思路，設計模式的運用，架構設計策略，代碼堆疊方案，甚至是不同功能模塊的技術選型。這些都需要仰仗厚重的經驗、扎實的功底和日積月累的技術實力。
未來大數據和機器學習的熱潮已經如火如荼的展開，手握Java這一門利器，運用storm、elasticsearch、Hadoop、lucene等絕技的Java程式員，必然能更好的適應潮流。
