互联网技术爆炸的时代

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

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

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

成熟和常见技术优先

成熟和常见技术指那些被大部分人知道并学习很多年的技术,比如网页编程语言 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 位高级工程师解答遇到的所有相关问题,这位工程师需要从源码级别理解这项技术。优先选择成熟技术。

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

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

没有银弹

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