微软玩内源吗？
近期和微软的几位朋友交流，获知一些有趣的信息，流水账记录如下（为了书写方便，微软兄弟以字母M代替）：
关于内源
我：微软玩内源吗？
M：什么是内源？
我：就是产品源代码在公司内部开放；并且开发团队模仿外部Github上开源项目的运作形式来进行产品开发，有开发者来编写代码，提交代码请求合并，有commitor来负责审核代码后决定是否接纳合并请求……（我解释了一下我们内源的运作模式）
M：1）微软内部的源代码有严格的权限管理，不会随便向不相关的员工开放；2）一个项目组的员工，可以方便的看到和他工作相关的代码，但是如果要看超出业务范围的代码，必须申请；3）微软内部没有内源这种叫法，但是，我们的代码在提交到开发分支以及合并到主干前，都是要经过评审和检查，达到标准才允许提交和合并。
我：我们认为内源可以让一个人的代码公开透明，接受大家的围观和评审，这样对员工写好代码有促进作用；
M：是这样的。但是你们没有内源之前，员工的代码在项目组内实际上也是公开透明的吧？难道就没有人检视和评审吗？他们的代码是不是想提交就可以提交成功呢？或者说，你们内源之后，员工提交的代码被检视的力度和范围是不是变大了呢？我认为，是否内源不是关键问题，内源只是一种代码协作模式的提法。即使不玩内源，只要写代码、检视代码、提交代码的活动做到位了，保证了代码提交和合并前的质量，那么就没有问题。
我：微软也会使用 pull request 这样的协作形式吗？
M：是的。我们的TFS就集成了 pull request 的操作；
关于配置管理
我：微软内部用的配置管理工具主要是什么？Git或者TFSVC？
M：Git。我们几乎全部都用Git。
我：微软的软件开发项目管理平台是什么？
M：我们就用我们自己开发的 Team Foundation Service Services。这个Services是部署在Azure的公有云上的，开发团队只要申请就可以马上获取到一套配置好的TFS服务。
我：不用像我们需要自己搭建服务器？
M：是的。TFS Services是Azure云上的一项SAAS服务，任何一个公司只要申请并且付费，就可以马上使用到 TFS ，我们是保证信息安全的。当然你们出于自己的信息安全考虑，那就只能自己在自己的服务器上安装TFS了。
我：微软将Git集成到了TFS这个商业软件之中，这样有没有可能违背了开源协议？
M：没有，微软是Git开源项目的重要成员之一。
微软怎么做代码检视
我：微软怎么做代码检视？
M：微软很重视代码检视。TFS 里面已经集成了一个代码检视的工作流，可以满足绝大多数场景的检视需求；但是实际上我们内部在使用一个叫做CodeFlow的东西来支持我们做代码检视，下一个 visual studio 版本，我们会将 CodeFlow 集成到 TFS中，发布给客户使用。
关于Visual Studio
我：我们公司员工在使用visual studio的时候，常常会试图继承Source Insight的习惯做法，建一个Project，然后将代码库中成千上万的的源代码加入到这个Project中，结果发现VS非常缓慢；
M：是的，我们注意到了你们的这种用法，这个场景让我们VS开发团队也是大开眼界。如果一个产品具有良好的代码架构，并且进行了组件划分，那么不可能存在一个Project里面包含几万个源代码的场景。你们需要将你们的代码库进行整理，划分成可以独立编译的组件，每一个组件一个Project，多个组件组成一个Solution。
我：Visual Studio 的安装包太大了，独立安装包有7G多，中间还要下载很多东西；
M：确实我们注意到了这个问题，现在我们正在对VS进行拆分，支持按需安装。
我：Visual Studio 本身是用 C#语言写的吗？
M：不是，是用C++写的；
我：微软自己的Visual Studio 上开发了一个支持Linux上C/C++开发的extension，这个扩展做的很不错，可否将其开源给我们？
M：这个extension我们已经开源了，在 github上就可以找到源代码。
关于招人
我：听说微软更加喜欢招应届毕业生；
M：是的。微软喜欢应届毕业生，因为他们就像一张白纸，没有在别的地方染上的臭毛病和坏习惯，招进来之后微软有一套很好的培训制度，可以将毕业生快速培养成符合微软要求的具有良好职业素养的编码高手。当然，我们也不排斥社招。
关于其它
我：听说你们七月份微软中国的员工都会去美国；
M：是的，我们的财年在7月结束，这个时候很多中国的员工都会去美国，但不是全部员工，主要是去开会或者培训，然后一般会休假半个月左右，这假期是带薪的，如果不及时休掉就会作废，也不会换成钱发给你。所以大家一般都会趁着去美国的时候在美国休假。加上开会和培训等，整个时间可能会一个月。
我：你们这个福利很不错啊，你们现在还招人吗？
M：……
