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

　　這些看法有些確實(shí)是偏見，我們大可以有力地回?fù)簟Ｓ行┛捶▍s也不無道理，跨平臺性.NET確實(shí)不如Java，主要是沒有官方的多平臺支持；論運(yùn)行效率也確實(shí)與NativeC++有天生的差距。然而很大一部分責(zé)任，要?dú)w咎我們.NET程序員。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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