为什么写这篇文章是因为朋友公司的经历，朋友在一家初创公司做开发，初创必然是人少，事多，什么都做。有一天微信问我有个问题看看我有没有遇到过，我看了问题之后去原作者的github看了一下，我了个大去，最后一次commit是2017年底，而且issue上也有很多问题没有处理。这种技术怎么能用呢! 那么什么技术能作为技术选型？下面就来谈谈这个问题。
从实际出发首先我们必须考虑现实，必须考虑公司的现状，无论是业务现状还是技术现状。公司的业务场景是否有成熟的解决方案？成熟的解决方案用了什么技术？能否解决本公司的现在的业务需要还有未来的业务扩展需要？技术团队的技术改造能力如何？对候选技术是否有很强的掌控能力？不能出现上面出了问题自己控制不住的情况。我还遇到初创公司上来就要搞各种高并发分布式的，只能摇摇头。技术不是随大流，符合当前实际才是最好的。所以当评估技术方案的时候要首先考虑这几点，从业务出发，从开发团队出发。
一定要有科学的技术选型流程还是拿上面的例子来说吧，对不起兄弟了。老板扔过来github地址就二话不说拿来用。领导说用啥就用啥，以行政来推技术不可取。还有的看了几篇相关博客，觉得很好就拿来用，结果发现落地成本高，实施困难。只能推到重来浪费大量精力人力。或者凭感觉来选技术，微服务很火，好上上上。容器也很流行，好也上他喵的。python据说马上超过java了，好也给他用上。这种能行吗？肯定不行。没有做好技术分析，势必要栽跟头。应该如何做才是正确的呢？
平时要进行一些技术方案的研究和可行性分析，考察的维度可以粗一点，放入可观察的池子中去。对池子里的技术进行长期的技术追踪。比如orm框架 一般都是从 spring data jpa、hibernate，mybatis，甚至jooq。
对陌生技术一定要进行选型分析如果用了陌生技术、不知名技术一定要深入、不能靠几篇博客，几个demo就拿来用。花点实践搭个原型，然后让团队核心开发成员各自分析利弊，并总结出可行性报告，择优而用。
要有兜底方案任何技术都有不确定性，所以一定要有掌控能力。出问题能改。有兜底方案，可以再加一道保险。
定期的技术复盘经常性的技术复盘有利于团队对技术的把控，也有利于技术选型和对技术的掌控度。
结合上面几点整体的技术选型流程应该是这样的：“列出需求”->“细分需求”->“明确搜索方向”->“网络搜索”->“明确评判标准”->“分头执行”->汇总材料”->“初步选择”->“进一步调研”->“会议评审”->“最终决定”
什么样的技术可以用我认为有这些因素考虑
首先解决实际问题技术一定是为了解决自己的问题，这个是第一位的。
发展前景良好最好不使用已经不流行的技术或者淘汰的技术，现在很少使用dephi了吧，struts2 也只有老平台使用了。
社区活跃社区活跃的技术，出了问题解决方案就多，文档也完备。而且迭代也稳定。稳如spring，apache(ASF)等知名社区。
学习成本如果一个技术学习成本很高也要考虑，高学习成本意味着人才的可替代性比较低。
人才可替代性这个也是容易忽略的一方面，结合以上几方面考虑，一定要考虑该领域人才的数量。不然遇到人事变动，没有及时的补充人才。
这就是我程序开发技术选型的一些看法，分享给大家，希望对你有用，有问题可以留言讨论。别忘了关注一下哦。
