在长期存在的应用程序中,我们经常想重写或重构我们以前为解决一个问题所采取的方法。
下面是我在重构过程中使用的一种非显而易见的命名技术,以确保改进后的代码最终被命名为好的类,并且任何旧的实现都被清楚地标记为要删除的。
你可能会发现这有助于组织你的工作,或者更好地与你的队友沟通未来的修改意图。
而不是...
......在你的代码库中乱写 "new "。
class NewDoThingJob << ActiveJob
# new implementation
end
或
class DoThingJobVersionTwo << ActiveJob
# new implementation
end
选择...
重新命名,或者更好的是,将现有的代码命名为废弃的代码。然后创建具有正确的未来命名的替换版本。
module ToBeRemoved
class DoThingJob < ActiveJob
# existing implementation
end
end
class DoThingJob < ToBeRemoved::DoThingJob
在调用非命名空间实现的地方,将其改为调用已废弃命名空间的实现。然后部署并确保应用程序按预期工作,并且非命名空间版本的代码没有被调用或排队。
现在你可以在正确命名的位置上实现新的、改进的方法。
class DoThingJob
# new implmentation
end
一旦你建立、测试并改变了对新版本的所有调用,你就可以删除(现在未使用的)namespaced版本。
为什么?
这是一个有助于沟通意图的习惯。
这些重构项目的规模往往很大,在一系列的变化中很难看清发生了什么。这种方法论清楚地阐述了替换现有代码的意图。
如果你把你的新实现称为NewSomething
,那么你团队中的其他人(以及未来的你)就不容易理解代码的发展方向。"我应该使用新版本了吗?"
此外,当你不可避免地没有做最后的重命名时,你就不会有被留下许多NewSomething
对象在你的代码中的风险。)
为这种重构选择一个命名空间,还可以让你在一个地方寻找所有未完成的重构和你的应用程序中未使用的代码。
这种交错的重命名还可以让你在一系列较小的版本中部署变化,并避免创建长期的重构分支,这些分支可能是重定位、合并和部署的噩梦。
为什么不呢?
这是一种个人偏好。没有任何 "基于代码 "的理由要这么做。
同样,你也不应该自动复制现有的命名。在给替换的实现命名时要抓住机会,以更好地反映新代码在做什么。
如果你正在建立一个被你团队以外的客户/用户使用的API,这可能不是一个好的解决方案。如果你正在开发一个新的版本,你仍然可能需要支持现有的版本。在这种情况下,一个新的v2
命名空间是一个好主意。
还有什么其他的吗?
你可能想把这种方法与在你以前的实现中添加弃用方法结合起来,以便通过你的代码与你团队中的其他成员进行更充分的交流。