0-4.jpeg

在开发过程中是不是经常遇到似曾相识的问题?这没关系。以前解决过的问题,现在还是可以解决掉的。

面对问题(并解决它们)是开发人员的一种生活方式。

当问题发生时,我们希望赶紧把它解决掉。如果一个熟悉的问题再次发生,我们会希望记起第一次是如何解决的。而且,希望下次能够更快地把它搞定。然而,有时一个问题看起来跟以前遇到的完全一样。但是,我们却不记得是如何修复的了。这种状况时常发生。

不能通过 Web 搜索获得答案吗?毕竟互联网已经成长为如此令人难以置信的信息来源,我们也应该好好加以利用。

从 Web 上寻找答案当然胜过仅靠个人努力解决问题。 可这是非常耗费时间的过程。

有时可以找到需要的答案,有时除了找到一大堆意见和建议 之外,发现不了实质性的解决方案。

看到有多少开发人员遇到同样的问题,也许会感觉不错,但我们需要的是一个解决办法。

要想得到更好的效果,不妨维护一个保存曾遇到的问题以及对应解决方案的日志。

这样,当问题发生时,就不必说:“嘿!我曾碰到过这个问题,但是不记得是怎么解决的了。”

可以快速搜索以前用过的方法。工程师们已经使用这种方式很多年了,他们称之为每日日志。

不要在同一处跌倒两次

可以选择符合需求的任何格式。下面这些条目可能会用得上。

  1. 问题发生日期。
  2. 问题简述。
  3. 解决方案详细描述。
  4. 引用文章或网址,以提供更多细节或相关信息。
  5. 任何代码片段、设置或截屏,只要它们是解决方案的一部分,或者可以帮助更深入地理解相关细节。

要将日志保存为可供计算机搜索的格式,就可以进行关键字搜索以快速查找细节。

推荐使用 印象笔记 http://www.yinxiang.com

如果面临的问题无法在日志中找到解决方案,在问题解决之后,要记得马上将新的细节记录到日志中去。

要共享日志给其他人,而不仅仅是靠一个人维护。把它放到共享的网络驱动器中,这样其他人也可以使用。或者创建一个 Wiki,并鼓励其他开发人员使用和更新其内容。

维护一个问题及其解决方案的日志。

保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。

切身感受

解决方案日志应该作为思考的一个来源,可以在其中发现某些特定问题的细节。对于某些类似但是有差异的问题,也能从中获得修复的指引。

平衡的艺术

  1. 记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单,不必达到对外发布式的质量。
  2. 找到以前的解决方法非常关键。使用足够的关键字,可以帮助你在需要的时候发现需要的条目。
  3. 如果通过搜索 Web,发现没人曾经遇到同样的问题,也许搜索的方式有问题。
  4. 要记录发生问题时应用程序、应用框架或平台的特定版本。同样的问题在不同的平台或版本上可能表现得不同。
  5. 要记录团队做出一个重要决策的原因。否则,在 6~9 个月之后,想再重新回顾决策过程的时候,这些细节就很难再记得了,很容易发生互相指责的情形。