控件与业务

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

为什么要控件

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

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

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

遇到的问题

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

精心设计

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

过度借鉴

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

针对性优化

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

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

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

控件和场景

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

总结

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