[程序人生] 程序员如何选择技术类型？

在说技术选型时，先思考一个问题

当初自己的大学，专业是怎么选的？

有些人是一直朝着某个目标进发的。比如，TA想（或者TA的父母觉得ta想）学医，那目标就是医学的专业，大学就是各种医学院优先了。还有的，就是冲着某所大学，先不论专业，就觉着这大学好，专业嘛进去再说。

说一说我当初的决策逻辑：

定城市——定学校——定专业

最开始时，觉得自己应该优先挑专业强的，可是填报志愿时发现，志愿书上这么多专业，名词又这么相近，完全让人看花了眼。怎么解决这个问题？ 百度，这个方法可行，可是都是官方的。加各种群问校友，得到的答案 仁者见仁智者见智。即使挑中了专业，学校又那么多，咋挑？

后来一琢磨：从大方向出发，从上往下看。既然，这么多大学都有相近的专业，干脆先定下以后想要发展的城市，再看这个城市里有哪些学校是比较好的，然后从学校里挑感兴趣的专业。

再回到最初的话题，对于技术选型上该怎么抉择？

一个技术好不好，可以从三个方面观察。

研究过去

看这项技术有无底蕴，之前发展了多久，有无商用过。这个就很像指派任务，往往会选中一些有经验的人，有点像招聘一样，绝大部分公司还是偏爱有经验加成的。即使在项目中尝试使用新人，也会派一个老手带领或者协助。这项技术都没在任何商用经验，直接尝试可能是当敢死队，恐怕 不成功便成仁了。

看未来

一项技术，或者是某个框架，总是有些团队的，可以是这项技术的编写者，也可以是它的技术社区。技术框架的创建者，一直都有发些改进类的东西，版本也是在不断迭代，那这项技术有极大可能，未来发展不错。一个东西，创始者都不推崇它，那未来成长的空间可能就非常小了。这一点是不是跟A股里某些公司一样，上市后就遭初创者*的，往往死得很惨。

还有社区，这点也很重要。有了热闹的社区，编写团队才能收获意见，不断改进，提供新的基类或控件。就像产品里有句话：

不怕有人骂，就怕没人用。

 历史长河，不少故事都在告诉我们，闭门造车是行不通的。

关注当下

如果上述几项，都太过要求个人独具慧眼，那有个暴力的方法——索性就直接看同行们都在用啥，那么多人都在用，大概率不会差，大不了“大家一起死”。然后，自己小范围尝试下，看看官网的demo,展示的东西能否满足基本需求。查阅下API，看看解释的到不到位，查起来顺不顺手。这点很重要，因为，很多项目可能要团队做，或者后面有版本迭代。若是，后面带领新人入手，API查起来费劲，学习成本就会升高，产出效率也可能下降。

如果是抉择一项个人技术技能

这里的技术技能是指——职业技能。

很简单，去各大招聘网站搜罗吧，把现在想到的自己能干的职位，搜索下别的企业需要的技术类型，关注市场的认可度。然后选择自己最擅长的一个方向去钻研。

自己擅长+自己感兴趣的 = 最大优势

所谓扬长避短——在职场上，你要是想获得更多的成功，就应更大地发挥自己所长。虽然说，技术原理都是相通的。但是，每个人都有自己钟爱的一种。偏爱前端做交互的，可能对数据逻辑处理不感兴趣，喜欢研究数理的，可能对UI实现不感冒。容易让你产生痛苦的一种方式，就是让TA去做他不喜欢或不擅长的事。这种事做多了，好的结果就是短板提升，差的结果就是让人放弃。当然，自己要拎清痛苦的来源，是因为前期技术不熟练（比如语法糖的不熟练），还是这项技术的实际商用业务让自己头疼。不同的技术，在团队声明它的方向前，就有了商业公司来为其“定位”。很多时候，你选择了这项技术，就选择了它的商业定位使用。像丛林法则一样，要么适应，要么淘汰。

结语

有时候，做抉择往往让人烦恼，若是看不清楚，可以设想下，5年后的自己怎么看待当下的抉择。

人生的现状，不是经历与命运的总和，而是你在过去的时间里，做出选择的总和。