任何代码都可以以某种方式重用,至少在您修改代码时是这样.随机代码不是那么可重复使用.当我阅读一些书籍时,他们通常会说你应该通过考虑其他代码使用情况来明确地使代码可重用.但是某些代码也不应该是无所不能的所有人都在上课.
我希望有可重用的代码,以后我不必更改.你如何使代码可重用？代码可重用的要求是什么？可重用代码应该具有哪些东西以及哪些东西是可选的？
有关编写可重用代码的10个提示,请获取一些帮助.
保持代码DRY.干意味着"不要重复自己".
使类/方法只做一件事.
为您的类编写单元测试并使测试类变得容易.
从任何框架代码中删除业务逻辑或主代码
尝试更抽象地思考并使用Interfaces和Abstract类.
扩展代码.编写可以在将来轻松扩展的代码.
不要编写不需要的代码.
尽量减少耦合.
更模块化
像代码一样编写代码是一个外部API
如果采用测试驱动开发方法,那么基于即将到来的方案,您的代码只能作为重构重用.
就个人而言,我发现不断重构产生更清晰的代码,而不是试图猜测我需要为特定类编码的场景.
最重要的是,可维护性使代码可重用.
可重用性本身很少是一个有价值的目标.相反,它是编写代码结构良好,易于维护和有用的副产品.
如果您打算制作可重复使用的代码,您经常会发现自己试图考虑将来项目中可能需要的行为要求.无论你在这方面有多好,你都会发现这些未来的要求是错误的.
另一方面,如果您从当前项目的基本要求开始,您会发现您的代码可以干净,紧凑和优雅.当您正在处理需要类似功能的另一个项目时,您将自然地调整原始代码.
我建议查看所选编程语言/范例的最佳实践(例如,Java/C#类型的模式和SOLID),精益/敏捷编程文献,以及(当然)"代码完成"一书.了解这些方法的优缺点将不断改进您的编码实践.然后你的所有代码都将变得可以重复 - 但是"偶然",而不是设计.
另请参阅此处:编写可维护代码
在编写一个相对较大的项目时,您将编写各种模块(部件).实践中可重用的代码意味着您将创建需要相同功能的其他项目可以使用的库.
因此,您必须确定可以重复使用的模块
确定每个模块的核心竞争力.例如,如果您的项目必须压缩文件,您将拥有一个将处理文件压缩的模块.千万不要让它做超过一两件事.只有一件事.
编写一个将处理文件压缩的库(或类),而不需要压缩文件,输出和压缩格式.这将使模块与项目的其余部分分离,使其能够(重新)在不同的设置中使用.
你不必在第一次完美时将它完美,当你真正重用库时,你可能会发现设计中存在缺陷(例如,你没有使它足够模块化以便能够轻松添加新的压缩格式)并且您可以第二次修复它们并提高模块的可重用性.您重用它(并修复缺陷)越多,重用就越容易.
最重要的考虑因素是解耦,如果你编写紧密耦合的代码,可重用性是第一个牺牲品.
将所有必需的状态或上下文保留在库外.添加方法以指定库的状态.
对于"重用"的大多数定义,重用代码是一个神话,至少在我的经验中.你能告诉我有一些伤疤吗？:-)
通过重用,我并不是指在新的组件或服务失败之前采用现有的源文件并将其击败.我的意思是采取特定的组件或服务,并重新使用它而不做任何改动.
我认为第一步是让自己进入一种思维模式,即至少需要3次迭代才能创建可重用的组件.为什么3？因为第一次尝试重用组件时,总会发现无法处理的内容.那么你必须改变它.这种情况发生了几次,直到最后你有一个至少看起来可以重复使用的组件.
另一种方法是进行昂贵的前瞻性设计.但随后费用全部都在前期,并且好处(可能)会在未来一段时间内出现.如果你的老板坚持认为当前的项目进度总是占主导地位,那么这种方法是行不通的.
面向对象允许您将代码重构为超类.这可能是最简单,最便宜和最有效的重用方式.普通的阶级继承不需要考虑"其他情况"; 你不必构建"无所不能"的代码.
除了简单的继承之外,重用是你发现的东西而不是你发明的东西.当您想要重用一个自己的包来解决稍微不同的问题时,您会发现重用情况.如果要重用不适合新情况的包,则有两种选择.
复制并修复它.你现在需要几乎相似的包 - 一个代价高昂的错误.
在两种情况下使原始包可重用.
只需这样做就可以重用.而已.过多地考虑"潜在的"重用和未定义的"其他情况"可能会浪费时间.
京公网安备 11010802040832号 | 京ICP备19059560号-6 