增加复杂度的12危险信号

软件设计的哲学:增加复杂度的12中危险信号

 

软件系统的设计和开发过程中,增加系统复杂性的12中危险信号:

危险信号1:浅层模块

浅层模块的接口相对于它提供的功能来说是复杂的。浅层模块在与复杂性的斗争中帮助不大,因为它们提供的好处(不需要了解它们内部如何工作)被学习和使用它们的接口的成本所抵消。小模块往往是浅层的。

危险信号2:信息泄漏

当在多个地方使用相同的知识时,例如两个不同的类都理解特定类型文件的格式,就会发生信息泄漏。

危险信号3:时间分解

在时间分解中,执行顺序反映在代码结构中:在不同时间发生的操作位于不同的方法或类中。如果在不同的执行点使用相同的知识,它就会被编码到多个地方,从而导致信息泄漏。

危险信号4:传递方法

透传方法是一种除了将其参数传递给另一个方法外什么也不做的方法,通常使用与透传方法相同的API。这通常表示类之间没有明确的责任划分。

危险信号5:重复代码

如果同一段代码(或几乎相同的代码)反复出现,这是一个危险信号,说明您没有找到正确的抽象。

危险信号6:特殊和通用的混合物

当通用机制还包含专门用于该机制特定用途的代码时,就会出现此警告。这使得机制更加复杂,并在机制和特定用例之间产生信息泄漏:未来对用例的修改可能也需要对底层机制进行更改。

危险信号7:联合方法

应该能够独立地理解每种方法。如果你不能理解一个方法的实现而不理解另一个方法的实现,那就是一个危险信号。此微信型号也可以出现在其他上下文中:如果两段代码在物理上是分开的,但是每段代码只能通过查看另一段代码来理解,这就是危险信号。

危险信号8:注释重复代码

如果注释中的信息在注释旁边的代码中已经很明显,那么注释就没有帮助。这方面的一个例子是,注释使用与它所描述的事物名称相同的单词。

危险信号9:模糊的名字

如果一个变量或方法名足够宽泛,可以引用许多不同的东西,那么它就不能向开发人员传递太多信息,底层实体更有可能被误用。

危险信号10:选择很难的名字

如果很难为创建底层对象的清晰图像的变量或方法找到一个简单的名称,那么这就暗示底层对象可能没有一个干净的设计。

危险信号11:难以描述

描述方法或变量的注释应该简单而完整。如果你发现很难写这样的注释,那就说明你所描述的东西的设计可能有问题。

危险信号12:不易理解的代码

如果不能通过快速阅读理解代码的含义和行为,这是一个危险信号。通常这意味着有一些重要的信息对于阅读代码的人来说不是很清楚。软件设计的哲学

