近期和微軟的幾位朋友交流，獲知一些有趣的信息，流水賬記錄如下（為了書寫方便，微軟兄弟以字母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：……