概述
技术选型的一个基本原则是:求稳,适当求新。
其实,很难说什么技术是“稳”的,那都是相对的。衡量一项技术的“稳”可以从以下几个指标判断。
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的技术生态做得比较出色。
当然,接触一项新技术必定会踩坑无数,正所谓“逢山开路,遇水搭桥”,当前面四个条件都满足的情况下,就不要怕困难了,路子走对了,只不过走得有些坎坷而已。
最后
以上就是欢呼抽屉为你收集整理的如何进行技术选型的全部内容,希望文章能够帮你解决如何进行技术选型所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复