程序员解决问题的60个策略

   <p>程序员的生活就是解决一个又一个问题，永无止境。这篇文章介绍了一系列解决问题的策略。</p>    <p>根本的指导方针</p>    <p>1. 首先写代码的时候最好不要有缺陷。最好的修复方法就是让 bug 胎死腹中。</p>    <ul>     <li>良好的单元测试</li>     <li>强制数据库约束</li>     <li>使用输入验证框架</li>     <li>避免未实现的“else”条件</li>     <li>在应用到主程序之前知道如何在孤立的情况下使用</li>    </ul>    <p>日志</p>    <p>2. print 语句。往往额外输出个一两行将有助于隔离问题。</p>    <p>3. 切换至详细的日志记录。详细的日志记录有助于发现更多的线索。</p>    <p>4. 搜索日志。如果日志太多，可采取关键字或错误代码来搜索日志文件。</p>    <p>5. 开启自动换行和关闭自动换行。控制日志的自动换行也非常有用。</p>    <p>6. 搜索不同的日志。主服务器的日志可能并不是唯一有用的日志。</p>    <p>7. Windows 事件日志。日志文件的另一个来源可能是操作系统本身。</p>    <p>8. 制作有用的日志记录。有时，如果你没有得到任何有用的日志记录，那么你可能需要自己写。</p>    <p>与其他人交流</p>    <p>9. 询问一些可能知道问题答案的人。</p>    <p>10. 问”愚蠢“的问题。可能你觉得这些问题很愚蠢，但其实并不是。</p>    <p>11. 将问题解释给队友。他们可能知道答案或者能提出一些你并没有想到过的事情。</p>    <p>12. 将问题解释给你的狗。述说的对象是谁其实没有关系，但是能让你从不同角度分析问题。</p>    <p>写作</p>    <p>13. 描述问题。用最准确和最精确的语句描述问题，有助于你去思考可能的解决方案。</p>    <p>14. 问题日记。创建一个文本文件来记录已经尝试的各种方法，包括代码片段、配置设置以及产生的任何错误。</p>    <p>15. 记录问题和解决方案。有没有这样的情况，突然看到一个似曾相识的问题，只记得解决过但却忘记了是如何解决的？可以将问题和解决方案记录到一个容易搜索的地方，如维基、缺陷跟踪，甚至可以发送电子邮件给自己。</p>    <p>支持</p>    <p>16. 阅读 FAQ。</p>    <p>17. 提交支持请求。如果有可用的产品/库的支持，那么就用。</p>    <p>18. 在你点击 send 之前，请三思。写支持请求能让你再一次思考问题，有时候就在你点击 send 按钮之时，突然灵机一动就想到了解决问题的方法或者是新的线索。</p>    <p>19. 其他方面的支持。可以与开发人员直接面对面交流，最好是实时聊天/ SKYPE/屏幕共享。</p>    <p>离开键盘</p>    <p>20. 散散步。</p>    <p>21. 打个盹。</p>    <p>22. 重置优先级。暂时从键盘上离开还有一个好处就是可以让你重新评估这个问题的重要性，也许这个问题只是个 CSS/布局问题，根本不值得你花上 16 个小时。总之要有效分配和使用时间。</p>    <p>23. 暂时将这个问题放在一边。实在解决不了的话，可以将这个问题先搁置起来。也许几天后你在阅读相关问题的时候，突然一个激灵，解决问题的关键就来了。</p>    <p>隔离</p>    <p>24. 确定是哪行代码。首先要确定是哪行代码导致的问题，以便于插入 print 语句。</p>    <p>25. 将问题分割为一个单独的程序。有时候对于库和产品的问题，我们可以将它的相关代码从主程序中分离开来。这可能需要一点时间，但往往处理一个孤立的程序比应对整个的项目构建过程要容易得多。然后在解决这个单独程序的基础上再去和主程序作比较。</p>    <p>更改代码</p>    <p>即使你一点都不知道如何解决问题，更改代码也是一个挺有效的解决方法。</p>    <p>26. 写新的单元测试。</p>    <p>27. 重构。有问题的代码往往显得有点乱，通过一些简单的重构方法，例如重命名变量或展开嵌套的 if / then/ else 模块等都可以让代码整洁起来。</p>    <p>28. 发现 bug。另一个整洁代码的手段是查阅相关代码的“Find Bugs” 报告，我们之所以首先要整洁代码是因为：作为一个能让我们的大脑专注于代码的方法，既简单又划算。</p>    <p>29. 重写。转存所有的相关代码，从头开始重写。一个全新的视角也许能让你完全规避这个问题。</p>    <p>30. 为一些不必要的代码添加注释——或者至少是你以为是不必要的。然后你会发现可能这些代码流并不像你曾经以为的那样“没有必要”。</p>    <p>31. 实验。如果你不能确定底层产品或库是如何工作的，那么一些小实验，特别是围绕边界条件的实验会非常有用。</p>    <p>32. 回到干净的状态。如果你在代码中做了各种变动，或者是搞了很多配置设置，那么定期回到一个干净的状态就非常重要。否则，实验结果可能会影响正确答案，这样你就永远也找不到正确的解决方案了。</p>    <p>33. 切换技术。</p>    <p>产品</p>    <p>34. 升级到更高的版本。也许你正在处理的问题已经被修复了，可以试试先升级到另一个版本。</p>    <p>35. 降级到以前的版本。也许问题正是由于与你目前正在使用的其他产品/库不兼容而引起的。</p>    <p>36. 打补丁。</p>    <p>37. 下载并安装源代码。</p>    <p>文件</p>    <p>38. 阅读手册。大多数开发人员可能会认为这是一个低概率的策略，但是，嘿嘿，你永远不知道，也许答案就在文档中。</p>    <p>39. 阅读手册的正确版本。</p>    <p>40. 手册是否正确？有时候代码已被更新，但手册还没有。</p>    <p>调试器</p>    <p>41. 了解键盘上的快捷键。</p>    <p>42. 倒退。这是调试器的一个功能，让你的代码退后一步。</p>    <p>43. 编写断点代码。</p>    <p>44. 异常中断。调试器的一个蛮有用的功能就是可以捕捉到任何地方的特定异常。</p>    <p>45. 专业化的调试工具。例如：</p>    <ul>     <li>Plumbr</li>     <li>AppDynamics</li>     <li>Chronon</li>     <li>Wireshark</li>     <li>HTTP profilers：Fiddler2、Charles、Live Http Headers</li>    </ul>    <p>源代码控制</p>    <p>46. 对 bug 缺陷进行编号标记。你有没有碰到过这样的问题：先是用这种方式被修复了，然后几周后又成为了 bug 被其他人用另一种方法修复了。这样问题貌似就有两个正确答案。解决办法就是对源代码中相关的 bug 缺陷进行标记，并记录一些关于为何改变以及谁参与决策等更为详细的说明。</p>    <p>47. Blame 功能。这个可爱的小工具能告诉你是谁最后更改的代码。</p>    <p>48. Git bisect 功能。Git 有一个有意思的“bisect”命令，能自动通过你提交的历史进行二进制搜索发现故障。</p>    <p>寻找答案</p>    <p>49. 谷歌搜索。</p>    <p>50. 论坛帖子。</p>    <p>52. 搜索堆栈交流。</p>    <p>53. 创建堆栈问题。</p>    <p>其他</p>    <p>54. 聘请专家。可能在短时间内成本很高。</p>    <p>55. 招实习生。聘请专家的相反方法就是聘请新手。有时候初学者饱满的热情能让他们从不同的角度来解决问题。</p>    <p>56. 改变要求。如果你不能修复缺陷，那么可以改变要求。通过解释各种成本需要，也许能让客户改变他们的初衷。</p>    <p>57. 更改上/下游系统。</p>    <p>58. 循序渐进地学习技术。</p>    <p>59. 通过断点检查配置。更改关键配置值，并确保已经断点，这样能够让我们无所顾忌地设置配置。</p>    <p>60. 系统化。有时候我们需要将三四件事情组合在一起，那么可以将已经试过的组合记录下来，如果需要的话一定要尝试各种的组合。</p>    <p> </p>    <p>来自：http://www.androidchina.net/5535.html</p>    <p> </p>