软件开发的复杂性 ：
计算机硬件界的摩尔定律(每隔 18 个月计算机硬件的运算速度提高一倍，价格下降一半)适用于硬件的发展规律已经超过三十年了。人们想当然的认为计算机软件的发展速度和硬件的发展速度相当，但是不幸的是：每次重大的硬件升级之后，随着更大功能更丰富的软件的出现，硬件的潜能再一次被无情的榨取殆尽。许多开发的软件系统不断的遭受进度延期，人员资金和时间等预算无休止的增加，软件质量的不断反复，开发出来的系统对客户的新需求响应缓慢，更改困难的噩梦。
这样的现实是由软件的固有复杂性造成的，软件不同于硬件的生产过程，是由人的智力劳动完成人的需求到机器程序的翻译转换过程。需求可能不清晰，对需求可能出现个人理解上的差异，选择实现方法的差异，需求的不断变化，具体实现语言平台的差异，软件生产中采用的过程，具体实现人员的变动等等都会对最终的产品产生影响。想象一下，如果一种变化的因素只有两种可能，那么可以使用简单的 0 ， 1 表示，只有 10 个变化因素的组合就已经达到了 2--10=1024 种可能性，而实际开发中变化的因素轻易就超过 10 个以上，每个变化的可能是还不止两个，因此软件的复杂性很快就会超出人的理解程度。有一句经典的软件开发名言：世界上唯一不变的是变化本身。不断出现的变化，会使初始的设计和最终的需求之间的距离越来越远。
软件的臭味：
软件开发，使用，维护中出现了以下的“臭味”：
* 僵化性： rigidity 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。即使是简单的改动，也会迫使导致右依赖关系的模块的连锁改动。
* 脆弱性： fragility 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。出现新问题的地方和改动的地方没有概念上的关联，难以排错，排错的过程中又会引入更多的“臭虫”。
* 牢固性 immobility 很难解开系统的纠结，使它成为其他系统中重用的组件。系统中包含了对其他系统中有用的功能，当其他人想复用这个功能到新的系统时，剥离出独立的组件的难度远远大于重新实现的难度，在时间和进度的压力下，大多数人只有选择拷贝涂鸦的方式来实现新系统的功能。
* 粘滞性： viscosity 做正确的事情比错误的事情要困难。程序完成正常的功能总是倾向于得到不正确的结果。
* 不必要的复杂性： needless complexity 设计中包含有不具有任何直接好处的基础结构。为了预防后期维护更改需求的对源码的修改，在设计之初放置了那些处理潜在变化的代码来保持软件的灵活性，这样的结果是软件中包含了很多复杂的结构，理解起来更加困难。
* 不必要的重复： needless repetition 设计中包含有重复的结构，而该重复的结构可以使用单一的抽象进行统一。对鼠标右键(剪切，复制，粘贴)的滥用，使得完成同一或类似的代码片断出现在系统各处。如果原始的代码段完成的功能需要变化，或者存在错误，排错和增加新的功能变得非常困难。
* 晦涩性： opacity 很难阅读，理解。没有很好的表现出意图。
以上讨论了系统构架的臭味，下面讨论微观层次上代码的臭味：
* 重复代码：重复的代码使得更改功能和排错更加困难。同样的模块错误会在拷贝粘贴的程序各处多次出现。
* 过长的函数：程序越长越难于理解，这已经是软件业开发的常识。越难理解的程序，使用维护的成本就越大。如果一个函数的行数超过一页，很少有人能够在看到下一页的时候还清楚的记得函数开头的变量定义，理解和查错更加困难。
* 过大类：在一个类中完成几乎所有需要的功能。十项全能的人是不存在的，软件也一样。
* 过长的参数列：如果一个函数(方法)的调用参数过长，使用这个函数的调用过程也一定是困难的。想象一下，调用一个十个以上参数存储过程会有多么痛苦。这还只是开始，如果任一个参数的定义(名称，类型)发生轻微的变化，函数的调用客户端会有多么大的改动。
其他的臭味还有发散式变化，散弹枪修改，依恋情结，数据泥团，基本型别偏执，复杂的 switch 分支语句，平行的继承体系，冗赘类，夸夸其谈的未来性，令人迷惑的暂时值域，过度耦合的消息链，中间转手人，狎昵关系，异曲同工的类，不完美的程序库类，纯数据类(数据哑元)，子类不需要父类的某些特性，过多注释。详细的讨论可以参见《重构》的介绍。
文章来源于领测软件测试网 https://www.ltesting.net/