浅聊技术栈选型

浅聊技术栈选型

技术栈选型是一个复杂的过程，也是一个可变的过程。举一个例子，在微服务(Microservice)兴起的时候，Spring Boot框架是很多团队的选择，自然的Java就是技术栈选型。在无服务器(Serverless)开发时代，由于运行效率等的原因，Java可能变成了不是最好的选择，团队可能会考虑运行效率更高的Python或Javascript。在长时间维度来看，技术栈选型也是一个不断迭代的过程。

当要做技术栈选型的时候，是一个内外部条件结合的评议过程，以此找到当下的最优解。

在不同的技术栈的比较中，特定的应用场景一般会浮现出相对优秀的候选技术。一般在客观的研判后都会得到这样的结果。之后就要考虑内部因素和外部因素。

内部因素 - 要考虑的内部因素有可用资源和知识储备。先说可用资源，例如：服务器资源或可用预算。如果选用的技术栈需要支付使用费用，可能就要考量免费的技术栈能否满足需求，免费的技术栈可持续性能否达到要求。再就是知识储备，团队成员的技术知识结构会影响到远期目标的可达成与否。如上面的微服务和无服务器的选择，在技术栈对满足需求影响不大的情况下，无服务器对Java工程师就可能不是好的选择。但如果技术栈有很强的优势，那就涉及到团队转型与建设的话题。不在本文的讨论范围。

外部因素 - 技术支持和人力资源市场。先说技术支持，举个无服务器部署的例子，AWS无服务器服务Lambda部署有多种选择(AWS SAM, Terraform, Serverless)。在比较技术支持可获取难度(技术社区，所在地区专业技术支持)之后，Terraform 和 Serverless胜出。再就是人力资源市场，比较典型的例子是，某一种技术栈在人力资源的获取难度大或成本很高。极端的例子如：COBAL软件工程师。

这些因素会在每一次技术栈选型中不断迭代。幸运的是随着新的技术设计框架，如微服务(Microservice)和无服务器(Serverless)的出现，技术栈选型迭代的成本越来越小。一个团队用不同开发语言部署不同微服务情况也常常出现，再也不是一个团队一个Java的App管十年。

Happy Coding~