前端组件化

 

传统的开发方式

 

 

概述

 

根据页面的渲染过程来编写代码结构。像：init -> getData -> processData -> bindevent -> report -> xxx 。 方法之间线性跳转，你大概也能感受这样代码弊端。随着页面逻辑越来越复杂，这条” 过程线“ 也会越来越长，并且越来越绕。加之缺少规范约束，其他项目成员根据各自需要，在” 过程线“ 加插各自逻辑，最终这个页面的逻辑变得难以维护。

 

 

 

面向过程

 

 

最为实际的一种思考，也比较符合普通人的思维方式，它考虑的更多是实际的实现，从上而下的步步求精。不过缺点也比较明显，因为每一步都依赖它的上一步计算结果，导致整个功能为一个整体，牵一发而动全身，另外也限制了复用的可能性。

 

 

 

组件化编程

 

 

概述

 

组件就是将一段UI样式和其对应的功能作为独立的整体去看待，无论这个整体放在哪里去使用，它都具有一样的功能和样式，从而实现复用，这种整体部分的思想就是组件化。不难看出，组件化设计就是为了增加复用性，灵活性，提高系统设计，从而提高开发效率。与模块化类似，组件化是页面层次上，按照功能纬度来进行分割，从而达到隔离复杂度的目的。

 

康威定律：软件源代码的组织结构要与开发团队的组织结构尽量保持一致

 

 

 

目的

• 降低页面复杂度
• 提高可维护性
• 增加可读性
• 方便单元测试
• 提高可复用性
• 提高开发效率
• 提高维护效率（分而治之）

 

 

 

 

结构化编程

 

功能性降解拆分，我们可以将一个大型问题拆分为多个高级函数，再将高级函数拆分为多个低级函数，如此无限递归下去，层层分解，且每一个函数也可以通过结构化编程来分解，最终可以拆解成更小、可证明的函数单元。

但是形式化证明并没有发生，因为程序和数学还是不同，程序没办法被证明，只能够被证伪。我们写的单元测试，或者由测试人员进行的测试只能证明在当前环境是足够正确的。

 

禁用goto无条件转移语句

 

 

 

组件划分

 

通用组件：

 

具有业务通用性，普适与一般的业务场景，为了复用而被创建，可被沉淀下来被多处使用，可以被单独维护和扩展。目前市面上开源的组件都是通用组件。

 

业务组件：

 

包含完整的功能逻辑，具备控制层职责，为高级策略组件，是稳定抽象层，整个功能中最稳定的部分，负责高级策略的定义，整体轮廓的搭建，及其他策略类的创建与配置。智能组件

 

原子组件：

 

业务组件中直接依赖的低级策略组件，作为业务组件的一部分存在，通过组合功能完成功能，只负责展示相关的职责。木偶组件<