认识达内从这里开始

我们在上文中给大家简单介绍了模块化编程开发的开发原则等基础知识，而本文我们就继续来学习一下，模块化开发应用实践分享。

一、构建模块

要实现整洁的模块设计。关键在于要实现一组小且作用的函数。

1、可组合性和可扩展性，如果在设计接口时就考虑到可扩展性，可能就会根据功能对相似用例进行分组，在此过程中也许就能避免不必要的API表层的扩展。

如果新的用例与设计抽象时所设想的情况足够类似，那么这个抽象方案可能就能满足那些突然出现的需求。

2、现代化设计，一开始不要试图让接口满足每一个可能的用例。不仅要将开发工时集中在当下需要的功能上，而且还要避免产生不必要的复杂性。

要牢牢抓住这种心态，努力将功能保持在所需的绝对低限度。

3、一点点抽象，当不确定是否将一些用例与某个抽象捆绑在一起时，好的方法是先等一等，看是否有更多的用例能被归入到这个抽象的范围内。

用了错误的抽象会严重损毁组件的接口。保证API表层尽可能小，不让使用者知道完成相同的任务有多种方法。

4.谨慎地行动和尝试，代码不能脱离产品而存在。对于同样的产品，代码越简单越好。谨慎行动是指所做的一切都是有道理可循的。

不提倡草率开发内部结构，鼓励经过充分的思考周全地设计接口。

二、CURST原则

1、适度使用DRY原则，如果始终努力压缩重复性的东西，反而更难找到正确的抽象。

如果一段代码变得简洁后却导致程序更难读懂，DRY原则可能就是一个坏主意。

2、特性分离，将小组件移到不同的文件中仍然是值得的，因为几乎不费力气就从父组件中消解了构成子组件的复杂性。

但复杂性没有消失，而是隐藏在这些子组件与父组件之间的相互关联中。

考虑实现一个服务层，把业务逻辑处理放在该层，或者实现一个持久层，所有缓存和持久化存储操作都发生在这一层。

越是把模块化做到极致，在文档和测试上花费的时间就越多。如果模块要依赖其所属代码库中的其他代码，那么分离模块比较有挑战，因为该模块所依赖的部分也必须被分离出来。

3、设计内部结构时进行权衡。

试图预测使用者的需求往往会增加代码规模和复杂性，还会浪费时间，对于改善使用者的体验几乎没什么用。

三、修剪模块

1、对错误的处理、缓解、检测和解决。

测试的目的主要是防止回归，防止在已经修复的BUG上又一次栽跟头，也防止因为用错误的方式调整代码而出现可预料的错误。

2、文档是一门艺术，文档不仅是帮助使用者在设计时查阅接口使用示例和高级配置选项的指南，还可以看作实现者提供发一种参考资料。

其实测试和代码注释也是某种意义上的文档，甚至变量名或函数名也应该被视为一种文档。

用正式文档描述公共接口，用测试用例描述值得注意的使用示例，以及用注释解释异常情况。

3、删除代码，如果部分程序变得陈旧，不再被使用，好将其删除，而不是推迟这种不可避免的命运。

开发人员可能会因为不确定无用代码是否在其他地方被使用而不愿意将其删除，随着时间的流逝，破窗理论开始生效。

很快代码库里就会到处都是不再被使用的代码，没有人知道其用途，没人知道代码库是如何变得混乱的。

4、考虑自己的情况(上下文)，在分析某个依赖项、工具或建议是否适合你的情况，一步是先找到相关的参考资料仔细阅读，并考虑它们所解决的问题是否就是自己要解决的问题。

永远不要执着于你不确定是否符合自己需求的东西，要多尝试。规则本来就是用来打破的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。