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

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

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

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

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

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

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

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

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

      其實(shí)，本來.Net雖然內(nèi)存消耗大點(diǎn)，但運(yùn)行速度總體并不比C++差，這點(diǎn)許多人已經(jīng)實(shí)驗(yàn)證明過了。可以參考C#的性能到底有多差 、編寫高效的C圖像處理程序。我們要了解.Net，支持.Net，反射機(jī)制和異常處理等本是.Net的先進(jìn)特性，不要把它們變成性能殺手，為攻擊.Net的陣營(yíng)制造磨刀送箭，反過來砍向.Net。如果你就是在循環(huán)中一次次進(jìn)行IO和反射操作，硬要int.Parse+try catch來進(jìn)行類型轉(zhuǎn)換，甚至都懶得用StringBuilder的話，我們真該好好問問，C#不可忍受之慢，誰是罪魁禍?zhǔn)祝?/p>

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

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

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

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

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

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

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

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