• 你还在把DRY编程思想奉为宝典?
  • 发布于 2个月前
  • 153 热度
    0 评论
  • 金龙鱼
  • 8 粉丝 44 篇博客
  •   

作为开发人员,我们经常听到一些诸如“不要重复你自己”的陈词滥调。我们按照这种思想去编码,并运行代码,有时候结果和我们预想的很不一样。
回头思考并评估一下我们为什么做这些事情是很有帮助的。所以今天,让我们来看看可以代替DRY编程的另一种编程思想。


不要重复你自己(DRY)编程思想的定义
根据维基百科,DRY的定义是:
在一个系统中,每一个知识都必须有一个单一的、明确的、权威的表示。


可能这听起来有点迂腐,但在考虑诸如编程思想之类的事情时可能会很有帮助。我们来分解一下这句话的措辞。


每一个
什么是“每一个”?我们不能重复一个变量名吗?或者一个HTML实体?
好吧,好吧。所以我们可以重复<div>,这没有什么问题,我认为没有人会反驳。但这确实带来了一个问题——我们什么时候决定某些东西已经变成了“每一个知识”?在React中,一个很好的例子可能是组件——但它是PrimaryButton和SecondaryButton,还是一个通用的Button类?答案通常是“你的团队选择什么”,但是这仍然会让我们对要选择抽象的内容模棱两可。


知识
这是另一个模棱两可的观点——我们如何定义知识?在使用一些原子类和React的时候考虑样式化的按钮元素。如果高级开发人员需要10秒钟来创建,那么他们可能认为这些知识不值得抽象。但是对于一个不太了解系统的初级开发人员来说,这些知识可能是一个很好的抽象。否则,他们可能不得不寻找一些类,提醒别人按钮是如何工作的,并想出一个onClick事件的语法。知识是相对的,在定义中使用它会增加歧义。


单一的,明确的,权威的表示(代表)
“单一”的表示方式会带来很多的要求。从一个开发工程师的角度来看,单一表示可能是他们需要部署的整个应用程序。对于前端开发,这可能是一个组件。对于后端开发,可能是一个类的方法或API接入点。这个区分界线从哪里来呢?


我们也有“无歧义”这个词——但正如我刚刚指出的,这句话的其余部分定义了更多的歧义。“权威”是有意义的——你的DRY代码应该准确定义它所做的事情,并要忠实于该定义。然而,这并不仅仅限于DRY代码。


系统
最后,我们来看“系统”这个词——这又回到了我们前一秒钟讨论的“单一”的描述。什么是一个“系统”?在React中,它可能是一个组件或一个Redux操作/组件/还原器。在容器化的软件中,我们可以讨论整个pod,也可以只讨论一个实例。
在一天结束时,DRY 经常会提升预优化,这是不必要的,有时还会损害你的编码能力。有时,修改抽象组件以适应特定用场景会变得更加困难。你增加了很多的复杂性,或者你把这个组件分解成一些新的东西——这并不是特别DRY的。你不可能一开始就知道你的组件的每个用例。


一个替代方法——将所有东西都写两次(WET)编程
相反,我建议使用WET编程。对我来说,定义是:
你可以问自己“我以前没写过这个吗?”两次,但是绝对不能问三次。
有了这个定义,焦点就不再是提前优化,而是允许你重复几次相似的代码。它还将焦点转移到更直觉的反应上。它允许你根据你正在查看的准确用例做出决策。如果你正在构建一个web应用程序,你可能希望将按钮抽象为组件,因为你将会使用很多按钮。但是,如果有一个具有一些特殊样式的页面(可能是定价页面?),那么你就不需要过多地担心提取该页面上的组件。事实上,在这个系统下,如果你需要一个跟那个特殊页面类似的新页面,你只需要复制/粘贴并更改所需的代码。然而,当第三次出现这种情况时,就是时候花点时间抽象出可以抽象的部分了。


我还要补充这一规定(对WET和DRY编程):
你必须对你的抽象进行注释。
每当你抽象出某些内容时,你就是在重新调整你的应用程序结构。如果你没有通过备注来说明你进行抽象的原因,那你就是在伤害你的团队(和未来的自己!)
你觉得呢?这跟你的未来发展有关系吗?


用户评论