摘要:软件系统的设计和开发过程中,增加系统复杂性的12中危险信号。 阅读全文
posted @ 2020-01-04 10:08 peida 阅读 (108) | 评论 (0) 编辑
摘要:良好的设计是软件工程的一个重要目标,这本书中的思想应该会使编程变得更加有趣。 阅读全文
posted @ 2020-01-02 09:41 peida 阅读 (68) | 评论 (0) 编辑
摘要:大道至简:干净的设计和高性能是兼容的,复杂的代码往往很慢,因为它做的是无关的或冗余的工作。 阅读全文
posted @ 2019-12-31 14:40 peida 阅读 (332) | 评论 (1) 编辑
摘要:软件设计为易于阅读,而不是易于编写。设计和代码的可阅读性是好的设计和编码一个指标,面向阅读和维护编程。 阅读全文
posted @ 2019-12-30 11:47 peida 阅读 (254) | 评论 (0) 编辑
摘要:确保一致性需要一些工作:决定约定的工作、创建自动检查器的工作、寻找类似的情况以在新代码中模拟的工作,以及在代码评审中培训团队的工作。 这种投资的回报是您的代码将更加明显。 阅读全文
posted @ 2019-12-28 07:17 peida 阅读 (123) | 评论 (0) 编辑
摘要:破窗效应:如果每次都增加一点复杂性,时间一长就会发现各种临时妥协的处理越来越多,直到系统不可维护为止。避免破窗效应出现,每个开发组织都应该计划将其全部工作的一小部分用于清理和重构,这项工作从长远来看是值得的。 阅读全文
posted @ 2019-12-27 13:40 peida 阅读 (213) | 评论 (0) 编辑
摘要:编写注释的最佳时间是在过程的开始,即编写代码的时候。原因如下: 首先,编写注释使文档成为设计过程的一部分,其次,这不仅产生了更好的文档,而且还产生了更好的设计,第三,这会使的编写文档的过程更加愉快。 阅读全文
posted @ 2019-12-26 10:04 peida 阅读 (178) | 评论 (1) 编辑
摘要:为变量、方法和其他实体选择名称是软件设计中最被低估的方面之一。好的名称是文档的一种形式:它们使代码更容易理解。它们减少了对其他文档的需要,并使错误检测变得更容易。相反,糟糕的名称选择会增加代码的复杂性,产生可能导致bug的歧义和误解。 阅读全文
posted @ 2019-12-25 10:01 peida 阅读 (208) | 评论 (2) 编辑
摘要:注释的目标是确保系统的结构和行为对读者来说是显而易见的,这样他们就可以快速地找到他们需要的信息,并有信心地对系统进行修改。 ​ 有些信息可以在代码中以一种读者已经很容易理解的方式表示,但是有大量的信息不容易从代码中推断出来。 阅读全文
posted @ 2019-12-24 09:50 peida 阅读 (215) | 评论 (0) 编辑
摘要:好的注释可以使软件的整体质量有很大的不同;写出好的注释并不难;而且(这可能很难相信)写注释其实很有趣。 阅读全文
posted @ 2019-12-23 13:40 peida 阅读 (299) | 评论 (0) 编辑
摘要:两次设计的方法不仅提高了你的设计,也提高了你的设计能力。设计和比较多种方法的过程将教会您使设计更好或更差的因素。随着时间的推移,这将使你更容易排除糟糕的设计,并专注于真正伟大的设计。 阅读全文
posted @ 2019-12-22 07:25 peida 阅读 (202) | 评论 (0) 编辑
摘要:异常处理是软件系统中最糟糕的复杂性来源之一。任何形式的特殊情况都会使代码更难理解,并增加bug的可能性。最好的方法是重新定义语义来消除错误条件。对于无法定义的异常,您应该寻找机会在较低的层次上屏蔽它们,这样它们的影响就有限了。 阅读全文
posted @ 2019-12-21 07:13 peida 阅读 (185) | 评论 (0) 编辑
摘要:拆分或联接模块的决策应该基于复杂性。选择能够隐藏最佳信息、最少依赖和最深接口的结构。 阅读全文
posted @ 2019-12-20 08:00 peida 阅读 (254) | 评论 (0) 编辑
摘要:在开发模块时,寻找机会让自己承担一些额外的痛苦,以减少用户的痛苦。把复杂留给自己,简单留给用户。 阅读全文
posted @ 2019-12-19 07:51 peida 阅读 (430) | 评论 (0) 编辑
摘要:软件设计的哲学,解决软件复杂性的原则,中文翻译抢先体验版,持续更新中。 阅读全文
posted @ 2019-12-18 18:47 peida 阅读 (370) | 评论 (0) 编辑
摘要:软件系统是分层组成的,其中较高层使用较低层提供的功能。在一个设计良好的系统中,每一层都提供了不同于其上下层的抽象;如果您通过调用方法跟随单个操作在层中上下移动,那么抽象会随着每个方法调用而变化。 阅读全文
posted @ 2019-12-18 15:48 peida 阅读 (92) | 评论 (0) 编辑
摘要:与专用接口相比,通用接口有许多优点。它们往往更简单,包含更少的方法。它们还提供了类之间更清晰的分离,而特殊用途的接口往往会泄漏类之间的信息。使您的模块具有一定的通用功能是降低整个系统复杂性的最佳方法之一。 阅读全文
posted @ 2019-12-18 15:42 peida 阅读 (321) | 评论 (1) 编辑
摘要:信息隐藏与深度模块密切相关。如果一个模块隐藏了很多信息,就会增加模块提供的功能,同时也减少了它的接口。这使得模块更深入。相反,如果一个模块没有隐藏很多信息,那么要么它没有太多的功能,要么它有一个复杂的接口;不管怎样,这个模块都是浅层的。 阅读全文
posted @ 2019-12-17 19:39 peida 阅读 (111) | 评论 (0) 编辑
摘要:好的设计不是免费的。它必须是你不断投资的东西,这样小问题就不会积累成大问题。 幸运的是,好的设计最终会收回成本,而且比你想象的要快。 阅读全文
posted @ 2019-12-16 15:09 peida 阅读 (198) | 评论 (0) 编辑
摘要:如果一个软件系统难以理解和修改,那么它就是复杂的;如果它容易理解和修改,那么它就是简单的。复杂性来自于依赖和模糊的积累。随着复杂性的增加,它会导致变化的扩大、高的认知负荷和未知的未知。 阅读全文
posted @ 2019-12-16 15:05 peida 阅读 (222) | 评论 (0) 编辑
摘要:更简单的设计允许我们在复杂性变得不可抗拒之前构建更大、更强大的系统。有两种对付复杂性的一般方法:第一种方法是通过使代码更简单、更明显来消除复杂性。处理复杂性的第二种方法是封装它,这样程序员就可以在一个系统上工作,而不必一次暴露系统的所有复杂性。这种方法称为模块化设计。 阅读全文
posted @ 2019-12-16 14:47 peida 阅读 (204) | 评论 (0) 编辑
摘要:计算机科学中最基本的问题是问题分解:如何把一个复杂的问题分解成可以独立解决的几个部分。问题分解是程序员每天都要面对的核心设计任务。 阅读全文
posted @ 2019-12-16 14:37 peida 阅读 (234) | 评论 (1) 编辑
摘要:2020年必读书籍推荐:软件设计的哲学(A Philosophy of Software Design),本书190多页,豆瓣的点评分在9分以上,目前只有英文版本,中文版还未上市,英文好的同学建议去直接阅读原版。 阅读全文
posted @ 2019-12-16 14:35 peida 阅读 (246) | 评论 (0) 编辑
原文地址:https://www.cnblogs.com/Leo_wl/p/12337904.html