控件与业务

本贴最后更新于 2396 天前,其中的信息可能已经时过境迁

前端的代码大致可以分为控件和业务,将可重用的逻辑和交互封装成控件是一种很好的控制复杂度的方式。有的时候设计同学希望精心设计业务中的每一个细节,导致控件中塞进一些只在某个场景下起作用的代码,这就破坏了控件的通用性和可维护性,增加了系统的复杂度。

为什么要控件

一个功能丰富的产品必定有许多的业务场景,每个场景都会有很多的细节。举个例子:设计一个收集数据的表单,那么,填写文本的地方如何展示、失焦时如何,聚焦时如何、必填而未填时如何提示、不可填写时如何使得它看上去就不可填写?填写时间的地方如何展示、如何选择年月、如何选择时间、如何切换 24 时制和 12 时制以及失焦和聚焦的效果如何?填写地址的地方,省市县如何联动、直辖市如何处理、是否提供搜索、如何搜索等等。

如果每个业务都要这样设计,那设计同学的精力恐怕不够,描述这样的业务的代码量也会爆炸。所以我们有控件这个概念,一个承担单一功能、可重用的、封装了交互细节的东西。每个业务中的按钮、地址、时间以及对话框等,都是同样的表现、同样的逻辑,它们的背后也是同一份代码。

从研发上来说,控件大大的降低了代码的复杂度,增加了代码的可重用性。从设计上来说,控件大大节省了设计同学的精力,使得设计的精力集中在业务本身。对于用户来说,理解了某一处的时间控件就理解了所有业务中的时间控件,这样在推出新功能时,用户就节省了许多学习成本,不会被多余的细节吸引注意力,从而快速地学习功能本身,这一点很重要。

遇到的问题

然而,在维护控件的过程中我遇到了一些值得注意的问题。在此记录并作一些讨论。

精心设计

首先,设计同学接到的任务是以业务或者功能为单位的,他可能出于责任心,希望精心设计他所负责的功能的每一个细节。但是,按照控件的概念,细节应该是封装在控件中的。研发在写代码时同样的代码不能写两遍,那么我天真的以为,同样的细节也不会设计两遍吧:) 有时会有这样的怪现象:如果是设计同学很忙的时候设计的功能,往往实现起来很顺畅,而碰上设计同学开足马力、精心设计的功能,实现起来就磕磕绊绊,很多交互细节的优化反映到代码里就变成了 丑化(也可能是我水平不够)。诚如某位前辈所说,“bug 都是精心设计出来的”。

过度借鉴

"借鉴"也会成为问题。设计同学经常会借鉴一些优秀产品的设计,这种借鉴有时会达到一个很夸张的地步,每一个优化每一个调整都有一个理由:“XXX 就是这样的”。确实,自身产品必定会有一些不足,别家优秀产品必定有值得借鉴的地方。可是换一个角度看,这一处借鉴了,其他相似的场景要不要借鉴?如果相似的场景有着不相似的表现,就会破坏产品的一致性,增加用户的理解成本,增加研发——好吧,这条不是打动设计同学的理由。总之,细节应该体现风格,风格应该贴合产品本身。考虑到这些,借鉴别家产品的细节是否应该更加谨慎?

针对性优化

还有一种情况也很棘手。有一天,某个用户(可能是 BOSS),说某个地方效果不好,要改。设计同学就针对这个地方做了“针对性”优化,这个“针对性”就是棘手的地方。设计同学希望调整某处被吐槽的地方,又不想作太大改动,引起更多的吐槽。

“这里的表格效果不太好,我想改一下”
“可以啊,很多地方用到了表格,要不要确认一下其他地方的效果”
“不,只改这个地方”
“为什么”
“只有这个地方效果不好,别的地方效果还可以”

这其实这不难做到,只要加个参数,加点判断就行了。可是这个变量名可能会很难起,因为是针对某个场景做的改动,描述这个场景可能要五十个字。效果好不好是个主观的事,是没有逻辑可言的。如果写这段代码的人忘了这个针对性优化,换一个人来看就会看到一段不知道干了什么又不敢去动的代码。不易看懂的代码积少成多,再加上人员变动,项目就会慢慢腐烂,这是一件很严重的事。

控件和场景

控件是通用的,但并非不能变化,控件是可以内置一些模式的。比如说,我们的提示框可以有成功、信息、警告、错误四种模式,按钮可以有蓝色、绿色、白色(为什么我们的按钮是这样分的)以及可用不可用等模式,复选框组可以有横纵两种模式等。设计同学可以通过设计控件的各种模式来满足不同业务的需要,这样就能在控件的通用性和场景的独特性之间取得一个平衡。

总结

设计业务时应该专注于业务本身,尽量使用已有的控件完成业务场景,如果已有控件满足不了,那就重新设计控件。无论是新功能还是交互优化,都应该遵循这个原则。业务场景是独特的,而控件是通用的,没有这里的控件和那里的控件之分,千万不要在控件中加入适配业务场景的逻辑。否则尽管每个场景下控件看起来都很正常,内部代码却混乱不堪,充满了各种参数和判断,只有熟悉所有场景的人才能读懂。

  • JavaScript

    JavaScript 一种动态类型、弱类型、基于原型的直译式脚本语言,内置支持类型。它的解释器被称为 JavaScript 引擎,为浏览器的一部分,广泛用于客户端的脚本语言,最早是在 HTML 网页上使用,用来给 HTML 网页增加动态功能。

    710 引用 • 1173 回帖 • 192 关注
  • 业务
    5 引用 • 26 回帖
  • 控件
    1 引用 • 6 回帖

相关帖子

6 回帖

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 88250

    谢谢分享 ❤️

  • FlyingFinger

    其实原生的玩透了组件什么的就手到擒来了可惜俺修行还不够且修且珍惜~ 😂

  • 一个控件要用到很多地方,需求还不太一样。各种兼容,各种接口。最后自己都看不下去了。。。

    1 回复
  • gfafei
    作者

    前端同学表示:我能怎么办,我也很无奈

    1 回复
  • SQLite 会好一点么?

  • wizardforcel

    针对性优化,用文档的思想就是加个 #id,它会覆盖你的 .class

    用控件思想就是来个继承。在构造器里把参数都设好。

请输入回帖内容 ...