软件工程22-如何为项目做好技术选型？

在架构设计过程中，肯定绕不开技术选型这个话题，大到架构、框架、语言选择，小到用什么组件、设计模式。

这也是最容易引起争议的话题，无论是现实中还是网上，到处有各种语言、框架的争论：Java 好还是 C# 好？前端框架是 Vue 好还是 React 好？跨平台手机开发，该选 React Native 还是 Flutter……

虽然这种争论从来没什么结果，但当你做技术选型时，却很容易受到这些信息的干扰，尤其是你身边有几个某种语言或者框架的狂热粉丝的话，他们会不停地在你旁边吹风，说他喜欢的语言或框架的各种好处。

包括我们自己做技术选型时，也会有很多个人偏好在里面。比如我以前对微软技术栈特别熟悉，也特别喜欢，做技术方案就会偏向微软技术栈；我喜欢 React，做前端技术选型，也会偏向 React 的方案。

通过上一篇架构设计的学习，我们知道，架构设计的主要目标，是要能低成本地满足需求和需求变化，低成本地保障软件运行。然而对技术的个人偏好，很可能让你在技术选型时，忽略架构设计的目标，导致满足需求的成本变高，或者运行成本居高不下。

所以今天，我们一起来探讨一下，在软件工程中，怎么样才能避免这种选型的倾向性，科学客观地做好技术选型。

技术选型就是项目决策

技术选型，就是在两个或者多个技术方案中选择适合当时项目情况的方案。技术选型看起来是个技术的选择，但其实是一个和项目情况密切相关的项目决策。

在项目中，除了技术上的选型，类似的选择也有很多，比如说产品设计中：某个功能该不该加？该选哪种动画效果？比如制定测试方案的时候，选择哪一种压力测试工具？选择哪个测试框架？这些选择，本质上就是一种项目决策。

要做好技术选型，就是要做好项目决策。那么怎样从做项目决策的角度来选择合适的技术选型呢？

受制于时间、范围和成本的约束

我们在《08 | 怎样平衡软件质量与时间成本范围的关系？》中学习了项目金三角的理论，也就是项目受制于三个因素：时间、范围和成本。

技术决策作为一种项目决策，也要受制于时间、范围和成