技術爭論在博客和twitter里無休止地進行著，這些爭論涵蓋每個開發人員社區。每個語言，框架，工具，和平臺在某個特定的時間都不可避免地會至少有幾個爭論在進行中。

　　下面是我多年來對技術爭論所做的幾個總的觀察，以及對一些我最近看到的，尤其是關于ASP.NET Web Forms 和 ASP.NET MVC的最新討論的一些評論。

　　關于技術爭論的總的觀察

　　下面是幾個總的觀察，無關任何具體技術爭論：

　　（一） 開發人員喜歡充滿熱情地爭論和比較語言，框架，APIs，和工具。每個編程社區（.NET, Java, php, C++, Ruby, Python等等）都如此。我認為你可以2種方式來看待這類宗教性的技術爭論：

　　1. 這些爭論有時很討厭，經常是浪費時間。
　　2. 這些爭論經常是一個既健康又活躍的社區的一個標志（因為激情意味著爭論雙方的人都深切地關注著，遠遠好過了無興趣（apathy））。

　　就個人而言，我認為兩者都對。

　　（二） 開發什么東西從沒有唯一的“正確之道（one right way）”。作為面試的開場題目，我有時會要求參試者以他們所能的效率最高的方式來對一組數字進行排序，大多數人都做的不是很好。這通常并不是因為他們不知道排序算法，而是因為他們從來不想起來詢問其后的場景和需求，而這些對理解效率最高的方式的做法是至關緊要的。數字序列有多大？典型數字序列的隨機度有多高？（是否大部分已經排好序了？數字差幅有多大？數字都是獨特的么？重復數字是否群集在一起？）計算機架構的平行度有多高？作為排序的一部分，能否分配內存還是內存必須是常量？ 等等。這些都是該問的重要問題，因為一組數字的效率最高和最優的排序方式依賴于對這些答案的理解。

　　任何時候人們聲稱某個編程問題只有一個唯一的“正確之道”時，他們幾乎總是假定了一套固定的需求/場景/輸入，而這對每個場景或每個開發人員來說，很少是最佳的。眾所周知，編程中的大多數問題比將一組數字進行排序要復雜多了。

　　（三） 優秀的開發人員使用差的工具/框架也能造出優秀應用來，差的開發人員使用優秀的工具/框架也能造出差的應用來。在根據所用的工具/框架對你正建造的應用的質量來做太廣的假定（無論好壞）時要千萬謹慎。

　　（四） 開發人員（好的和差的）可以通過延伸自己，學習新的思路和方式方法來變得更加強大。即時他們最終并不直接使用新的東西，學習這個行動本身就能以積極的方式使得他們變得銳利。

　　（五） 在技術行業里，變化是永恒的。變化可以令人害怕。但你是否被變化壓倒（get overwhelmed），歸根到底取決于你是否讓你自己被壓倒。別太擔心需要停下來，突然學一堆新東西，你很少需要那么做。 避免被壓倒的最好方法就是務實，對大范圍的東西在高的層次上保持相當地了解（而不僅僅是技術和工具，也包括方法學），有自信認識到，如果學一門新技術很重要，那么你現有的開發技能的絕大部分能夠轉移過去并且有所幫助。不管怎樣，對開發而言，句法和APIs很少是最重要的東西，問題的解決，客戶共鳴和互動（customer empathy/engagement），以及能夠專注一個項目并且訓練有素的能力，更為寶貴。

　　（六） 下面是我偶爾會給我的開發團隊的人員一些在與他人協作和交流時的引導：

　　1. 告訴別人他們很蠢，你很少會贏得爭論，無論你對他們智商問題的解釋是多么有善意，或者是多么有說服力。
　　2. 總有某個人，在世界上某個地方，比你更聰明，- 別總是假設他們跟你不在一個屋里。
　　3. 你交流的人往往會忘記你給予他們的贊譽，往往會記住以前的侮辱，- 所以說話時一定要審慎，否則后患無窮（come back to haunt you later）。
　　4. 人們可以改變主意，也會改變主意， - 所以在爭論中一定不要固執己見,他們改變主意的話,也別洋洋得意或者歧視他們。

　　（七） 當我聽人埋怨編程抽象不太好時, 我總是發現有點啼笑皆非，特別是當這些埋怨是通過博客來發表的時候，想想博客內容是使用HTML來顯示的，用CSS來做的樣式，用JavaScript來做交互的，在線上是用HTTP傳輸的，在服務器端是用高級語言編寫的應用實現的，使用了面向對象的，垃圾回收的框架，是在解釋的或JIT編譯的字節碼運行時之上運行的，博客內容和評論最終是保存在關系數據庫中的，最終還是通過SQL查詢字符串來訪問的。所有的這些都是在主機服務器上的VM中運行的，而VM 中的OS以kernel模式和用戶模式進程界限對內存進行分配，使用線程調度工作，使用信號觸發設備事件，使用抽象的存儲API做硬盤持久。等下一次你讀到 “ORM與存儲過程之比較” 或者 “服務器控件，是好是壞？” 貼子的時候，非常值得把所有這些東西在腦子里再回想一番。而更有趣的爭論都是關于特定問題的最佳抽象的。

