偶然复杂度(Accidental complexity)是指计算机软件开发过程中所引入不必要的复杂度。偶然复杂度不是待求解问题的本质，相对而言， 本质复杂度和待求解问题的本质有关，是无法避免的。偶然复杂度一般是因为选用求解问题的方法时所引入的。有时偶然复杂度可以归因于像无效的规划等错误，不过有时偶然复杂度是求解问题时伴随产生的副作用。例如因为内存用完而产生的复杂度是一种偶然复杂度，但只要决定使用计算机求解问题，就会存在这种复杂度。好的软件架构、设计及实现可以将偶然复杂度降到最低，过多的偶然复杂度是一个反面模式的例子。
定义复杂度是软件系统客观存在的属性，与软件系统组成元素，种类，数量，状态有关，同时元素之间互动，信息交换的频度有关。这些是系统本身的复杂度，而系统的实现映射到计算机里面，也会带来偶然的复杂度。偶然复杂度是指随着软件开发过程中引入的偶然的、任意的、附属的以及非必要的复杂度。偶然复杂度具有无序性、不确定性、非常规性、随机等特点。降低偶然复杂度需要做好软件架构设计和通过软件项目管理，降低软件开发的干扰。
复杂度70年代，软件系统已经变得极其复杂，无论是开发还是维护都是一项成本高昂的工作。人们意识到必须使软件模块化，以便于开发、测试和维护。为此，成立于1976的McCabe&Associates公司开发出了McCabe Cyclomatic Complexity Metric（圈复杂度）技术对软件进行结构测试。Metric以软件复杂度测量的数目为基础，能帮助工程师识别难于测试和维护的模块，圈复杂度已经成为评估软件质量的一个重要标准。人们可以用圈复杂度对软件的复杂度和质量进行衡量，来安排工程进度，在成本、进度和性能之间寻求平衡1。
本质复杂度(Essential complexity)是指由于一问题的本质不适合简单的求解方式，所有可行的求解方式都很复杂的情形。本质复杂度和偶然复杂度不同，后者的复杂度和问题本质无关，和选用求解的工具或方法有关。本质复杂度至少在1980年代中期已被使用，图灵奖得主佛瑞德·布鲁克斯当时已开始使用本质复杂度及其反义词偶然复杂度。他也在1995年时在《人月神话》中的没有银弹一段中提出他的新论点。若本质复杂度和循环复杂度并用时，本质复杂度有不同的含意。此时的本质复杂度是指一程式持续的将有良好结构的流桯控制指令改为单一叙述后，最后得到的循环复杂度。像if-then-else及while loop等控制结构都视为良好结构，因此不会增加本质复杂度。未限制使用的goto、break及continue指令会增加本质复杂度。
软件项目管理软件项目管理是为了使软件开发项目能够在预定的进度、成本、质量的目标基础上完成软件项目开发的工作。软件项目管理是对软件产品、开发人员、项目开发过程进行必要的分析和规范的管理的工程活动。软件开发项目管理的基本目的是，让软件项目在整个软件生命周期中（从需求分析、概要设计、详细设计、编码调试和测试验收、维护的所有过程中）都能在项目管理者的可监控之下进行，以满足预订的成本、按照预订的日程且保证质量的前提下，生产出满足客户需求的软件并交付给客户。而研究软件项目管理的目的，是为了通过从已经成功或失败的软件开发项目的案例中，总结出软件开发的通用原则和方法，用于以后的项目的管理工作。同时尽量避免前人产生的失误，从而降低在新项目中问题出现的次数。软件具有一定的特殊性，和其他工业产品不同，它是一种高逻辑的智力性产品，他是纯知识产品，软件项目开发的进度和质量不容易被估量和估计，生产效率也很难被预测和保证，再加上软件开发系统的复杂性也增加了对软件系统难以预见和难以控制的风险。软件开发的过程也是需要进行复杂的逻辑思维，和以往的传统工业产品相比较，软件的设计过程是贯穿于全部的软件开发过程，软件开发主要是需要使用较高素质的人力资源，在物质资源的投入的需求较少；软件开发的最终成果物一般仅仅是程序代码和技术性文件及说明和使用文档。软件项目管理的对象是成本、进度、质量和风险，软件开发团队成员在项目开发过程中的大力配合是软件项目管理实施的基础和保障。软件项目管理的主要内容包括：人力资源的组织管理、软件规模质量进度上的度量、项目风险管理、项目计划与策划、质量保证体系、过程能力评估和配置管理等方面2。在项目管理中，可以通过以下措施降低偶然复杂度：
沟通协作，降低项目的干扰，从而减少复杂度。流程，使得软件开发过程更有秩序，信息畅通，信息透明，加强信任，减少干扰。 这里暂且不谈，会在软件的生命周期里面谈到。
敏捷工程实践，提高对软件的控制力。 比如TDD， 单元测试，重构，持续集成，持续部署， 自动化。通过反馈，来提高对于系统的感知和控制力。极限编程和ASE开发都会提高对于软件的控制力。
反面模式在软件工程中，一个反面模式（anti-pattern或antipattern）指的是在实践中明显出现但又低效或是有待优化的设计模式，是用来解决问题的带有共同性的不良方法。它们已经经过研究并分类，以防止日后重蹈覆辙，并能在研发尚未投产的系统时辨认出来。
Andrew Koenig在1995年造了anti-pattern这个词[3]，灵感来自于GoF的《设计模式》一书。而这本书则在软件领域引入了“设计模式”（design pattern）的概念[4]。三年后antipattern因《AntiPatterns》这本书而获得普及，而它的使用也从软件设计领域扩展到了日常的社会互动中。按《AntiPatterns》作者的说法，可以用至少两个关键因素来把反面模式和不良习惯、错误的实践或糟糕的想法区分开来：
行动、过程和结构中的一些重复出现的乍一看是有益的，但最终得不偿失的模式
在实践中证明且可重复的清晰记录的重构方案
很多反面模式只相当于是错误、咆哮、不可解的问题、或是可能可以避免的糟糕的实践，它们的名字通常都是一些用反话构成的词语。有些时候陷阱（pitfalls）或黑色模式（dark patterns）这些不正式的说法会被用来指代各类反复出现的糟糕的解决方法。因此，一些有争议的候选的反面模式不会被正式承认。
本词条内容贡献者为:
王慧维 - 副研究员 - 西南大学