后端工作主观上来看，是一个容易上手，却很难精通的岗位，因此经验对于快速debug就显的尤为重要。为什么这么说呢？众所周知，后端实现过程中的细节非常多，不同制程都有各自需要注意的特点，不同类型的设计，不同规模的设计也都有各自特殊注意的点，而要掌握这么多的知识本身就是一个非常耗费精力和时间的过程。那么，提高debug的效率，就可以让我们的工作进行的更顺利。如果有足够的背景知识以及丰富的经验的话，分析问题的效率高也是顺利成章的事情。但是，项目的需要，和人员资历的限制，不可能让我们万事俱备才开始后端工作。而后端工作容易上手的特点，就给了广大工程师一个台阶，好迈入岗位的大门。那么，在有限的条件下，如何能够提高debug的效率呢？个人结合多年的工作经验，进行了一些通用性思路的探索和总结。

• 遇到问题先分类。

• 正面查找原理，确定问题根源

• 破坏问题出现的环境，曲线解决

• 控制变量法去测试

• 及时求助相关领域专家

先说问题分类，根据问题出现的位置，阶段，关键字，来进行一个粗略的划分。然后搜集出现问题相关的信息。具体来说，就是在log中搜索相关的关键字，查找是否有相似的信息，异常的提示等。一般而言，大部分的error都会在附近找到相关信息。如果log中没找到直接相关的信息。那可以从输入的数据着手，寻找相关性。

至于正面查找原理这一点，除了准确的基础原理知识外，也可以参考相关手册来确认原理算法。确定好问题的原理，那么就可以顺理成章的对照，修改。当然，这一点短期不容易实现。

第三点思路，破坏问题出现的环境，间接的解决问题，或者说是避免问题发生。这一点容易实现，对背景知识的要求不高，但是存在一定的概率。举例说明，当绕线之后某一个地方出现了奇怪的drc，或者说较复杂的结构，如果从原理去分析，需要仔细测量这个pattern，然后根据drc 规则去分析如何改正。对于大多数非精通的人来说，正面解决有一定的困难，或者说需要花费的时间比较长。而破坏这个drc生存的环境是一个更加快捷的解决办法。于是，可以尝试改变这个drc周围的net的走向，宽度，位置等等，再用工具ecoRoute，大概率可以解决。

控制变量法测试。这个方法比较简单，就是经过简单的分析之后，怀疑是某一个因素造成的，就可以可保持其他的参数不变，只修改这一个参数，重新去执行出现问题的这个步骤。然后，对比结果，是否解决，再做进一步的分析，迭代。

最后一步，就是前面都没有解决的时候，或者同时，借助专业领域的专家的力量，或者有类似经验的同事的建议，进行分析处理。往往事半功倍。

后面会继续探索，希望能整理除一套系统化的方案，赶在AI出手之前，更高效的debug问题。