软件系统的设计和开发过程中，增加系统复杂性的12中危险信号：
危险信号1：浅层模块
浅层模块的接口相对于它提供的功能来说是复杂的。浅层模块在与复杂性的斗争中帮助不大，因为它们提供的好处(不需要了解它们内部如何工作)被学习和使用它们的接口的成本所抵消。小模块往往是浅层的。
危险信号2：信息泄漏
当在多个地方使用相同的知识时，例如两个不同的类都理解特定类型文件的格式，就会发生信息泄漏。
危险信号3：时间分解
在时间分解中，执行顺序反映在代码结构中：在不同时间发生的操作位于不同的方法或类中。如果在不同的执行点使用相同的知识，它就会被编码到多个地方，从而导致信息泄漏。
危险信号4：传递方法
透传方法是一种除了将其参数传递给另一个方法外什么也不做的方法，通常使用与透传方法相同的API。这通常表示类之间没有明确的责任划分。
危险信号5：重复代码
如果同一段代码(或几乎相同的代码)反复出现，这是一个危险信号，说明您没有找到正确的抽象。
危险信号6：特殊和通用的混合物
当通用机制还包含专门用于该机制特定用途的代码时，就会出现此警告。这使得机制更加复杂，并在机制和特定用例之间产生信息泄漏：未来对用例的修改可能也需要对底层机制进行更改。
危险信号7：联合方法
应该能够独立地理解每种方法。如果你不能理解一个方法的实现而不理解另一个方法的实现，那就是一个危险信号。此微信型号也可以出现在其他上下文中：如果两段代码在物理上是分开的，但是每段代码只能通过查看另一段代码来理解，这就是危险信号。
危险信号8：注释重复代码
如果注释中的信息在注释旁边的代码中已经很明显，那么注释就没有帮助。这方面的一个例子是，注释使用与它所描述的事物名称相同的单词。
危险信号9：模糊的名字
如果一个变量或方法名足够宽泛，可以引用许多不同的东西，那么它就不能向开发人员传递太多信息，底层实体更有可能被误用。
危险信号10：选择很难的名字
如果很难为创建底层对象的清晰图像的变量或方法找到一个简单的名称，那么这就暗示底层对象可能没有一个干净的设计。
危险信号11：难以描述
描述方法或变量的注释应该简单而完整。如果你发现很难写这样的注释，那就说明你所描述的东西的设计可能有问题。
危险信号12：不易理解的代码
如果不能通过快速阅读理解代码的含义和行为，这是一个危险信号。通常这意味着有一些重要的信息对于阅读代码的人来说不是很清楚。
原文地址：https://www.cnblogs.com/peida/p/12148088.html