.NET Framework开源给开发者带来不同影响
2018-06-11 来源：
一些.NET Framework的源代码开放了，基于MS-RL许可，并提供调试整合到VS 2008当中了。从旁观者的角度来说，这是Microsoft迈向开放与社区化合作的一大步，很多人也把这当作历史性事件，然而对于一般的开发者而言呢？这事情到底有多大影响力呢？我认为对于开发者来说，不同角色的开发者遭受的影响是不同的，并且整体影响是导致分工继续细化。
.NET最内层的本质是什么？Microsoft曾经非常引以为豪的COM，.NET只是这种思想一路实践并且进化而来的结果。.NET最开始设计为满足 RAD的需求，以便吸引使用其他语言、框架的程序员转移过来，然而开放源代码后RAD的程序员仍然是RAD的，这对他们几乎没有任何影响。想象你是一个习惯于拖放一切的ASP.NET开发者，基本上不想写任何业务逻辑之外的代码，数据访问层用Typed DataSet或者Linq to Sql搞定，界面用现成的Control和Extender，Microsoft这次提供的源代码对你有什么意义吗？因为你不需要自己编写Control 或者Extender，自然你不会花时间去了解有关的模式，也无须查看内置控件的代码。如果你调用内置控件出问题了，在Google以及调试内置控件之间，你显然会选择前者。因此，对于习惯于RAD的程序员来说，开放源代码这件事是没有任何直接影响的。
然而，有些间接影响是不能忽略的。前面提到了使用Google搜索问题的解决方案，然而Google自身并不懂得解决问题，答案其实来自于其他已经把问题解决了的程序员，因此这些源代码如果确实帮助了其他类型的程序员解决了问题，那么也就间接帮助了RAD程序员。
那么，还有哪些类型的程序员呢？例如，做稍微底层一些工作的，编写Control、Extender、HttpHandler、HttpModule等可复用组件以便为自己或别人提供方便的。编写可复用组件最糟糕的地方就在于它是可复用的??你永远不知道别人会将它以什么样的方式用在什么样的环境，因此按照一定的模式开发这些组件以便保证兼容性就很有必要，而模式本身最好就参考自.NET Framework内置的同类组件，除非你想更大范围地研究.NET Framework并重新发明轮子。因此研究与模仿内置组件的行为是组件开发者的必修课，而从ScottGu文章（Releasing the Source Code for the .NET Framework Libraries）中的截图看来，内置组件丰富的注释将有助于程序员更轻松地理解其原本的设计方式，从而更轻松地在自己的组件中模仿内置组件的行为。事实上，有很多内置组件是设计为对另外一些内置组件特别照顾的，这类型的耦合在Reflector中阅读代码时是最难以理解的，如果阅读有注释的代码相信会轻松不少。
最后，开放源代码可能将会导致对.NET Framework进行纯粹思想或理论作研究的人数增加。事实上，无论.NET Framework多么倾向于实用型，如果Microsoft需要获取来自社区的创新思想，还是必须吸引一群思想家的，否则大多数的社区创新都只是应用与应用方法，Microsoft还是独揽.NET Framework前进方向的控制权。这种中央集权有它高效的地方，特别是发展初期，Microsoft能够根据自己的实力战略性地安排新特性的研发顺序。
然而Microsoft也曾经因此吃亏，例如ASP.NET 2.0没能引入AJAX支持，直到最后才急忙补上一个Callback特性，并承诺日后开发完整的AJAX库。因此，倾听来自社区的观点很重要，而要求社区有观点就必须先提供素材给他们讨论，开放源代码将能够激发社区对.NET Framework的研究热情并且提供更多能够作为反馈信息的新观点。
因此，就.NET Framework开放源代码这样一件事情而言，对于不同的开发者其影响的大小是不同的。同时我们也能预期Microsoft本身肯定也是最大的受惠者之一，否则以其智慧绝对不会做这样一个决策。
.NET最内层的本质是什么？Microsoft曾经非常引以为豪的COM，.NET只是这种思想一路实践并且进化而来的结果。.NET最开始设计为满足 RAD的需求，以便吸引使用其他语言、框架的程序员转移过来，然而开放源代码后RAD的程序员仍然是RAD的，这对他们几乎没有任何影响。想象你是一个习惯于拖放一切的ASP.NET开发者，基本上不想写任何业务逻辑之外的代码，数据访问层用Typed DataSet或者Linq to Sql搞定，界面用现成的Control和Extender，Microsoft这次提供的源代码对你有什么意义吗？因为你不需要自己编写Control 或者Extender，自然你不会花时间去了解有关的模式，也无须查看内置控件的代码。如果你调用内置控件出问题了，在Google以及调试内置控件之间，你显然会选择前者。因此，对于习惯于RAD的程序员来说，开放源代码这件事是没有任何直接影响的。
然而，有些间接影响是不能忽略的。前面提到了使用Google搜索问题的解决方案，然而Google自身并不懂得解决问题，答案其实来自于其他已经把问题解决了的程序员，因此这些源代码如果确实帮助了其他类型的程序员解决了问题，那么也就间接帮助了RAD程序员。
那么，还有哪些类型的程序员呢？例如，做稍微底层一些工作的，编写Control、Extender、HttpHandler、HttpModule等可复用组件以便为自己或别人提供方便的。编写可复用组件最糟糕的地方就在于它是可复用的??你永远不知道别人会将它以什么样的方式用在什么样的环境，因此按照一定的模式开发这些组件以便保证兼容性就很有必要，而模式本身最好就参考自.NET Framework内置的同类组件，除非你想更大范围地研究.NET Framework并重新发明轮子。因此研究与模仿内置组件的行为是组件开发者的必修课，而从ScottGu文章（Releasing the Source Code for the .NET Framework Libraries）中的截图看来，内置组件丰富的注释将有助于程序员更轻松地理解其原本的设计方式，从而更轻松地在自己的组件中模仿内置组件的行为。事实上，有很多内置组件是设计为对另外一些内置组件特别照顾的，这类型的耦合在Reflector中阅读代码时是最难以理解的，如果阅读有注释的代码相信会轻松不少。
最后，开放源代码可能将会导致对.NET Framework进行纯粹思想或理论作研究的人数增加。事实上，无论.NET Framework多么倾向于实用型，如果Microsoft需要获取来自社区的创新思想，还是必须吸引一群思想家的，否则大多数的社区创新都只是应用与应用方法，Microsoft还是独揽.NET Framework前进方向的控制权。这种中央集权有它高效的地方，特别是发展初期，Microsoft能够根据自己的实力战略性地安排新特性的研发顺序。
然而Microsoft也曾经因此吃亏，例如ASP.NET 2.0没能引入AJAX支持，直到最后才急忙补上一个Callback特性，并承诺日后开发完整的AJAX库。因此，倾听来自社区的观点很重要，而要求社区有观点就必须先提供素材给他们讨论，开放源代码将能够激发社区对.NET Framework的研究热情并且提供更多能够作为反馈信息的新观点。
因此，就.NET Framework开放源代码这样一件事情而言，对于不同的开发者其影响的大小是不同的。同时我们也能预期Microsoft本身肯定也是最大的受惠者之一，否则以其智慧绝对不会做这样一个决策。
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
最新资讯
热门推荐