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