眾所周知，打從.NET誕生那一天起，業(yè)界就彌漫著一股貶低.NET的空氣。許多公司排斥.NET，因為.NET低效的名聲，加之怕被微軟綁架的擔心。許多C++程序員有偏見，看不起.NET程序員，認為那些人比較菜，才學入門級的語言。Java程序員對.NET也不待見，我們會Spring，Hibernate等一大堆框架，你們除了用類庫還會什么？

　　這些看法有些確實是偏見，我們大可以有力地回擊。有些看法卻也不無道理，跨平臺性.NET確實不如Java，主要是沒有官方的多平臺支持；論運行效率也確實與NativeC++有天生的差距。然而很大一部分責任，要歸咎我們.NET程序員。

　　其實每個開發(fā)平臺，每種編程語言都有優(yōu)勢和劣勢。作為.NET程序員，我們需要更專業(yè)一點，熟悉.NET的長短之處，最大化的利用和回避。

　　我們要熟悉常用的設(shè)計模式，懂得DRY、SHY等編程原則，專業(yè)的運用Framework，寫專業(yè)的代碼。工作幾年了，不要讓人一看就是菜鳥。

　　要有專業(yè)的代碼風格，使用專業(yè)的命名。不要寫幾百行的方法，幾千幾萬行的類，里面動輒十幾層的花括號。我所見過的這種代碼，一半以上都是水分。

　　要知道要盡可能少地創(chuàng)建新對象，盡可能地減少IO和反射操作，尤其避免在循環(huán)中使用。

　　要知道對客戶輸入作驗證，要會正則表達式，要懂得如何盡可能避免類型轉(zhuǎn)換，要會高效的類型轉(zhuǎn)換方式。

　　要明白一些基本Framework常識，比如List、Dictionary等集合類不是線程安全的，知道如何保證線程安全。

　　不要再寫Request.QueryString[id].ToString()和ConfigurationManager.AppSettings[key].ToString()這樣的可笑代碼了（我實在納悶為什么一多半人都這么寫），不要到處畫蛇添足的Trim和Try…Catch了。當看到這種代碼，連自己都為身為.NET程序員群體一員感到羞慚。也就難怪其它語言的程序員看不起我們，以菜鳥的眼光看待我們了（參考《做Java開發(fā)這一年》），因為我們就是如此。

　　其實，本來.NET雖然內(nèi)存消耗大點，但運行速度總體并不比C++差多少，這點許多人已經(jīng)實驗證明了。可以參考C#的性能到底有多差 、編寫高效的C#圖像處理程序。不過如果你就是在循環(huán)中一次次做IO操作，硬要int.Parse+trycatch來進行類型轉(zhuǎn)換，甚至都懶得用StringBuilder的話，我們真該好好問問，C#不可忍受之慢——誰是罪魁禍首？

　　我不清楚造成.NET程序員群體這種現(xiàn)狀的原因。我完全是自學入門的，當然開始時寫了許多爛代碼，現(xiàn)在可能也在寫，但至少自己在不斷提高。而很多的.NET程序員，不上論壇，不看博客，頂多案頭放著一本一千多頁的《.NET高級編程》（其實是低級編程，內(nèi)容MSDN上全有）備查。

　　我估計，不止是.NET，多數(shù)C++/Java程序員也不是一天到晚學習和提高，大家需要多樣的生活。但至少，在工作中可以不斷提高吧，工作幾年了犯初學者的錯誤實在是說不過去，只能歸結(jié)為態(tài)度問題。可能是.NET比其他語言平臺都容易入門得多，許多生性浮躁的初學者選擇了它。甚至在有些人眼里，編程就是來混飯的，只要運行出結(jié)果，其他不關(guān)我的事。平庸的程序員只會產(chǎn)生消極的生產(chǎn)力（為什么新人不會編程）。當我每次為維護項目，花一整天甚至更久解決一個Bug時，我真想把開發(fā)者再抓回來，讓他們自己dogfood。

　　在此的同仁們，你們是否曾有過類似的感受呢？相信大家既然能來博客園，能看到這篇文章，應(yīng)該都是有志于不斷學習提高而來。大家是程序員中最努力的群體，至少從代碼風格上看，也跟平日接觸的.NET程序員不是一個檔次。不過現(xiàn)實中，不少人既追求專業(yè)，而對一些不太專業(yè)的用法習以為常。

　　比如今天看到一篇隨筆如何寫健壯的代碼，道法同學先展示一段代碼，然后提出了許多改進思路，這種追求每個細節(jié)的做法很值得學習，然而改進后的代碼仍有幾個問題：

　　如果要最嚴格的規(guī)范命名的話，parsedArgs不是改為_isArgsParsed，而是標準的Camel方式：argsParsed；還有只比較字符串相等與否，應(yīng)該用Equals而不是CompareTo方法；最不應(yīng)該的是出現(xiàn)了goto語句，這是不得已情況才用的。最后拋出異常時，應(yīng)該拋一個具體的異常，在任何情況下都不應(yīng)該拋出Exception異常。

　　在此，我向大家強烈推薦，如果沒有讀過，一定要讀讀《.NET設(shè)計規(guī)范》這本書，如果你之前一本書也沒看過，那也應(yīng)該先看看它。它是設(shè)計.NETFramework的大師們的智慧結(jié)晶，作為開發(fā)高質(zhì)量.NET程序的規(guī)范指南，還有什么它更權(quán)威的呢？看過這本書，幾乎可以避免所有常見的規(guī)范性問題，包括在上段提出的那幾條。

　　園子里有好幾個人寫的代碼是我們的榜樣，像老趙，裝配腦袋等人。還有一個人不得不提下，就是吉日嘎啦。作為一個半路學.NET的老程序員，十年來，不斷思考并重構(gòu)權(quán)限管理系統(tǒng)代碼，大家可以看看DotNET.Common 命名空間的來源說明，真實地說明了統(tǒng)一規(guī)范的好處。雖然大家可能因為他的商業(yè)行為不喜歡他，可誰也不能否認，至少在專業(yè)及對專業(yè)的追求方面，吉日值得敬佩。

　　最后，我想對園子的.NET程序員同仁們說，也是對自己說，專業(yè)不是來自有沒有證，而是來自我們的內(nèi)心。我們要堅持自己的追求，堅持自己的風格，要有自信，堅決同不專業(yè)進行斗爭。真正有價值的軟件，一定出自追求專業(yè)的開發(fā)人員，我們決不會寫出讓火車追尾的調(diào)度程序的。　

it知識庫：.NET程序員，我們應(yīng)該更專業(yè)點，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。