在架构设计过程中，肯定绕不开技术选型这个话题，大到架构、框架、语言选择，小到用什么组件、设计模式。
我们知道，架构设计的主要目标，是要能低成本地满足需求和需求变化，低成本地保障软件运行。然而对技术的个人偏好，很可能让你在技术选型时，忽略架构设计的目标，导致满足需求的成本变高，或者运行成本居高不下。
那在软件工程中，怎么样才能避免这种选型的倾向性，科学客观地做好技术选型。
技术选型就是项目决策
技术选型，就是在两个或者多个技术方案中选择合适当时项目情况的方案。技术选型看起来是个技术的选择，但其实是个核项目情况密切相关的项目决策。
在项目中，除了技术上的选项，类似的选择也有很多。比如产品设计中，某个功能该不该加？该选择哪种动画效果？比如制定测试方案的时候，选择哪一种压力测试工具？选择哪个测试框架？这些选择，本质上就是一种项目决策。
要做好技术选型，就是要做好项目决策。那么怎样从左项目决策的角度来选择何时的技术选型呢？
受制于时间、范围、成本的约束
技术决策作为一种项目决策，也要遵循项目金三角（时间、范围、成本），在决策时不能超出这三者的边界。
比如说项目时间紧时，决策上就要偏向于能提升开发速度的技术；在成本吃紧的情况下，要多用成熟的免费的框架、工具；避免用贵的商业软件或者自己造轮子提升成本；在范围大、需求多的情况下，架构就要考虑如何能用简单的方法快速完成需求。
还要注意一个问题就是随着项目的推进，制约项目的三个因素一直在动态变化（比如人员流动），需要及时根据情况调整技术决策。
要分析可行性和风险
如果在项目决策时，不考虑可行性，不预估风险，就极有可能导致决策失败。
要考虑利益相关人
在做项目的决策时，如果决策时没有人代表利益相关的人，就可能会做出不考虑他们利益的决策。
选择适合的技术选型时，也要考虑到这一点。比如说光顾着选用新酷的技术，而没有考虑客户的利益，导致成本增加，进度延迟；比如在选择 UI 组件时，只想着哪个调用方便，而不考虑产品经理的利益，导致产品体验不好。
项目决策中常见的坑
无论是技术选型也好，还是其他项目决策，经常会遇到一些坑，一不小心就会踩上去。
把听到的观点当事实
现在网上充斥着各种观点：一个 React 的粉丝会给你描述 React 的各种优点，而不会告诉你学习曲线有多陡峭；一个不喜欢微软技术的程序员会把.Net 贬低的一文不值；一篇鼓吹Mongodb 多好的文章可能是收了钱的软文。
每个人都有自己的观点没有问题，但是不能把观点当成事实，尤其是在做决策之前，至少需要验证一下。
先入为主，有了结论再找证据
在做技术选型或者项目决策时，还有一个问题就是可能心中已经有了答案，后面所谓的决策，不过是寻找有利于自己答案的证据。比如说我特别喜欢 React，在做技术选型时，就会拼命寻找对 React 有利的数据作为证据，这其实可能会导致结论并不客观。
所以选择技术选型的时候，要像做项目决策一样思考分析。要想决策能正确，就要注意项目中范围、时间和成本的约束，要分析可行性和风险，要考虑利益相关人，最后还得要避开常见的一些坑。
如何做好技术选型？
对于技术选型问题，我们一样也可以考虑借鉴工程方法设计一套流程，基于流程去做技术选型或项目决策，来保证整个过程能科学可行，充分考虑项目决策的特点，避开常见的坑。
对于技术选型包括项目决策类的问题，我们可以分成：问题定义、调研、验证、决策这几个阶段。
问题定义
在问题定义阶段，需要搞清楚两个问题：为什么需要技术选型？技术选型的目标是什么？
很多时候为了解决问题引入一个新技术，然而真的需要吗？也许我们可以基于现有技术方案进行优化，根本就不需要引入一个新的技术或者新的框架
还有一个就是技术选型的目标需要明确，你的技术选型目标是为了使用新酷技术呢？还是为了提升开发效率？还是为了降低开发成本？
只有明确了技术选型的目标，才能有一个标准可以来评估应该选择哪一种方案
调研
在明确技术选型的目标后，就可以去调研，看看哪些技术选型可以满足目标，包括开源的方案和商业的方案。
在调研时，可以参考前面“项目决策的特点”中的内容，从几个方面去分析：
- 满足技术选型目标吗？
- 满足范围、时间和成本的约束吗？
- 是不是可行？
- 有什么样的风险？风险是不是可控？
- 优缺点是什么？
在调研结束后，可以筛选掉明显不合适的，最终保留 2-3 种方案留待验证。必要的话，可以一起讨论，最终确认。
验证
一个技术是不是合适，如果不够了解，没有应用过的话，实际用一下是很有必要的。可以通过一个小型的快速原型项目，用候选的技术方案快速做出一个原型来，做的过程才能知道，你选择的技术选型是不是真的能满足技术选型的目标。
决策
在调研和验证完成后，就可以召集所有利益相关人一起，就选择的方案有一个调研结果评审的会议，让大家提出自己的意见，做出最终的决策。
必须要承认，对于技术选型来说，是有不确定性的。即使通过上面的流程，也一样可能会做出错误的决策。但有一个科学的流程，至少可以保证提升做出正确决策的概率。
如果遇到很纠结的情况，就需要负责决策的人来拍板了，这时候其实并不一定有对错，重点的就是做出一个选择，然后按照选择去执行。有时候迟迟不选择、不拍板才是最坏的结果。
在项目结束后，也要对之前技术选型和项目决策做总结，不断的完善技术选型和项目决策的机制，帮助未来更好的进行决策。
总结
技术选型，本质上是项目决策的一种，也符合项目决策的一些特点。也就是说，技术选型的选择要受制于范围、时间和成本的约束，要分析可行性和风险，要考虑利益相关人。还有一些坑要小心避开，比如要避免把听到的观点当事实，要验证；要避免先入为主，不要有了结论再找证据。
要做好技术选项，要有一个科学的流程，首先要明确技术选型的目标，避免没必要的引入新技术；然后要充分调研；还要对备选的方案进行验证；最终和利益相关人一起决策。
技术选型，也不要太过于纠结，要勇于决策，选定了就坚定的去执行。
其他
- 很多技术选型就是技术负责人擅长什么、喜欢什么而决定的。但很多时候这也是有原因的，先抛开个人喜好的因素不说，初期的时候团队人少，没有什么好选择的，只能是负责人会什么就是什么。后面团队虽然壮大了，但是更换语言或者技术平台成本就高了。
- 在没有特殊要求的情况下，项目中更加倾向选择更为熟悉的技术，因为我们需要对项目的质量与交付时间负责，可以做到可控的。而新技术有着新的设计思想与强大的功能，同时也伴随着无法预知的”坑”。在后续产品迭代的时间里，有针对性的升级或者选择更换同类技术里更优的。
- 工作之外会做一些业余项目，然后在这些项目中体验新的技术，体会其中优缺点，然后再逐步应用到工作的项目中
走快的唯一方法是先走好。欲速则不达