控件与业务

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

为什么要控件

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

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

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

遇到的问题

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

精心设计

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

过度借鉴

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

针对性优化

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

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

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

控件和场景

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

总结

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