从个人观点出发，技术选型包括框架、工具、语言。
对于初创公司或者小公司来讲，上级领导的意愿更多的是能够快速盈利，此时应该选择成熟便捷的框架， 尽量减少学习成本，这就属于经验优先，因为只有做出成品并且盈利，公司才能够生存。
中型公司是由小公司慢慢发展的，此时技术有了一定的积累，并且也有能力自己去做一些定制化的开发，此时需要考虑的问题是自己开发还是使用现有产品
举个例子：目前公司内部需要搭建一套日志收集和监控系统，该怎么做？ 很多人最先想到的是 ELK ，但这样是不可以的，选型的话你要了解市场上都有哪些日志的框架，结合实际的项目，找到最方便的那一个，不能说 ELK 用的人多你就用，项目部署在阿里云，那使用阿里云的日志服务是不是更方便快捷？
大型公司就比较随意了，可能会花很长时间很多精力放在自研上
如果一个技术恰好能够解决当前遇到的问题或者在重构时能够解决性能的瓶颈，但是，它可能是用 GO 语言写的，而团队用的是 Java，此时需要考虑的是如果引进来了，那么能够多久能上手呢？之前看到某公司招聘的 JD ，如果你自认为可以在一周内精通领域，那么上述的要求可以不用遵循。所以在面试新人时就需要从多维度去考察，在此不细说；如果成员已经确定但是技术水平不高，那么你就需要如何去提升团队的技术水平。
记住，如果你在公司工作，那你就是给别人打工的，你的职责就是让企业赚钱，领导不会关心你用什么技术，但他能知道你用多久去把业务实现，此时你需要考虑什么？理想状态是时间短高收益，这需要借助二八原则，用百分之二十的成本带来百分之八十的收益。
举个例子：领导规定三天时间日志服务搭起来，并且上生产环境，如果你用 ELK 那你需要很多配置，如果你用云产品，直接集成就能用。有人可能会想，用云产品不是得花很多钱吗？我最初也是这样想，但后来我是这样想，首先钱不用你出，而且你自己搭的 ELK 后期维护消耗多少算过没有，和你云服务比一比看看哪个多。
风险其实一般很难发现的，比如安全问题，只有漏洞报出来你才会知道，还有就是有 BUG 但项目不维护了，这就是最后要讲的生态。
一个好的项目不是看多少人用，而是有一个成熟的社区，你提问题有人及时回，你提建议或者 BUG 开发人员会跟进，采纳后会加入下次发版，这比你遇到问题后去提 issue 人家不回你，问别人也不清楚，这样就是一次失败的选型。
技术选型离不开业务，脱离了业务你的技术再高也将无法体现。选型重要的还是选择问题，这能映射成生活，权衡一件事，要从多个角度去思考。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。