但硕果仅存的2个.net程序员在随后不到半年时间都走了：一个.net程序员跟着微软出来的高管去创业，另一个.net程序员跳槽去百度做了前端工程师。这中间的道理也很简单：既然公司要去.net化，那.net工程师就会担心等到将来.net系统都换掉之后，自己在公司还有价值吗，不就彻底边缘化了吗?
当然我在制订架构迁移计划的时候，也考虑到了这一点：我给那个更资深的.net工程师制订的是整个公司总架构师的培养计划，那个精通JS的.net 工程师制订的是未来前端团队Leader的培养计划。不过有不确性的承诺总是不如现实的威胁更迫切，所以我也特别能够理解.net工程师的流失。
这个时候，我陷入了一个两难的处境：
1.如果未来还是沿着“去.net化”的计划往下走，就算重新招聘和搭建了.net研发团队，由于.net在公司是注定要被替换掉的，那么新的.net团队是不可能稳定的，很可能来一两个月，一看形势不对，立马走人了。而当时.net的核心系统占整个网站的比重很高，且极端复杂，一旦出问题，根本就束手无策，必须要有好手坐镇维护。当时我已经开始review核心系统的.net代码，准备亲自上阵了。
2.如果未来放弃“去.net化”的计划，也许短期可以解决一些头疼的系统维护的问题，但是对整个网站长期的发展会带来很多不利的方面：例如网站的安全性问题，网站的架构扩展问题，网站服务端软件全面正版化的成本问题等等。如果当时不下定决心去.net化，那么将来再想做这个事情，代价只会越来越高。
当时，我最初的想法是：招聘2名水平尚可，没有太大上进心，可以安于现状，踏踏实实工作的.net程序员来维护老的.net核心系统;同时招聘和搭建ruby研发团队，以我过去用ruby开发网站的惊人开发效率，争取时间，逐一重写老的.net核心系统。但是这样做，风险也很大：
• 我来CSDN的时间不是很长，当时CSDN线上产品又多又杂，足有上百个之多，很多系统我都不清楚干什么的;
• 公司领导也不太支持我这么快动手，甚至很担心我大刀阔斧的改造网站，会把当时已经很脆弱的网站彻底搞休克;
• 我来北京以后，只带过来1个Ruby程序员，而搭建Ruby团队，磨合团队，开发核心系统，都不是一朝一夕的事情，想快也很难快起来;
幸运的是，我招聘过程中，面试到了两个相当不错的.net工程师，有很强的上进心，编程功底和悟性都很好。虽然不符合我当时想找安于现状的工程师的标准，但我又不太想错过好的人才，所以我临时改变了自己的想法，将他们招过来，组建了新的.net团队。
