模块化设计与实战

Posted 2020-10-30

在阐述模块化设计的时候有必要先说明下其概念。

模块化程序设计是指在进行程序设计时将一个大程序按照功能划分为若干小程序模块，每个小程序模块完成一个确定的功能，
并在这些模块之间建立必要的联系，通过模块的互相协作完成整个功能的程序设计方法。

我一直认为模块化的概念在很多领域都是相通的，其所用的方法就是分而治之法，将一个复杂的问题分解成若干小的问题，

因为从宏观上来讲人们很难从抽象的角度去将问题剖析的非常透彻，并且在问题逐渐被纵深化以后会产生意向不到的问题，

从整体去解决一个问题往往很难抓住细节，在这些错综复杂的小细节中又往往会扰乱你的思路，所以经过前人大量的经验总

结产出了一套模块化思想的方法体系并且成功的应用到很多领域。了解了这个概念之后我们可以从不同角度来分析如何将我们

的代码设计的更好，更容易维护，和团队协作。

从函数的角度分析

函数又名方法，步骤等，函数之所以能够出现在程序设计中并且形成一种语法，那么他势必是要解决领域问题，
初学者往往会把所有的代码不管三七二十一统统写入一个函数中，并且取一个只有自己才能看懂的函数名，那么
我想说，还不如不用函数，这样计算机还节省一点执行函数的开销，速度跑的更快，那么怎样才能正确的理解函数和使用函数呢？
我认为从以下几点进行改善：

1. 函数名： 首先要取一个准确的函数名，不要担心它很长，目的是为了说清楚这个函数要做什么。
2. 参数：   准确的参数命名，将参数的个数尽可能控制到最少，这样为了减少耦合度，让你的api更加简洁。
3. 方法体： 首先保持你的代码干净这是基础，其次方法体，让它只做与本身职责有关的事情，尽可能让外面少知道这个方法
           内部发生了什么，知道的越多耦合就越高。
4. 函数组织：按照概念的相关性将这些函数组织到一起，例如 event是个事件，那么可以将事件的绑定组织在一起，这样易于
           维护 和查找。

从功能的角度来分析

大家都知道，问题总是从简单到复杂的，当问题复杂的我们很难去管理和思考的时候，我们开始将函数解决问题的思路移植到模块设计的
思路上，往往模块更像一个独立的功能，模块的概念要比函数的概念更加宽泛一些，我们也可以认为一个函数就是一个特殊的模块，很多
框架都提到了模块的概念，并且尽可能在语法上将其表现出来，但是我们如何很好的发现一个模块并且合理的将它定义出来，
我个人是这么理解的：
1. 功能独立性，以提供服务为目的，对于其自身来讲他属于产品的一部分，可以提供可用的服务，对于它内部有自身的运行环境，
   以由多个函数协同合作对外提供服务为目的。
2. 在定义模块的时候要思考其易用性和单一职责，他的职责就是提供独立的服务，如果一个模块需要提供多个服务的时候，要考虑其 
   服务之间的关联性，如果这些服务在概念上完全不相关可以考虑将模块拆分成多个模块。
3. 模块最终是要以组合的形式构成一个完整的产品，那么模块与模块之间的通讯要考虑其通讯方式和通讯接口的标准化以及简洁化， 
   简洁是为了让它更好的被使用。

从组件化的角度来分析

组件=模块？个人认为组件和模块在一定程度上可以等同，但是在设计思路上又不完全相同，其主要原因有以下几点：
1. 从概念上来讲组件更像一个小型产品，他可以脱离产品独立使用，站在用户层面他是一个日历或者一个滚动的滑
   轮可以形象的被描 述出来。
2. 组件可以包含多个模块，由多个模块协同工作来提供特定的功能以及表现。
3. 站在前端的角度，从概念上来讲组件可以被划分为特定的几个类型。
   业务组件：为了解决某些特定业务问题，复用性不是很高。
   通用业务组件：为了解决整个业务范围内某些问题，复用性相对比较高。
   通用功能性组件：可以跨业务解决某些特定问题，复用性最高。
4. 不同维度的组件，在设计思路上是不尽相同的，解决的问题越是通用，越是要设计的灵活。

从产品的角度来分析

当产品和产品之间发生关系的时候，考虑问题的思路将会上升到更高的层面：
1. 由产品表面产生的一些列问题将会逐层传递到组件，模块以及函数内部，例如安全性问题，通讯的问题等。
2. 在错综复杂的产品之间发生关系，同样可以按照模块化设计的思想将产品进行组织和管理以服务为目的进行交互。

综上所述： 模块化设计的好处主要在于：

(1)控制了程序设计的复杂性。
(2)提高了代码的重用性。
(3)易于维护和功能扩充。
(4)有利于团队开发。

更多文章 请访问我的技术栈 前端架构解决方案