Robin的主页

选型没有最佳实践,因为每个项目所处的场景都是不一样的。 具体技术选型方案好坏,例如“为什么要选择React而不是Vue?”之类的文章网上已经很多了,这里不多讲。

本文主要谈一些选型原则和技巧,也就是说“道、法、术、器”中,我们聊的是“术”。

这几年工作中,除了自己做的技术选型外,还看了网上非常多的技术选型相关的文章。今天,我总结出以下几条最佳实践👇

基于业务场景

业务是目的,技术是手段。

技术服务于业务,并在伴随业务一同演变、成长。所以,要结合业务自身特点以及未来业务的可能演变方向来开展技术选型。

B端业务比较重,需要侧重的点是开发效率和长期的可维护性,这时候选择一些比较成熟的技术栈是比较好的选择。而C端业务更加注重用户体验,为了降低页面加载的白屏时间需要选择做SSR。

有的业务(设计到金额、结账之类的)会经常处理数字,在这种场景下TypeScript相对于ES6来说会是更好的选择。

基于团队能力

成员之间差异

团队由许多的个人组成,每个成员的技术能力、技术偏好存在一定的差异。所以在选型时,要考虑这些差异加以权衡。

是否有助于团队成长

团队如同一个孩子,挑食会导致影响不良,均衡的技术栈能让人更好地成长,所以技术选型要考虑是否有助于团队的成长。

如果团队都是React项目的,可以考虑在一些边缘项目或者简单的C端项目引入Vue,对整体技术体系冲击不大同时团队也有了Vue的能力储备。

与已有的整体相协调

  • 要考虑迁移成本。
  • 新的选型最好与旧体系相协调,协调意味着新、旧能够共生,而不会产生较大的破坏力。

新的技术体系引进来之后,是否要对老项目进行迁移,迁移会产生多少的成本。

选型处理要与团队已有的技术栈相协调之外,在公司范围内,选型需要考虑与公司整体的技术栈相协调(不一定要强一致调)。协调的好处有很多,例如:可复用性方面,其他团队的轮子可以直接接入到项目中,本团队有的轮子可被其他团队复用。

降低成本、提高效率

Focus on ROI.

技术本身是一种工具和手段,而工具和手段应该关注成本和效率

换而言之,技术选型需要考虑ROI。

  • 降低成本要求做相同的事情投入更少;
  • 提高效率要求付出相同的时间产出更多。

所以,选型要考虑如果降低成本、如何提高效率。好的ROI,也可能让你有一个好的KPI。

比如:上手难度要在允许可能范围内降到最低。一个项目往往会有很多的人参与开发,上手难度越低越有助于项目开发。

长期可维护

Think in longterm, do it in shortterm.

这里只谈——长期可维护,因为:

短期而言,所产用的技术都是比较热门的、知名度高、社区活跃,不存在可维护问题。

很多技术都是盛极一时,落伍的技术栈会导致维护成本增加,所以,选型时要考虑到项目的长期可维护性。长期可维护性需要考虑下面几个点:

  • 所采用技术的社区生态是否完善、周边配套工具是否完善。
  • 是否有人在维护,是否是大公司发起和采用的。
  • 选择较为稳定的。激进的框架变化非常快,看起来增加好多新能力,但是实际上需要用户频繁更新,一年没更新就落后很多,更新起来又有风险。

满足现在,兼顾未来

想得远,才能走得远。

技术选型时,“满足现在”这点基本上大家都能做到,但是“兼顾未来”是很多人所忽略的,因为很多人是短视的或者根本不思考未来的演变。

如果不前瞻未来,有时会产生以下问题:

  • 技术选型马上面临淘汰,维护成本攀升。
  • 技术选型不能满足未来业务发展的需要,需要再次更换技术选型并重构。

一切从简

Simple is powerful!

切记,能简单的不要复杂,更不要过度设计。

杀鸡焉用牛刀,对症下药才是正确的。很多时候,技术人员喜欢在选型时把许多牛bi的东西都加进来,实际上用处不大、可有可无,反而会增加维护成本。

所以在选型时,尽可能保持技术选型的简单。最简单的,才最可持续。

其他一些思考

  • 团队规模越小,技术越要收敛。同时如果团队未来会扩大,则选型时要考虑到这一点。
  • 借力业界的最佳实践。充分利用业界的最佳实践,在此基础上结合业务场景加以创新。
  • 商业化需要考虑法律问题,这不是开玩笑。对于要拿出去卖的东西,要考虑著作权保护。遇到“BSD+专利许可证”的开源项目,采用就要谨慎考虑了。
  • 大型公司内技术团队的技术选型较为简单,小公司考验团队的技术选型。大公司基本都会要求使用公司统一的技术体系,参考其他团队的选型少做调整即可。
- - - - - -
written by 陈烨彬 Robin Chen , and published under (CC) BY-NC-SA.