DRY原则

     

DRY是一种被高估的编程原理 - gordonc

1336 1 5K

DRY是我遇到的第一个编程原则,可能也是我在成为开发者的第一年中唯一意识到的原则。它也可能是最简单的理解原则之一。如果你在你的代码中看到两件相同的东西,也许它们就应该是一件东西。这一点很难说得通。但是.

DRY原则:识别模式并抽象概括 - javierdearcos

1152 1

DRY 来自“Don't Repeat Yourself”的首字母缩写词,是最普遍的开发原则之一。它是由Andy Hunt和Dave Thomas在他们的书The Pragmatic Programm.

设计习惯比较:高凝聚/松耦合、DRY/错误抽象 - Jesse

1474 1 4K
本文将面向对象分析设计的单一职责等SOLID原则应用于微服务划分,以及DDD领域划分/上下文分界/DDD聚合等设计概念中,是一种实际中每天重复的设计习惯:松耦合和高内聚这两个术语似乎同时存在的:这两个.

DRY原则在DDD实践中应用 -Berthon

847 1

开发人员喜欢使用首字母缩写词来说明“良好做法”(KISS,DRY,SOLID等)。通常,他们传达的想法非常容易掌握。DRY是dont-repeat-yourself不要重复自己意思,其目的是更好地管理.

DRY原则与微服务的矛盾:共享复用会导致耦合 - AllenHolub

1421 1

DRY(不重复自己)原则不是法律,而是经验法则。例如,在微服务中,最重要的是能够更改单个服务并孤立地重新部署该单个服务。如果使用共享库迫使您重新编译/重新部署多个服务,即使当前服务未使用刚更改的库的一.

干净整洁代码(Clean Code)的本质是什么? - mariocervera

3439 1 3K
当我们听到“整洁代码”一词时,通常会想到由罗伯特·C·马丁(Robert C. Martin)(也称为鲍勃大叔、鲍勃大爷)撰写的著名书籍:“整洁代码:敏捷软件工艺手册”(2009年)自从本书出版以来,.

幽默:四大设计原则要点

1253

稳健性原则:保守你发送的内容;在您接受的事情上保持自由。(banq注:说话谨慎,倾听自由,注重函数方法的返回结果,严谨且明确,输入参数则需要兼容抗打击)帕累托原理:80%的影响来自20%的原因。(ba.

重用或复用会导致耦合,微服务是宁可重复也不耦合 - Victor Rentea

2459 2

微服务避免了代码重用,其理念是:宁可代码重复,也要彻底避免耦合,因为重用意味着耦合,微服务架构是完全分离的。进化的架构!所以,DRY原则并不适用微服务。Microservices eschew cod.

对抽象方法仇恨的自白 - 250bpm

796 3K

我之前写过关于抽象成本的文章。一旦你在IT行业工作了几十年,一旦你在遗留代码上阅读了数百万行,你就会对任何一种抽象产生正常的怀疑。并不是说我们可以不做抽象。我们需要它能够编写代码。但是,每次在代码中遇.

清洁代码:职责 — Janos Pasztor

1568 4K

我听说你想成为一个更好的程序员。您希望使用可重用的部分,并希望更轻松地维护旧代码。您可能还希望在团队中更好地工作并确保减少错误。对更好代码的渴望通常会让人们发现“清洁代码”这个术语。这很可能是由罗伯特.

好的代码很容易删除!

1639 4K

编程是从浪费生命中学到的可怕教训,编写易于删除但不易扩展的代码。“每一行代码都是在没有理由的情况下编写的,有自己的弱点,并且偶然间会被删除” Jean-Paul Sartre的ANSI C编程。编写的.

这不是你想要的DRY

1013

“ 不要重复自己 DRY”,每个开发者都在他职业生涯的早期就学会了这个口头禅。对这个原则的共同理解是你不应该复制你的代码。就那么简单。不要复制,如果你发现重复就重构。违反此规则的行为将被其他开发人员立.

错误的抽象

1341

复制比错误的抽象便宜得多(代价小成本低),宁可重复而不选择错误的抽象。让人们意识到“错误的抽象”这个问题是很难: 程序员A看到重复。 程序员A提取重复并为其命名。这创建了一个新的抽象。它可能是一种新方.

复制粘贴比依赖更好

1 2684 2

人们过于害怕代码重复,过于憧憬可复用可重用的美好,导致对代码重复发起了一场神圣的战争。如今人们提出了不同的意见,在Twitter上引起了一场争论:“我呼吁结束针对代码重复的神圣战争。我们让年轻的开发人.

关于领域驱动设计中的“合法”性校验?

5 4454 3

各位在进行领域驱动设计开发的时候,实体的“合法”性是如何实现的,怎么保证实体的一致合法性?检验代码分布在实体中,还是在服务中,还是都有?如果分布在实体中,如何保证一次性校验,使用构造函数或工厂保证?如.