在写《Asp.Net 服务器组件系列文档》之前，笔者不才，揣测微软战略用意：

• 微软利益诉求莫过于 微软产品和技术的市场份额；
• 因此，微软战略之一莫过于将 所有开发人员 团聚在 微软周围，以推动微软技术更新，微软系统的推广；
• 因此，就有了 简化编程（比如 C#的诞生），网罗开发人员（跨语言的.Net平台）等相关举动；
• 而 微软的“所见即所得”（VS开发工具中 WinForm，Asp.Net，Silverlight 等 都支持这里理念）编程理念，则将开发人员的门槛降低了不少；
• 简而言之：微软的技术取向上：让开发人员简单编程才是第一位，微软技术的执行性能可能才只是第二位或更往后；

项目开发中，技术选择的矛盾：

一家公司，同一个业务功能：

• 让一个四年工作经验的人写 100行代码；
• 或者让一个应届毕业生 基于某个技术，写2行代码（但是性能只有前者的 80%）；

问，这家公司将作何选择？

前者：

• 性能很快，代码流畅整洁；
• 项目测试或交付，发现BUG，100行代码内阅读代码，修改代码；
• 人力有限，修复BUG可能交给一些能力相对差点的人，于是 可能代码风格不一致，技术能力不一致，修复BUG时，又带入新的BUG；
• 类似的BUG也要修改，实际修改代码行数 取决于 这 100行代码如何复用；
• 最终可能出现：代码增加到 150行，修改BUG之后，性能降低，可能引入新的BUG；

后者：

• 性能只有前者80%，代码流畅简洁；
• 项目测试或交付，发现BUG，2行代码内阅读代码，修改代码；
• 人力有限，另选一个应届毕业生修改，依然2行代码，顶多5行；
• 类似的BUG，搜索一下 相关技术关键字，修改 5*N 行代码；如果是技术BUG，只用修改技术代码；
• 最终可能出现：代码增加致 5行，性能还是那个性能，很难引入新的致命BUG——代码少，BUG就少；

做过大项目的人或许都体验过 被人追着 改BUG 的情景：

情况紧急 或者 能力不足，保不准就 先贴个狗皮膏药应付BUG；

等到想起 要将狗皮膏药修改成正规代码时，自己又忙的不可开支，没时间改——只要不报错，管他代码是否规范；

因此，我也看到过某些项目完成的时候代码很漂亮，但是最后测试或交付之后，代码就惨不忍睹了。

本文当适合人群，不适合人群请自觉绕行：

• 如果你在 上面的公司技术的选择中，选择了前者， 本系列文档 不适合你。