前端工程师必备技能之技术选型

585

近期,因业务需求,需要选用一个 React 技术栈的 Table 插件(类库),但发现可选方案太多,于是本文就诞生了。将我的技术选型过程与大家分享,希望有助于大家今后的技术选型。

  • 背景
  • 原则
  • 调研
  • 方案确定
  • 总结

背景

技术选型对于前端工程师来说大家都非常熟悉,但是,我发现却少有一些文章能够做具体的介绍。刚入职场或者工作不久的工程师,较少有相对系统的技术选型策略。其实,至关重要。如果选型不当,小则影响一个需求的工期延误,大则影响一个项目的成功与失败,甚至影响团队和企业的发展。本文则重点介绍一个前端类库的选型工程,以前端工程师所熟悉的 Table 类库选型为例。

原则

  1. 需求满足
    • 完全满足
    • 二次开发
  2. 商用许可
    • 免费
    • 付费
  3. 用户评价
    • GitHub Star 数量
    • npm 下载量
    • Issue 比例
  4. 学习成本
    • Demo
    • 文档

1.1 满足需求 - 必须

明确需求,列入清单,如我们的 Table 需求:

  1. React 技术栈
  2. 便于开发和维护迭代
  3. 具有排序、分页、虚拟滚动、表格分组、API 简洁、方便样式定制、DEMO 及文档完善等功能
  4. 压缩后体积较小
  5. 学习成本较低

1.2 License 许可证 - 参考

这点非常重要,所以单独列出来。作为面向市场的产品,我们必须把版权问题牢记于心。一般 License 分为开源免费和商业付费两种。

常用免费的 License 包括 MITApache 2,详情参考文末链接

个人观点:免费的未必不好,付费的未必就合适,根据需求和预算来选择适合的即可。

1.3 GitHub Star 数量 - 参考

其实 GitHub Star 数量就像商品的好评榜,越多越好。

1.4 npm 下载量 - 参考

npm 下载量是衡量一个开源项目使用情况的重要指标,类似于商品的销量。下载量很少的插件我们应该放弃使用,除非你确实对这个插件很了解。

1.5 Issue 比例

有些人会推荐大家看 Issue 的数量,但是我认为单存看数量不太合理,我们应该看比例。往往使用量非常大的类库,因为使用场景的复杂性相对 Issue 也较多。我推荐的 Issue 比例 = Issue 数量 / Download 数量,这样可以比较快捷并准确地评估 Issue 的多少。

调研

当我们需求明确以后,就可以根据上面的选型原则进行技术调研了,其实就是搜集上面的数据,并填入下面的表格。

根据需求的重要情况以及可选方案的多少情况来决定备选方案的数量,一般3~5个即可。太多整理及选型都需要大量时间,太少则参考很少,过于局限。

image.png

图表说明:

  • 所有统计数据均截至2021年8月11日
  • Issue 比例 = Issue 数量 / 下载数量,可以想想成商品的差评率,数值越大说明差评率越高。
  • 开发/维护者,是衡量一个类库开发质量或者后期维护情况的重要依据,例如谷歌开源或者维护的项目大家认为比个人开发者维护的项目或许更可靠。有利于类库的应该长期处于维护和迭代周期中,而不是长期无人维护。
  • Minified size 文件压缩后尺寸越小越好,这样不仅可以减少网络带宽,还可以提升网络访问速度,这个数值一般在npm trends中可查到。
  • Version 如果一个产品经常有大版本的发布,往往说明产品还处于快速迭代阶段,还不处于稳定阶段,或许会经常有 API 的更新,例如 breaking changes,不便于后期的迭代,如 Angular v1v2 就是断崖式升级,多数的 Angular v1 版本处于不可升级至 v2 的状态。

下载-前端技术选型评价表

方案确定

小组讨论

无论你是组长还是组员,我建议当你需要引入新的技术栈或者类库时,最好可以争取一下大家的意见。毕竟开发是一个团队工作,得到大家的一致认可是至关重要的。这将有助于新技术的引入和推广,同时增加你对团队的影响力。

讨论的形式不局限于开会,可以是一个简短的分享、一个站会或者是一个远程慧眼,亦或是例会之后的一个简短介绍。形式主要取决于技术栈的变革大小、重要性及以及团队的情况。

讨论过程

  1. 背景简介,为什么需要引入新的类库?最好能几句话概况总结。
  2. 需求介绍,把需要实现的需求告诉大家,将是技术选型的重要参考依据。
  3. 展示调研结果,最好可以形成表格,让大家一目了然,方便大家快速搜集信息。
  4. 提出你的观点,对每个备选方案进行介绍,优点及缺点。
  5. 大家发表自己的观点
  6. 确定方案

Tips:

  1. 将讨论过程中大家的疑惑或者提出的问题记录下来,这些都是难得的机会。
  2. 将讨论的结果记录下来,作为技术文档所归档。

总结

技术选型是一个看似简单,但是却非常的重要技能,很容易被大家所忽视。以上是我技术选型的原则和过程,在此与大家分享。也非常欢迎大家对我的观点和开发给予批评和指正。

参考文献

  1. 开源许可证教程
  2. npm trends