技术选型的艺术

作者 | 章烨明

杏仁医生CTO。中老年程序员，关注各种技术和团队管理。

什么是技术选型

技术选型对于广大程序员，特别是互联网公司的技术负责人或者架构师来说，一定不陌生。小到日常开发中的一个工具库的选择，大到整个系统语言、架构层面的选择，都是技术选型的范围。今天我们就简单聊聊技术选型。

一般而已，我们会碰到的技术选型，可以分为以下几类：

• 基础设施选型：云平台或IDC、编程语言、数据库等。

• 框架和库的选型：前后端的开发框架、核心类库等。

• 中间件选型：负载平衡、消息中间件、缓存中间件等。

• 第三方服务选择：第三方的推送、短信等。

实际上，我们常常面临的不是单个技术的选型，而是对于一个项目所涉及的一整套的技术、方案、规范或者产品的选型。这就需要我们更仔细的去权衡各种技术、各种组合的利弊，作出取舍。

技术选型，其实本质上就是一种架构决策。《系统架构》这本书里将架构决策总结成了六种模式，包括选项、筛选、指派、分区、排列和连接。而技术选型明显属于其中的选项（Decision-Option）模式，也即每个决策都是一套离散选项，从中选择一个合适的。

影响技术选型的因素

项目因素

首先考虑的是项目。

我们要明确项目本身的性质，包括项目的规模、重要程度、时间要求等等。如果是一个小规模的实验性项目，那么尝试一些新技术也未尝不可。如果时间要求非常紧，那可以考虑基于开源或商用的程序修改。淘宝当年上线时候，就是购买了一个商用程序后修改的。另外，项目的成本和预算也是必须要考虑的。如果预算足够，我们也可以考虑购买商用程序或者第三方服务。

项目的需求也会影响甚至限制技术的选型。特别要注意的是那些非功能性的需求，例如对并发性、实时性、可用性、数据一致性、安全性等方面的需求，往往对技术方案和选型有很大影响。例如支付相关的应用，对数据的一致性有非常高的要求，那核心的支付数据的存储，就会倾向选择 Oracle、PostgreSQL 这种强一致性的数据库，而不会去选 MongoDB（虽然据说马上也要支持事务了）。

团队因素

其次要考虑的是团队，也就是说人的因素。

技术选型一定要考虑当前团队人员的技术组成。对于一些比较基础的技术的选型，比如语言和框架、数据库等等，往往最合适的选择就是团队最熟悉的技术。如果打算选择不同的技术的话，那就要考虑下团队是否有人能够 Hold 住了。另一个必须要考虑的是招聘，如果使用的是比较小众的技术，那么当需要扩充团队的时候，招聘人员会比较困难。我们杏仁在这方面就取了一个巧，最开始我们用的是基于 JVM 的 Scala 语言，但是我们招聘的时候，都是打的 Java 工程师的幌子。

团队的发展时期对于技术选型也会有一定影响。对于早期团队，大多数员工都是喜欢创新、愿意承担风险，那么可以选择一些相对较新、有挑战的技术；团队发展到一定阶段，那就要开始考虑团队效率、开发规范等因素，此时往往会选择一些比较大众的、经过验证的技术。

我加入现在的公司时，我们正好开始转型。原有的产品是基于 Web 的网站，我们打算开发一个移动 APP。我们原先后端应用使用的是 Scala 语言和 Play 框架，当时面临的一个问题是，新的产品后端应该选择什么技术？虽然也考虑过 Java，但因为时间很紧，我们还是选择了团队最熟悉的 Scala。但后面我们开始服务化的时候，就选择了 Java。

还有一点就是，虽然技术选型需要考虑团队人员的喜好，但千万不要因为某几个人的个人喜好，来决定技术的选型。还是通过细致的分析和实验来进行选型。而决策者也需要看的更长远一些，推动团队技术向前发展。

技术因素

技术选型当然也必须考虑技术因素，例如技术特性（易用性、可维护性、可扩展性、性能等）、技术成熟度、社区活跃度、架构匹配和演化等等。

技术特性往往是大家都会去关注的，相信不必多说。但是注意不要只是浏览网上看到的各种分析，对于重要的特性，还是需要去亲自实验一下或者做一些测试，有第一手的感觉。另外，这些特性往往不可兼得，所以我们需要对照项目因素和团队