异味这个词，可能有点抽象，我们先看一下下面的例子。

 

这是一个CAD系统。现在，它已经可以画三种形状了：线条，长方形和圆。先认真的看一下下面的代码：

 

代码都是一直在改变的，而这也是上面的代码会碰到的一个问题。

现在我们有一个问题：如果我们需要支持更多的形状(比如三角形)，那么肯定要改动Shape这个类，CADApp里面的drawShapes这个方法也要改。

好，改为如下的样子：

 

如果以后要支持更多的形状，这些类又要改动……，这可不是什么好事情！

理想情况下，我们希望当一个类，一个方法或其他的代码设计完以后，就不用再做修改了。它们应该稳定到不用修改就可以重用。

现在的情况恰好相反！

每当我们增加新的形状，都得修改Shape这个类，跟CADApp里面的drawShapes方法。

怎么让代码稳定（也就是无需修改）？这个问题是个好问题！不过老规矩，先不说，我们以行动回答。

我们先看看另外一个方法： 当给你一段代码，你怎么知道它是稳定的？

怎么判断代码的稳定性？

要判断代码的稳定性，我们可能会这样来判定：先假设一些具体的情况或者需求变动了，然后来看一看，要满足这些新的需求，代码是否需要被修改？

可惜，这也是一件很麻烦的事，因为有那么多的可能性！我们怎么知道哪个可能性要考虑，哪些不用考虑？

有个更简单的方法，如果发现说，我们已经第三次修改这些代码了，那我们就认定这些代码是不稳定的。这个方法很“懒惰”，而且“被动”！我们被伤到了，才开始处理状况。不过至少这种方法还是一个很有效的方法。

此外，还有一个简单，而且“主动”的方法：如果这段代码是不稳定或者有一些潜在问题的，那么代码往往会包含一些明显的痕迹。正如食物要腐坏之前，经常会发出一些异味一样（当然，食物如果有异味了，再怎么处理我们都不想吃了。但是代码可不行。）。我们管这些痕迹叫做“代码异味”。正如并不是所有的食物有异味都不能吃了，但大多数情况下，确实是不能吃了。并不是所有的代码异味都是坏事，但大多数情况下，它们确实是坏事情！因此，当我们感觉出有代码异味时，我们必须小心谨慎的检查了。

现在，我们来看看上面例子中的代码异味吧！

(本文仅代表作者观点,与站长网立场无关.) 本文作者: 个人空间 档案 留言
上一篇：Samba远远不够 Sun寻与Windows合作方法   下一篇：让Firefox 3.0也能兼容老扩展插件