写出可以正常工作的代码是一回事，而写出可以正常工作的且良好的代码则是另外一回事。

即使团队中的每一个人都希望能够成功并尽了最大的努力，系统设计在某些时候可能一步步走向泥潭。系统的变差通常是个缓慢的过程，需要相对较长的一段时间。也许是因为不停地为类型添加临时性的修复，而让越来越多的代码变的越来越难以维护和改进。最终你会发现，系统已经无药可救。

这时，管理层可能会进行完整的重新设计，重新设计的一个正在变化的系统就像是想要抓住一只正在逃跑的公鸡，你必须在途中竭力追赶，但你的团队真的有这种水平吗？

接下来将给出一些常见的信息，当这些信息出现时，就暗示你的设计或许已经开始走下坡路了。

1，坚硬，因些易碎
你能够折弯一块木头吗？若不停地用力又会怎么样呢？木头是一个坚硬且不易弯曲的东西，足够地用力才能毁坏。但如果继续用力，木头会直接碎掉，无法再复原。

坚硬的软件又如何呢？

坚硬的软件是指那些对修改有较大抵触的软件。抵触是通过复原能力来衡量的。若对某个模块进行了修改，这又引发了你不得不对其依赖的模块进行修改，就会很难预期某个修改（即便是最简单的那种）所花费的时间。

若用力击打玻璃等易碎物品，那么后果只有一个——玻璃碎了。同样，若修改软件时不得不将其完整破坏掉，那么这个软件毫无疑问可称为易碎的。

和生活中的其他领域一样，软件世界中坚硬和易碎也非常常见。当由于(隐藏的)依赖，以至修改某个软件模块影响了（很多）其它模块时，一般就会认为该软件的设计存在问题，需要尽快重新设计。

2，重新设计要比重用简单
假设某个软件在某个项目中工作良好，因此你考虑在另一个项目中直接重用。可是你发现，将类型或程序集复制过去后竟然无法使用。

为什么会这样呢？

若同样的一段代码在另外的项目中无法工作，那是因为这段代码与外界有依赖。依赖不是唯一的问题，问题还有依赖的个数和深度。存在依赖就会让你为了在其他项目中使用一小段功能，而不得不引入很多根本不需要的功能。最终，项目将变的无法、无处重用，只能从头开始设计。

对于设计而言，这并不是一个好的信号，这种设计上的不好之处通常就叫做顽固性(Immobility)。

3，临时修补要比彻底解决简单
在需要对软件模块进行修改时，一般我们都会找到不至一种解决方法。通常来说，仅有一种能够和原有设计配合得天衣无缝，不过这种做法通常较为费力。你也会找到一种更加简单的做法，虽然它更像个补丁，而不是彻底解决该问题的方法。

这时应该如何选择呢？

实际上两种做法都能完成任务，这主要取决于你的时间限制能及老板的倾向。

通常而言，临时的修补并不会比彻底解决问题简单快速很多，临时的修补也不会给整个设计带来太多难以纠正的不良影响。不过若积少成多，这就成了一个信号，说明你的代码已经乱成一团了，难以维护了。

这种设计上的不好之处通常叫做粘度。高粘度不是一件好事，因为这意味着软件难以修改，就像粘度高的液体不易流动一样。