转载

关于技术选型方法论的探索

软件 产品 那么

业务的 要求 那么

领导给的 预算 那么

技术选型 该如何做 ???

关于技术选型方法论的探索

写在前面

小到日常开发中的一个工具库的选择,大到整个系统语言、架构的选择,都是技术选型的范围。技术选型是设计阶段的重点工作之一,奠定了之后开发的基础和方向,如果选择的技术不适合业务场景,那么,开发过程中将出现各种水土不服,导致整个项目推进困难,甚至项目失败的严重后果。

本质上,技术选型是一种架构决策。《系统架构》这本书里将架构决策总结成了六种模式,包括选项、筛选、指派、分区、排列和连接。而技术选型明显属于其中的选项(Decision-Option)模式,即每个决策都是一套离散选项,从中选择一个最合适的。实际上,我们常常面临的不是单个技术的选型,而是一个项目所涉及的一整套的技术、方案、规范或者产品的选型。这就需要我们更仔细的去权衡各种技术、各种组合的利弊,作出取舍,因此更为复杂。

当前大部分技术选型的现状是,技术人员结合当下具体的需求,依据自己的经验和网上获取的繁杂琐碎的信息来确定一个系统应该采取什么技术,而没有一套通用的、规范的、有效的有关于技术选型的方法。我们尝试建立一套方法论,以更结构化和可量化的方式来指导技术选型。本文是这套方法论的概述。

关于技术选型方法论的探索

影响技术选型的因素主要有四个,分别是项目因素、团队因素、版权因素和技术因素。

关于技术选型方法论的探索

(图1: 技术选型的影响因素

> > > 1. 项目因素 < < <

关于技术选型方法论的探索

项目因素包括项目的规模、重要程度、时间要求等。 如果是一个小规模的实验性项目,那么尝试一些新技术也未尝不可。如果时间要求非常紧,那可以考虑基于开源或商用的软件修改。另外,项目的成本和预算也是必须要考虑的,如果预算足够,也可以考虑购买商用软件和支持服务。

项目的需求也会影响甚至限制技术的选型。 特别要注意的是非功能性的需求,例如高并发、低延迟、高可用、数据一致性、安全性等方面的需求,往往对技术方案和选型有很大影响。

> > > 2. 团队因素 < < <

关于技术选型方法论的探索

技术选型一定要考虑当前团队成员的技术栈。 对于一些比较基础的技术的选型,比如语言和框架、数据库等等,最合适的选择就是团队最熟悉的技术。一个成熟的团队往往有自己熟悉的技术栈,在熟悉的技术领域内进行技术选型一方面有利于开发的进行,另一方面对可能出现的各种问题也有预估和解决的能力,不容易出现重大研发事故。

技术选型应该征询团队成员的意见 ,并通过严谨的分析和实验来进行选型,不要由决策者独断决定。

> > > 3. 版权因素 < < <

版权因素可能会是技术选型中最容易被忽视但极其重要的一项因素。

根据项目的背景,选择协议适合的技术。 比如我们的项目要商业化,这时候很多开源协议均可以满足,比如GPL协议、BSD协议、LGPL等协议;但如果担心竞争对手根据自己的程序开发类似产品,或者是对代码有保密要求的企业,就不能使用GPL协议了,因为这个协议要求用户强制开源扩展程序, 这时可以选择BSD协议、MIT协议以及LGPL协议等,这类协议不会要求使用者强制开源。使用LGPL协议需要注意的是该协议下的程序只有被调用的时候才不要求强制开源,也就是说当你的程序要将该协议下的程序包含到自己的程序中,就要求同GPL协议一样,强制开源你的代码。

> > > 4. 技术因素 < < <

技术因素是选型中最重要的因素,技术因素又分为 标准功能、非功能性特征、技术标准、技术支持 四个方面:

1) 标准功能

目标选型技术或者候选技术有哪些功能,或者系统有哪些特定行为,我们称之为“标准功能”。以API网关为例,路由、安全认证、监控等属于标准功能。

2) 非功能性特性

目标选型技术应该在诸如“性能、可用性、可扩展性等”方面具备哪些特性,而候选技术又具备哪些特性,我们称之为“非功能性特性”。

“非功能性特性”是技术选型的核心环节之一,如果要给它定一个标准,引用一下《中间件——达成灵便的电子商务的技术基础》中的一段信息:

特性

描述

可伸缩性

产品在性能上必须能容易且有效地伸缩以满足业务需求增长的需求。

灵活性