　　（八） 編程爭論的歷史是一個漫長的無限循環，其實大多數的編程想法都早已被解決過很多次了。不管是真是假，我們今天爭論的許多問題很久以前就已在LISP 和 Smalltalk中解決了。令人啼笑皆非的是，盡管非常優雅地開創了許多東西，這二門語言卻用得不太多了，琢磨去吧。

　　針對 ASP.NET Web Forms / ASP.NET MVC之爭的一些評論：

　　下面是對我最近看到在社區里傳播的一些爭論的幾個評論，這些爭論是關于ASP.NET Web Forms 和 ASP.NET MVC哪個方案最好的：

　　（一） Web Forms 和 MVC是用來建造ASP.NET應用的2種方案，它們都是不錯的選擇。取決于應用的需求和參與開發的團隊成員的背景，對特定的問題，每個方案都可以成為 “最佳選擇”。你可以使用兩者中的任意一個建造出優秀應用來。你也可以使用兩者中的任意一個建造出糟糕應用來。你是好的還是差的開發人員，并不取決于你選擇了什么。使用兩者，你可以是絕對地棒，也可以是毫無用處。

　　（二） ASP.NET 和 Visual Studio開發團隊在Web Forms 和 MVC上都投下了大量資源，隨便哪個都不會消失。兩者在接下來的幾個月內都會有重大發布。ASP.NET 4包含了對Web Forms的重大更新 （干凈的 ClientID 和 基于CSS的標識輸出，較小的ViewState, URL導向， 新的數據和報表控件， 新的動態數據特性，新的SEO APIs, 新的VS設計器和項目改進等等）。ASP.NET 4中還會同時發布ASP.NET MVC 2，其中包含了重大的更新（強類型的輔助方法，模型驗證，多區域，更好的腳手架支持，異步支持，更多的輔助方法APIs等）。別擔心其中一個會變成死路一條或者你必須轉向某一個。我懷疑，在我們大家都死了很久以后，在InterNET某個地方還會有服務器依然還在運行基于 ASP.NET Web Forms 和 ASP.NET MVC兩者的應用。

　　（三） Web Forms 和 MVC 間共享的代碼/基礎設施/APIs 遠遠超過了參與爭論雙方的任意一位所提到的，- 認證，授權，成員，角色，URL導向，緩存，會話狀態，用戶信息，配置，編譯，.ASPx網頁, .master 文件, .ascx 文件, Global.asax, 請求/回復/Cookie APIs, 健康監測，進程模型，跟蹤，部署，AJAX, 等等等等。無論你是怎么構建你的UI的，你學到的所有常用的東西還是同樣有效的。在未來，我們將繼續投入大量資源建造可用于Web Forms 和 MVC兩者的核心ASP.NET特性（ 象URL導向，部署，輸出緩存，和我們加到 ASP.NET 4 中的DataAnnotation的驗證特性）。

　　（四） 我經常發現圍繞著編程模型之合適性和抽象的爭論有點可笑。Web Forms 和 MVC兩者都是編程web框架抽象，是建立在更廣的框架抽象之上的，以高級編程語言編程，在運行引擎抽象之上運行，而運行引擎抽象本身又是在名為OS的巨大抽象之上運行的。你用Web Forms 和 MVC創建的是 HTML/CSS/JavaScript （所有的抽象都被持久為文本，在HTTP之上傳輸，而HTTP則是另一個高層次的協議抽象）。

　　該爭論的有趣的問題不是這些抽象是好還是壞，而應該是哪個抽象你感覺最自然，哪個抽象與你項目的需要/場景/開發人員最匹配。

　　（五） 我們即將對www.ASP.NET網站做一個非常重大的更新。作為更新的一部分，我們將發表更多的全程（end to end）教程/內容（Web Forms和MVC兩者都有）。我們還將提供教程和指引，幫助開發人員很快地評估Web Forms和MVC兩種方案，輕松地學習兩者的工作原理基礎，很快地決定哪個他們感覺最好。這將方便新的ASP.NET開發人員，以及已經知曉Web Forms或者MVC的開發人員，來理解和評估這2種方案，然后決定他們想要使用哪個方案。

　　（六） 決定某個項目你究竟想使用Web Forms還是MVC，然后對此決定你要感覺高興。兩者都是好的選擇。尊重別人做的選擇，他們做的選擇希望是一個好的，并且進展會順利的選擇。記住，十有八九，他們對他們自己的業務/技能的了解要比你所了解的多得多。同樣地，希望你對你自己的業務/技能的了解也比他們所了解的多得多。

　　（七） 與他人共享想法和最佳實踐， 那是博客，論壇，郵件列單和社區的一個重大部分。它們之所以成功，是當人們知道他們的想法不會被批得體無完膚，而且他們會受到尊重的對待。請有建設性，而不是刻薄。請教授，而不是教訓。記住，三人行，必有我師。

　　希望本文對你有所幫助，

　　Scott

NET技術：關于技術爭論（尤其是ASP.NETWebForms 和 ASP.NETMVC 之爭），轉載需保留來源！

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