预计阅读本页时间:-
33.记录问题解决日志
“在开发过程中是不是经常遇到似曾相识的问题?这没关系。以前解决过的问题,现在还是可以解决掉的。”
面对问题(并解决它们)是开发人员的一种生活方式。当问题发生时,我们希望赶紧把它解决掉。如果一个熟悉的问题再次发生,我们会希望记起第一次是如何解决的,而且下午下次能够更快地把它搞定。然而,有时一个问题看起来跟以前遇到的完全一样,但是我们却不记得是如何修复的了。这种状况时常发生。
不能通过Wed搜索获得答案吗?毕竟互联网已经成长为如此令人难以置信的信息来源,我们也应该好好加以利用。从Wed上寻找答案当然胜过仅靠个人努力解决问题。可这是非常耗费时间的过程。有时可以找到需要的答案,有时除了找到一大堆意见和建议之外,发现不了实质性的解决方案。看到有多少开发人员遇到同样的问题,也许会感觉不错,但我们需要的是一个解决办法。
广告:个人专属 VPN,独立 IP,无限流量,多机房切换,还可以屏蔽广告和恶意软件,每月最低仅 5 美元
想要得到更好的效果,不妨维护一个保存曾遇到的问题以及对应解决方案的日志。这样,当问题发生时,就不必说:“嘿,我曾碰到过这个问题,但是不记得是怎么解决的了。”可以快速搜索以前用 不要在同一处跌倒两次过的方法。工程师们已经使用这种方式很多年来, Don’t get burned twice他们称之为每日日志(daylog)可以选择符合要求的任何格式。下面这些条目可能会用得上。
□ 问题发生日期。
□ 问题简述。
□ 解决方案详细描述。
□ 引用文章后网址,以提供更多细节或相关信息。
□ 任何代码片段、设置后对话框的截屏,只要它们是解决方案的一部分,或者可以帮助更深入地理解相关细节。
要将日志保存为可供计算机搜索的格式,就可以进行关键字搜索以快速查找细节。图7-1展示了一个简单的例子,其中带有超链接以提供更多信息。
图7-1 带有超链接的解决方案条目示例如果面临的问题无法在日志中找到解决方案,在问题解决之后,要记得马上将新的细节记录到日志中去。
要共享日志给其他人,而不仅仅是靠一个维护。把它放到共享的网络驱动器中,这样其他人也可以使用。或者创建一个Wiki,并鼓励其他开发人员使用和更新其内容。
维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。
切实感受
解决方案日志应该作为思考的一个来源,可以在其中发现某些特定问题的细节,对于某些类似但是有差异的问题,也能从中获得修复的指引。
平衡的艺术
□ 记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单,不必达到对外发布式的质量。
□ 找到以前的解决方法非常关键。使用足够的关键字,可以帮助你在需要的时候发现需要的条目。
□ 如果通过搜索Wed,发现没人曾经遇到同样的问题,也许搜索的方式有问题。
□ 要记录发生问题时应用程序、应用框架或平台的特定版本。同样的问题在不同的平台或版本上可能表现得不同。
□ 要记录团队做出一个重要决策的原因。否则,在6~9个月之后,想在重新回顾决策过程的时候,这些细节就很难在记得了,很容易发生互相指责的情形。