产品必须易于适应新的需求。

可操作性

产品必须被设计成易于与共享的数据和广泛可得的系统通讯。

可扩展性

产品功能必须在供应商很少介入的情况下能够定制和快速地增强。

可使用性

只需很少的培训就能使让顾客使用产品和他的任何特性,产品应该被设计成其目标使用者的技术水平很匹配。

高效率

产品应能在各种性能水平上工作,能够应付应用对效率的要求。

可靠性

产品必须有被证实可在预定环境中工作的功能与特性。

可管理性

产品必须能被配置、部署、监控和优化以确保其在预定的环境中工作良好

安全

产品必须保护信息和事务的完整性

高可用

通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。

对于技术选型而言,标准功能和非功能特性的界线没必要刻意划分,也有人将“非功能特性”比喻成“标准功能”的一种技术属性较高的补充项,听上去反而更贴切。但如何定义“标准功能”和“非功能特性”其实并不重要,关键是架构师在选型时要找准这些区别,从而选择出合适的技术。

3) 技术标准

目标选型技术或候选技术在应用场景中使用什么通讯协议?API标准是什么?实现语言和兼容语言支持哪几种?而这些技术又可不可以扩展,也是需要考量的内容。

4) 技术支持

技术因素不能只关注技术本身,还要考虑厂商、社区的支持力度、服务质量及成本、社区活跃度等因素。毕竟没有人愿意使用没有人维护,出了问题也无处可以解决的技术。

上文描述的影响因素在我们选型过程中,可分为必要因素和可量化因素。 必要因素用来直接判断某一项技术是否符合选型要求 ,比如团队成员的技术栈和版权因素,从而初步过滤不符合选型需求的技术; 而可量化因素则用来对候选技术进行打分评定 ,比如非功能性特性和技术标准,从而得到最佳选型。

在清楚了技术选型的考量因素之后就需要进行技术选型了,那么技术选型应该按照什么步骤进行呢?

关于技术选型方法论的探索

> > > 1. 可量化因素及其所占权重 < < <

由三人及以上的奇数个专家组成专家团队,分析技术使用的应用场景,明确选型目标。根据分析结果选出本次选型过程用到的可量化因素,并给这些可量化因素赋予权重,权重之和为100%。

以网关选型为例(图2), 蓝色的可量化因素是直接得到半数以上专家选择的因素,少于半数的可量化因素由所有专家充分沟通后再进行一轮投票, 这一轮得到半数以上票数的因素被标为绿色,否则被标为橘色。橘色的不会被作为本次选型的可量化因素,而蓝色和绿色的可量化因素将作为候选技术的打分项。

关于技术选型方法论的探索 (图2 选择可量化因素)

然后由每位专家设定可量化因素的权重,通过对权限进行均值计算得到各因素的最终权重(图3)。

关于技术选型方法论的探索 (图3 确定权重)

> > > 2. 大范围的搜寻候选技术 < < <

对于候选的技术, 建议范围要大一点,既可以包含得到广泛认可的成熟技术,也可以包括由成熟的技术社区刚刚孵化的新技术,既可以是开源的,也可以是商用的。

> > > 3. 利用必要因素筛选 < < <

对于大量的候选技术,我们要筛选掉其中不满足我们要求的技术,此时要利用必要性因素,来筛去一些明显不适合的产品或技术,最终留下几个候选方案。

关于技术选型方法论的探索

(图4 技术粗选)

> > > 4. 可量化因素打分评定 < < <

经过技术粗选的候选技术已经基本具备我们需要的功能或者符合我们的需求,但究竟哪种技术更加合适,就要由专家给候选技术进行打分来判断。评分公式为: 评分= 参数一评分*权重+参数二评分*权重+...+参数N评分*权重。 图5就是以网关选型为例进行的细致分析过程,由专家对各个网关的可量化因素打分并求出总分。

关于技术选型方法论的探索

(图5 细致分析)

最后根据评分高低选择最佳的候选技术即可。

关于技术选型方法论的探索

当然,我们也相信,对于技术来说,本身并没有对与错,只有是否适合,本次分享的方法论还是一个框架层面的,实际使用还需要“具体问题具体分析”,也欢迎大家提出意见建议共同讨论完善~

作者简介: 赵文鹤, 北京交通大学软件工程研究生,基础技术板块小鲜肉实习生。

关于技术选型方法论的探索

原文  https://mp.weixin.qq.com/s/Z7jK8XnKnoY-FiP4inGjsA
正文到此结束
Loading...