在日常的开发中,调试问题也占了开发的很大一部分时间,面对问题,如何进行解决问题。书中给了一些思路,分享给大家。
1、识别复杂问题的第一步,是将它们分离出来。既然不可能在半空中试图修复飞机引擎,为什么还要试图在整个应用中,诊断其中某个组成部分的复杂问题呢?当引擎被从飞机中取出来,而且放在工作台上之后,就更容易修复了。同理,如果可以隔离出发生问题的模块,也更容易修复发生问题的代码。
2、找问题
如果将代码从其运行环境中分离后,问题消失不见了,这有助于隔离问题。
·另一方面,如果将代码从其运行环境中分离后,问题还在,这也有助于隔离问题。
·以二分查找的方式来定位问题是很有用的。也就是说,将问题空间分为两半,看看哪一半包含问题。再将包含问题的一半进行二分,并不断重复这个过程。
3、提供有用的错误信息
错误提示与记录日志
错误发生时,是不是只要弹出一条优雅且带有歉意的信息给用户就足够了?并不尽然。当然了,显示通用的信息,告诉用户发生了问题,要好过由于系统崩溃造成应用执行错误的动作,或者直接关闭(用户会因此感到困惑,并希望知道问题所在)。然而,类似“出错了”这样的消息,无法帮助团队针对问题做出诊断。用户在给支持团队打电话报告问题时,我们希望他记录日志。
用很通用的错误消息,是无法提供足够的数据的。
针对这个问题,常用的解决方案是记录日志:当发生问题时,让应用详细记录错误的相关数据。错误日志最起码应该以文本文件的形式维护。不过也许可以发布到一个系统级别的事件日志中。
针对识别问题首先是分离出来,这块使我想起了曾经有一编程小伙伴在分享他的编程技巧时,提到了一种身份分离的编程思想。就是在日常编码中将需要编写功能分为主和次,也就是在自己是大哥身份状态时专心的写自己的逻辑,一旦发现自己需要调用其他方法其他小功能时,就要切换到小弟的身份。可以把功能点列出来,主流程上写大哥的代码,写完后再用小弟的身份写小的功能点供大哥去调用。 这样就可以以清晰的思路和更接近于方便分离的模式开发出高内聚低耦合的代码来。