技术争论在博客和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 之争），转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。