软件开发尝试新技术好吗

一个程序员问我，公司领导希望我们创新，使用新技术，而同时又希望线上系统的稳定，这也太矛盾了呀，搞得他们不知道怎么办。这个看似矛盾的要求，其实是考验团队的平衡能力，新技术的尝试是需要，否则团队技术能力没有发展，但线上系统的稳定也是必须的，如果因为系统不稳定导致死在当前，创新还有啥意义呢？下面就具体讲讲，怎么样把这两者权衡好，做到鱼和熊掌兼得的效果。

第一，需要确定这个创新是真的，还是假的，判断的标准就是能否带来利益，如果能，预估一下能够带来多少，最终没有经济收益的创新都是伪创新，是需要放弃的。例如，很多JAVA框架有注解功能，很多人喜欢SpringMVC，也是因为强大的注解功能，不过在我看来，使用注解不是好事，反而破坏了OO编程的概念，降低了工作效率，具体论述，请您参看”软件框架设计实例_Struts”。还有微服务最近特别的火，让人感觉到微服务可以解决一切问题，但个人绝对微服务会大大的降低性能，而且也不能根本上解决软件复杂度的问题，具体为啥，请您参看”软件框架设计实例_微服务”。当然有些创新可能对他人有用，对你自己的场景无用，没有任何一个方案是银弹，这是软件行业的定律。再举个个栗子，使用OkHttp替换HttpClient是可以带来好处的，一来OkHttp代码简洁效率高很多，而且对HTTP2.0有支持，考虑系统未来发展，当然进行替换是非常有好处的。还有，使用Nignx替代老的Apache服务器，Nignx的因为使用了异步IO，服务器的并发能力有几十倍的提升，反应到经济效益上，就是我们可以使用更少的服务器，花更少的钱。

第二，效益的评估是建立在自身的技术水平基础上的，而不是从网上看文章或者跟流行得来的结论。前几年SAAS大热，很多资金和公司都杀人SAAS，有些传统软件公司也坐不住了，认为不能错过新的风口，而事实上今年开始大量SAAS企业裁员倒闭，国外的Saleforce成功，不代表可以复制到中国来，具体SAAS的深入分析，请您参看”SAAS为啥那么难做”和”餐饮SAAS发展”。有一次，一个前端程序员给我讲，网上看到一个缓存框架，非常好，觉得可以应用到我们的项目当中。我问他，你对缓存的实现原理和应用场景分析过了吗？他的回答，人家都是成熟的啦，拿来直接使用就行了。我反复跟他强调了去分析原理的重要性，他的回答还是一样，对于这些的创新建议，我只能是忽略了（其实我也知道那个框架不适合我们的场景，希望他能够自己分析发现）。

第三，做技术创新之前，一定要深刻理解自己系统当前的问题，这种理解不是简单的表面的知道，而且问题背后原因的深刻分析和总结。之前，有个故事，一个北大高材生进入了华为，看到了很多问题，写了一大篇的建议书给任正非，结果被任老板开除掉了。其实很多时候，高层不是不知道问题的存在，高层更希望知道可靠的解决办法。很多时候，我们可能因为解决了一个问题，带来了更多的问题，大型软件系统是非常复杂的，而且很多模块之间是相互牵制影响的，不考虑全局的局部创新可能是非常危险的。比如，前端贸然使用新的类库，可能导致向后台通信的错误和不稳定，导致线上客户的流失。创新的精神是可嘉的，但公司是不希望成为先烈的。如果自己的资历和经验不足，要做创新之前是应该提升自己的能力，提高自己说话的资本，让他人感觉到你是可信赖的人。对于经验丰富的人，对旧有系统进行重构和创新，也需要去一线调查研究，分析总结问题后，再提出可执行的落地的方案，把现有系统和重构系统的关系平衡好。

第四，创新要稳步前进，不能过于激进，需要人员的培育和验证环节。创新的风险，一个是对新东西的认识不足，就是需要填坑，二是人员的培养，因为一个创新往往不是一个人完成的，可能需要团队的协作。创新很多时候可能是一种工作方式的改变，比如，软件开发的敏捷创新不是通过几节课就能实现的，是需要团队自身能力的提升和协作的磨合的。解决这个两个问题的方式，就是做试验田，就和中国的改革开放从深圳试验田开始一样。通过试验田，可以规避线当前线上系统稳定性的问题，因为试验田的范围是可控的。如果没有好的试验田，甚至可以自己建立模拟试验田，其实很多场景都是可以模拟的，当然这需要测试团队的能力很强。就和现在飞机为啥可靠性那么高，因为飞机很多的地上实验系统可以模拟空中的复杂环境，就和军事上的计算机实战模拟一样，如果能够建立这种模拟环境，不但可以加速团队的成长速度，而且可以大大的降低成本，提前发现问题，不要等到上线后发现。

总之，创新是一个系统化科学的流程，而不是脑袋一热的事情，创新需要全面系统评估，是建立在自身的技术能力的基础上的，没有能力，创新是空话，而且容易成先烈。