关于邮箱前端架构的一些思考（续一）--功能模块

今天主要给大家讲讲邮箱的功能模块这一部分，它跟架构有着同样的权重，因为如果一个产品就算架构再好，功能点薄弱，这个产品也不会有太多的生命力。给大家建议一点的就是，在功能模块这一部分，一定要结合自己开发所用到的技术，思想，融合起来，这样才能更好的去设计一个产品的技术架构。好了，多的不扯了，入正题吧。

1.功能模块的封装

在这一块，是考验一个FEer的基本功的地方 ，一个功能模块在实现了产品的业务逻辑与众多功能点的同时，又保证了其模块的内部结构组织的清晰，明了，这需要FEer在coding过程中不断的去总结和思考的。我在coding的过程中，有两三次曾推倒了之前的设计，因为在直接的结构上，这个功能模块的耦合性太高了，导致后续涉及到此功能模块的其他模块的封装成本太高，或者是执行效率太低。不过切记，千万不要怕重构你的模块，因为大多数功能你已经实现了，就是在模块的组织上面需要花费一点功夫，这才是你能力提升的一种很好的实践方式。
在模块封装之前，你需要去自习阅读产品设计文档，可能某个不起眼的小功能会让你在封装完之后发现，自己的数据结构扩展起来代价太大，需要重新设计，这就尴尬了，无形中给自己挖了很多坑，不断的去填一些完全可以避免的坑并不是一个FEer能力的真正展现，反而暴露了很多的问题。

在模块封装的过程中，你需要遵循小组内经过讨论约定的规范，比如说代码编写规范，设计规范，暴露出来的API规范，等等，都需要你去一一的落实下来的，只有很仔细的了解了这些规范之后，才能更好与他人合作，也少了许多后期维护的坑。

在模块封装完之后，还需要考虑的就是模块的输入输出，直白的讲就是你需要测试下你的模块在多种情况下输入对应的输出是否正常，在一些数据类型，数据结构上面一定要多加小心，举个栗子，一个功能模块的输入是一个配置，那么这个输入的参数就需要是一个option对象，而不是像function(param1,param2,param3)这样。

2.功能模块的复用

这里还是先举一个栗子，邮箱中的收件箱，草稿箱，回收站，垃圾邮件箱等，有没有觉得都差不多一个样子，只不过在一些细节的地方有略微的差别罢了，所以在邮件列表和邮件详情功能模块就要注意了，如何去复用这些功能模块，这是你需要结合你的实际情况去考虑的，不是所有的人都是做邮箱前端的，将思想融入到实践中，以不变应万变。

3.功能模块的扩展和可维护性

模块的可扩展和可维护性也是一个功能模块重要的组成部分。如何实现这两个特性，对于你的数据结构和函数的封装有很大的关系，在代码中多使用HOOK，原型，作用域链，对象，可以简化你的coding过程，同时增强了功能模块的扩展和可维护性。

^ _ ^