捉虫经历：耦合度过高引入的一个bug

前几天在修改测试部提交的几个 bug 时，却引入了一个新的 bug 。修改 bug 却引入了新的 bug ，这也很正常。但我修改的那个 bug ，不复杂，只是新增了两行代码，本不应该引入 bug 的。

后来打开 svn 的提交记录，找到 被修改的代码，打了个断点进行调试，结果发现在前端的两个菜单共用了后台同一个 action 中的同一个方法，在代码中加入了 if else 来判断处理不同的菜单。后来看了下 IDE 中的 annotation 发现是同事写得一段代码。怪不得，我修复了一个菜单中的 bug ，却引入了另外一个菜单的 bug 。

这大概就是软件工程中所说的高耦合吧，不知道写代码的人当时是为了省事图方便少写一个方法，还是为了复用代码，结果就是前台页面中的两个菜单共用了后台中的同一个 action 中的同一个方法。按正常的写法，应该是一个前台菜单对应着后台的一个 action 中的一个方法，这样即使是别人维护你写的代码，也好维护，在修改代码的时候，也不会引起其他菜单的 bug 。如果是自己写的代码，自己维护，还好说，自己知道哪里有坑儿，自己在有坑儿的地方，会小心谨慎。

如果这两个菜单调用的后台代码确实需要相同，我们也不应该两个前台菜单对应后台同一个 action 中的同一个方法，况且还是加了 if else 来判断是来自哪一个菜单，然后才做相应的处理。如果两个前台菜单对应的后台代码确实完全相同，我们完全可以这样来写，来避免高耦合。

假设我们有两个前台菜单，分别叫 menu1 和 menu2 ，分别对应着后台同一个 action 中的 method1 和 method2 ，然后还有一个私有的公共方法叫 commonMethod ，在这个公共方法中抽象出了所有的业务逻辑。我们可以在 method1 和 method2 中分别调用这个公共方法，这样一来不就达到了复用代码的目的了，而且还解耦了。

    public void method1() {
        commonMethod();
    }  
    public void method2() {
        commonMethod();
    }  
    private void commonMethod() {
        // 业务逻辑处理
    }  

如果在将来两个菜单中的一个菜单的业务逻辑发生了变化，另外一个没有发生变化，我们需要重构我们原来的代码。我们在重构代码的时候，会看到 method1 或 method2 中调用了一个私有的方法，我们一般会搜一下，看有没有其他方法也调用了这个私有方法。如果没有其他方法调用这个私有方法，我们就可以放心大胆的重构代码了。如果有其他地方调用了这个方法，我们就会考虑直接在这个私有的公共方法上修改，还是重新写一个新的方法。这样一来就能避免引入新的 bug 。