面向对象，结构化程序设计，组件化

一，面向对象

说起面向对象，很多人可以脱口而出：“封装，继承，多态”，面试的时候能说出这三点也基本差不多了。那么，在JavaScript中如何实现面向对象呢？ES6吗？只不过是实现以上三点的语法方式。 其实面向对象是一种数据结构的表达和组织方式。要从头开始理解面向对象，还是需要从结构化程序设计开始。

二，结构化程序设计

在接受一个任务时，一般是有两种方法：

• 自顶向下，逐步求精
• 自下而上，逐步求精

1，自顶向下，逐步求精

在接到需求之后，可以先划分模块，然后再一步一步考虑每个模块的属性和方法。这种方式结构层次分明，拓展性强，易维护，是 抽象到具体 ，就像建筑设计，设计整体框架之后再进行 细节方面的设计。

2，自下而上，逐步求精

“想到哪就写到哪，发现问题再改”，这是开发人员多数情况下最常用的方式，也是在架构稳定的情况下进行开发的方式。 就像房屋建设的施工阶段，从一砖一瓦开始实现一个局部，然后由各部分组成一个整体。

三，组件化

组件化的本质就是为了实现 自顶向下，逐步求精。
先来回顾一下 react 哲学 https://react.docschina.org/docs/thinking-in-react.html

构建应用的过程分为了以下这些步骤：

1. 第一步：将设计好的 UI 划分为组件层级
2. 第二步：用 React 创建一个静态版本
3. 第三步：确定 UI state 的最小（且完整）表示
4. 第四步：确定 state 放置的位置
5. 第五步：添加反向数据流

这种方式的最大问题就是第一步，也就是根据UI去划分组件层级，绝大多数的前端开发都有一定的数据库知识，工程化思想。我们不能要求UI同事有同样的能力。面对复杂的应用开发，如果不去熟悉业务，仅仅依靠UI去划分层级，很可能会让你的前端应用变得难以维护，逻辑混乱，出现方向盘安装在座椅上的情况。

所以构建应用的过程变成了以下步骤：

1. 沟通协调，协助产品和设计师完善需求解决方案（原型，设计图）。
2. 划分 应用组件 业务组件 容器型组件
3. mock 数据
4. 设计 store 数据流中心
5. 选择目录划分方式

1，沟通协调

对于一个产品来说，前端才是产品的 第一个用户 ，而且应该是在用户体验上最有发言权的人，因为开发应用的过程中会对产品的功能有更深刻的理解，能以数据，视图，交互多个维度去看到需求。 比如类似 todolist 这样的应用已经有无数个经受住考验的成熟方案，如果产品和设计 标新立异 ，首先是耐心劝导，提供方案，从对方有利的角度去说服，说服不了我们也可以继续进行下一步。

2，划分组件

不论第一步进展如何，我们都可以进行第二步骤
如果你阅读过 VUE风格指南 ，对下面的这些组件命名技巧应该不陌生。

基础组件 -------------

单例组件 -------------

耦合组件 -------------

组件命名单词顺序 -------------

此外还有 横线的方式

search-button-clear
search-button-run
search-input-query
search-input-excude-glob

引用 蚂蚁金服设计语言:
正如「格式塔学派」中的连续律（Law of Continuity）所描述的，在知觉过程中人们往往倾向于使知觉对象的直线继续成为直线，使曲线继续成为曲线。在界面设计中，将元素进行对齐，既符合用户的认知特性，也能引导视觉流向，让用户更流畅地接收信息。

格式塔学派（德语：Gestalttheorie）：是心理学重要流派之一，兴起于 20 世纪初的德国，又称为完形心理学；主张人脑的运作原理是整体的，「整体不同于其部件的总和」。——摘自「维基百科」

总结，想法

近期从事的工作多是 b 端，b端逻辑性强，需要了解业务。 真正熟悉业务之后，觉得UI 介入b端设计真的很多余，会扰乱前端工程结构，会增加前端开发负担， 对产品，对个人成长都是不利的。近期与UI进行了真诚的沟通，从对方的角度出发去说服对方在大厂规范的基础上去沉淀属于自己的业务组件，而不是从0到1的 发明创造 。 在刷抖音的时候刷到了腾讯的设计师在分享b端设计经验说到：“掌握了 60+大厂规范”，你就能解决80%的问题。 我个人觉得是比较谦虚的说法，因为她考虑的点比较细致，其实能掌握3个大厂的规范，就能解决95%的问题了。