互联网技术爆炸的时代

现在同一个问题，解决的方式有很多种。同样是应用层开发，有数不尽的语言和框架可以选择。这虽然有好处，但也带来了诸多麻烦。比如，团队成员对技术选型意见的不一致；解决同一问题工具选择周期的增长；很难客观完整的对比可选方案；社区对哪个语言、哪个框架更好争论的永不休止。究竟如何做技术选型是困扰很多人的问题。之前我也有很多疑惑和思考，最近整理如下。

效率：开发效率优先还是运行效率优先

选择开发效率还是执行效率是个老生常谈的问题。对于不同阶段的公司和项目会有不同的选择。新的商业项目更趋向于选择开发效率优先。因为商业模式的尽早验证比其他因素更重要。
但是假如是成熟的商业模式，预见规模会很快扩大到很大，则可以选择运行效率优先。另规模化项目比如云服务平台、大公司的基础组件更趋向于选择运行效率优先。

成熟和常见技术优先

成熟和常见技术指那些被大部分人知道并学习很多年的技术，比如网页编程语言 PHP 、关系型数据库 MySQL 、Web 服务语言 Java 。好处在于招聘成本、沟通学习成本会很低。大部分问题已经被很多人解决过很多次。很容易找到相关的技术文档。这样带来的是开发效率的提升。

小众技术不等于新技术

很多人会混淆小众技术和新技术。虽然有时候他们之间交叉很多。

小众技术指那些? 小众技术一般针对特定领域问题设计。比如 Erlang 针对软实时控制系统设计；Rails 针对快速 MVC Restful 互联网应用开发而设计；Grunt、Gulp 针对前端自动化设计。

成熟的小众技术

有一些小众技术及时诞生了很多年，由于适用性比较窄，也不广为人知。但是这不意味着这种技术不成熟。Erlang、Lisp、Lua、Node.js 都是成熟的小众技术。成熟的小众技术解决特定领域问题非常高效。

适度尝试新技术

一般情况，新技术都是在借鉴了所有已有技术基础上的重新设计和创新。一部分新技术会成为未来的主流技术，虽然这个过程比较缓慢，需要很多推广才能吸引很多开发者使用。并且技术本身由于越来越多的人使用，不断自我迭代，修正优化。所以，需要根据自我情况思考是不是有更好的新技术解决现有问题，提升开发和运行效率。

避免重造轮子

对于工程师或者手工艺人，创造东西给他们带来成就感、或者会对自己的业绩、绩效有影响。所以，很多新出技术并没有明显的创新和优势。只是把轮子重新制造一遍。这常发生在资源充足、人员冗余的大公司。试问哪个大互联网公司没有几套 RPC 框架？

团队大小对技术选型的影响

1 人团队、10 人以下团队、10 人以上团队对于技术选型有很大区别。1 人团队几乎不需要考虑技术选型的问题，选择喜欢的即可。10 人以下团队则可以更多尝试新技术和小众技术，因为招聘培训成本还不会很高。10 人以上团队则需要更多考虑团队扩展成本，而不单单是开发效率和执行效率问题、尽量少引入不成熟的新技术。在大公司的技术选型和创新过程类似，可以是自上而下，也可以是自下而上。

团队成员经验对技术选型的影响

团队技术选型自然会选择团队所有成员熟悉的技术，否则会出现开发节奏问题。比如所有人熟悉 Java，小部分人熟悉 Scala 的情况下，需要忍痛割爱选择即使从其他层面考虑更适合的 Scala 语言。一般情况下，某项技术至少需要 1 – 2 位高级工程师解答遇到的所有相关问题，这位工程师需要从源码级别理解这项技术。优先选择成熟技术。

技术帮派之正视技术的优点和缺点

技术爆炸和开发者社区的增长必然会导致一个问题，技术帮派。需要注意的是需要正视某项技术的优缺点和使用场景。尽量避免“技术帮派”对正确优化技术选型的影响。

没有银弹

没有任何一项技术可以适用在所有场景，所以不同场景下的技术没有可比性。没有银弹和最好的语言和框架。