前文《放弃“千行代码缺陷率”吧 》说明了为什么MTTR（平均缺陷修复时间）是个重要的指标。那么如何才能够缩短MTTR，使得整个工程团队的价值得到提升呢。今后将会就此话题逐步展开，分解到很多具体的工程实践上，以期望给诸位提供参考。

一、StackTrace

    很多编程语言的运行时，都会提供出错栈消息，最典型的就是Java的StackTrace。
    当Java代码执行的时候发生了Exception，后台会生成StackTrace。如果打印出来，就可以明确告知第几行代码出现了什么异常，那么就可以直接定位到该问题上。并且迅速解决掉。

   发生问题的点不一定是问题的根源点，但是问题的发生点清楚了，寻找根源点也就容易的多。

  StackTrace 有Caused By，可能还会有进一步的Caused By一直到RootCause，只要掌握了快速阅读StackTrace的技巧，解决此类问题的速度还是可以得到有效的提升的。

 小贴士：我见过太多的程序员有“英语恐惧症”，因为StackTrace信息都是以英文形式展示的。而程序员由于自身英语能力不行，所以选择了跳过这段最有价值的信息。所以，程序员们，最起码看到这里的英文的时候要自己阅读一下。实在看不明白，也可以搜索一下。

二、Log

   代码的错误也不一定就只会以Exception的形式出现。比如计算错误，逻辑错误，并不表现为系统的异常。

   一段电线损坏了怎么定位电线哪里有故障。一个常见的有效办法是：二分法。
从中间的位置检查，如果上半段没有问题，那问题就在下半段。然后依次递进，直到最后定位问题所在，就可以动手修复了。

同样的方法可以应用于软件的Bug定位。

首先，要确保代码是可以分割的。也就是说，分层，分模块等解耦合的方法都要用上了。这样就可以很好地插入检测点。监测点插入之后可以把代码运行一下看看，看代码运行到哪个位置停顿了，或者出错了，这样就比较容易的知道代码是如何被执行的了。

那么为什么不用Debug模式来解决问题呢？

首先，Debug模式需要暂停代码的执行，这个时候就要来大量记忆代码运行的位置，各种变量的含义，变量的值（Watch窗口只能看到当前类的变量），代码执行路径。如果步骤数太多，比如经历大量循环的时候要不停的点击按钮，造成疲劳感。这个过程是耗费很多时间，而且效果不佳的。

其次，Debug模式往往对于多线程无能力为。因为暂停的时候可能背后的某个线程已经在运行了。或者无法达到和真实情况基本一致的效果。导致Debug失效。

再次，对于回调函数Debug模式的表现也差强人意。

三、提高代码可读性和可维护性

当然， 并不是所有的Bug都这么容易的被解决掉，因为想要这样解决Bug得有一个大的前提，就是代码的结构非常清晰。如果代码的结构很混乱，耦合度很高，那么就不要指望什么高效的解决问题的方法了，首先要做的就是解耦代码。如果解耦实在困难，也许"重写"是个成本更低，效果更好的方法。

而可维护性指标直接影响了代码的缺陷修复速度。
高解耦的代码，在某个模块出现问题的时候，基本上就只会影响到该模块，并且根据出错的业务逻辑，可以直接快速定位到xxx类xxx方法。而且由于方法本身长度不大，会很容易的修复。

如何提高代码的可读性和可维护性呢。
1. 遵守编程的几个基本原则。
    单一职责原则 
    开放封闭原则 
    里氏代换原则 
    接口分离原则 
    依赖倒置原则 
    迪米特法则
    DRY原则 

2. 使用业已被广泛证明的了模式
    23种设计模式及实例

3. 设立团队的编码规范
    很多常见的命名规则都是已经成为事实标准了，编码的时候需要遵照这些事实标准，那么团队在解决问题的时候就会形成一个共识。比如：getter/setter就是获取和设置值的；大小写的写法；一些术语的用法；等等不一而足。

     但是，有些时候，比如关于一个数组的长度，不同的语言就会有不同的用法。
     有的叫做length，有的叫做size，有的叫做count。这些就提高一下兼容性吧。

四、建立有效的Bug Fix知识库

       当解决很多常见的Bug之后，Bug应该如何解决基本上应该都有一定的规律可以掌握了。建立起来如何解决常见Bug的知识库，不仅仅是对自己，对整个团队来说，也都是有价值的知识库。当新人加入的时候，快速融入团队，解决问题也就不是障碍了。