如何进行技术选型

技术选型的一个基本原则是：求稳，适当求新。

其实，很难说什么技术是“稳”的，那都是相对的。衡量一项技术的“稳”可以从以下几个指标判断。

1、社区活跃度高

现在IT技术的社区无非是三大阵地：官网，GitHub，以及前两者衍生的产品/服务。

在进行技术选型的时候，当然是挑活跃度高的技术。

活跃度高，自然知名度就高了，也能很快为大家所熟知和学习。所以，活跃度高，也可以认为其推广度也是不错的。

比如官网建设的完整程度，以及更新的频次。

而GitHub上面的Star那是更为直接的指标了，为了求稳，还得留个心眼：看看issues。因为可以从用户提出的issues里面能看出一项的缺陷多不多，是不是我们能够接受的程度。

当然，还有的技术是再造生态系统了，已经脱离了技术的纯粹性意义了，比如Python，Docker，Elastic。顺便说一下，Elastic已经提交IPO了！

不过，还有一种技术也会有极高的活跃度：有极大争议的技术。

这种情况只能持有更为谨慎的态度了，除非到了非用不可的地步了。

2、技术有前瞻性

这个指标不太好量化，所以不是很好把握，更多的是靠技术管理者的经验了。技术前瞻性指标是可以作为社区活跃度指标的延续，换言之，如果一项技术具有较高的前瞻性，那么其社区活跃度是会持续走高的，可能在一个爆发节点会达到巅峰，就像在国内的Python之于AI。

但是，我始终坚信“存在即合理”，我们很难说PASCAL是缺乏前瞻性而不够普及的，VB地位持续下滑是缺乏前瞻性的表现？其实每项技术都是辉煌过，只不过随着现代社会技术生产力的提高，出现了诸多更好的选择罢了。意即过了巅峰之后，迎来的必然是低谷。

其实，我们可以简单的认为，应用场景的多样化，就是一项技术有高前瞻性的表现。

其次，不要简单的认为当下的热门技术就是有前瞻性的，尤其是近来涌现的各式新奇的技术。

Java能存在20年，还是有其道理的，至少前瞻性不逊色于其他技术。

3、团队成员的拥护

这是关键点了，如果得不到团队的认可，再怎么牛X的技术，也无法落地执行，毕竟不是技术管理者一个人在干活，得到大家的支持才最重要。

不过，这里还是需要有一个制衡的：

不要因为团队使用的技术老旧，就不敢启用新技术；也不能急于启用新技术，来一次大刀阔斧的技术改革，结果就是“步子迈大了，扯蛋了”。

所以，我认为技术管理者身上必须有一个特质：技术布道。

很好理解，如果在一个因循守旧的管理者之下工作，很难有大的提高，甚至没有任何进步。

在日新月异的IT技术圈子里混的人，不可能没有这一点基本的上进心。

充分激发团队的技术热情，感染团队里的每个成员，是技术管理者必备的人格魅力。

不过，本着实事求是的原则，一项技术适不适合团队，只有用了才知道。但是技术管理者大可不必亲力亲为，尤其是CTO，总监级别的管理者，只需要指定技术目标，保持一定的技术热情即可，最后再积极配合进行技术布道。

4、从实际业务出发

技术圈里流行一句话：不以业务为基础的架构都是耍流氓。

这句话同样适用于技术选型，必须从实际业务出发。

当然，因为某些技术的应用场景足够丰富，所以，一般公司的技术选型的结果基本都是大同小异，也都能很好的满足业务需求。

因为业务随时都有可能产生变化的，这条准则并不是提供业务改变，技术也跟着变，而是在满足现有业务的基础上要有所“保留”。

举个例子：

一个网站目前的QPS是1000，这对一个中小型网站来说算是一个不错的成绩了。当时处于业务发展的考虑，在可预见的未来，QPS可能会到达10万，那么就按照这个标准进行技术选型，架构搭建。

如果这个时候用千万级别的QPS来要求自己，那是不是在为难自己呢？这是在挑战“双十一”，这个想法很危险。

纵使将来真的达到了这个量级，那么我相信整个技术也不是一蹴而就的，在这个过程中，不知道进行了多少次重构了。

5、给自己一些挑战

这是“求新”方面的考虑，大有一种稳中求进的意味，我认为技术管理者应当要具备这样的魄力。

举个例子：

当Dubbo几乎占据了大大小小的各家互联网公司的技术栈的时候，突然宣布停更了，想来真是一件不负责任的做法。

就在停更期间，微服务大行其道了，正好我司要启动一个新的产品研发项目，这个时候敢用Dubbo吗？老实说，真不敢，虽然之前也没认认真真用过它。

这个时候只能用Spring Cloud了，事实证明，Spring全家桶还更好用，各种组件的对接也比较友好，这就要归功于Spring的技术生态做得比较出色。

当然，接触一项新技术必定会踩坑无数，正所谓“逢山开路，遇水搭桥”，当前面四个条件都满足的情况下，就不要怕困难了，路子走对了，只不过走得有些坎坷而已。