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

朱雀 2022-08-24 11:27 135阅读 0赞

前几天在修改测试部提交的几个 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 。