Skip to content

一点思考 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
inJs opened this issue May 23, 2019 · 0 comments
Open

一点思考 #1

inJs opened this issue May 23, 2019 · 0 comments
Assignees
Labels

Comments

@inJs
Copy link
Owner

inJs commented May 23, 2019

推动某项规范(标准、最佳实践)落地最快的方法是——制定的规范尽可能少的存在想象空间。因为团队中每个人都是富有想象力的,如果留有太多的想象空间那规范就无法落地(对于 “好” 的认识不一致)。因此制定的标准必须清晰明了,能够供大家 case by case 的匹配最佳实践。举一个例子最近项目中遇到的问题:

在最近的一个项目中,我与同事在项目开始前做了充分的设计(当时还算充分,后来发现还是不够),对于 “业务组件” 这一块的设计尤其,粒度、命名等都做了充分的讨论。但随着项目的迭代,逐渐的暴露了很多问题,其中最典型的一个是:“为什么我们在有业务组件库的情况下,还有那么多 case 没覆盖到?”。ok,围绕这个问题,我与同事展开了讨论:

  • 我:“我觉得我们做业务组件的思路有点偏了,有点做成了通用组件的味道。导致有比较多的业务场景没覆盖到”

  • 同事:“还是业务组件,只是业务组件应该分层。至于对 业务贴合度不够的问题,我觉得是我们对业务切入的角度还不足够精细导致的”

  • 我:“业务组件应该是针对特定的业务场景的抽象,将特定业务域的问题解决即可,不需要考虑太多的通用场景”

  • 同事:“应该有 基础 UI 组件 --> 抽象业务组件 --> 定制业务组件”

ok,聊到这, 我陷入了一阵思考。这不是我想追寻的答案。我想追寻的更多是如何准确落地,解决特定问题的答案。于是我复盘了一下当初的设计过程:

不可否认,我们针对业务组件的划分、命名、props 做了足够多的讨论。但我们大多是套用一些宽泛的、发挥空间比较大的 设计理论。现在项目,其中最大的问题就是 “发挥空间比较大”,这是我们思路偏离的主要诱因。因此,在类似的场景中,我们的实现依据应该成文,而且套用这套规范,应该是始终能找到某个不确定问题的 “唯一解”。

最后感慨一下: 设计很重要!设计真的很重要!!

@inJs inJs self-assigned this May 26, 2019
@inJs inJs added the 杂谈 label May 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant