基本准则1.先写代码，一定不能有缺陷。修复它的最好方法是让bug死掉。良好的单元测试强制执行数据库约束使用输入验证框架避免未实现的“else”条件知道如何在应用到主程序之前单独使用log2.print语句。通常一两行额外的输出将有助于隔离问题。3.切换到详细日志记录。详细的日志记录有助于发现更多线索。4.搜索日志。如果日志过多，可以通过关键词或者错误码来搜索日志文件。5.打开自动换行和关闭自动换行。控制日志的自动换行也很有用。6.搜索不同的日志。主服务器的日志可能不是唯一有用的日志。7.Windows事件日志。日志文件的另一个来源可能是操作系统本身。8.进行有用的日志记录。有时，如果您没有获得任何有用的日志记录，那么您可能需要编写自己的日志记录。与他人交谈9.问可能知道问题答案的人。10.问一些“愚蠢”的问题。您可能认为这些问题很愚蠢，但事实并非如此。11.向队友解释问题。他们可能知道答案或能够提出您未曾想到的建议。12.向你的狗解释问题。跟谁说话并不重要，但它可以让你从不同的角度分析问题。写作13.描述问题。用最精确和精确的术语描述问题可以帮助您考虑可能的解决方案。14.问题日记。创建一个文本文件来记录已尝试过的各种方法，包括代码片段、配置设置和导致的任何错误。15.记录问题和解决方案。有没有这样的情况，突然看到一个熟悉的问题，只记得要解决却忘了怎么解决？问题和解决方案可以记录到易于搜索的位置，例如wiki、错误跟踪器，甚至可以通过电子邮件发送给您自己。支持16.阅读常见问题解答。17.提交支持请求。如果有可用的产品/库支持，则使用它。18.在你点击发送之前，三思而后行。写支持请求可以让你重新思考问题，有时当你点击发送按钮时，你会突然想到解决问题的方法或新的线索。19.其他支持。可以直接与开发者面对面交流，最好是实时聊天/SKYPE/屏幕共享。远离键盘20.去散散步。21.小睡一会儿。22.重置优先级。暂时离开键盘的另一个好处是，它可以让你重新评估问题的重要性，也许它只是一个CSS/layout问题，根本不值得你花16个小时。总而言之，有效地分配和使用时间。23.暂时搁置这个问题。如果解决不了，可以把这个问题搁置。可能几天后，你在看相关题目的时候，突然心惊肉跳，解题的关键就来了。隔离24.确定它是哪一行代码。首先确定是哪一行代码导致了问题，以便您可以插入打印语句。25.将问题拆分成一个单独的程序。有时对于库和产品问题，我们可以将其相关代码从主程序中分离出来。这可能需要一些时间，但处理一个孤立的程序通常比处理整个项目构建过程更容易。然后，在解决这个单独程序的基础上，将其与主程序进行比较。更改代码即使您根本不知道如何解决问题，更改代码也是一种非常有效的解决方案。26.编写新的单元测试。27.重构。有问题的代码往往有点凌乱，一些简单的重构，如重命名变量或扩展嵌套的if/then/else块可以使代码整洁。28.发现错误。清理代码的另一种方法是查阅相关代码的“FindBugs”报告。我们之所以首先清理代码，是因为它既简单又经济，可以让我们的大脑专注于代码。29.重写。转储所有相关代码并从头开始重写。一个全新的视角可能会让你完全回避这个问题。30.为一些不必要的代码添加注释——或者至少你认为是不必要的。然后你会发现，也许这些代码流并不像你曾经想的那么“不必要”。31.实验。如果您不确定底层产品或库是如何工作的，一些小实验，尤其是围绕边界条件的实验，可能会很有帮助。32.回到干净的状态。如果您对代码进行了各种更改，或者弄乱了许多配置设置，那么定期恢复到干净状态很重要。否则，实验结果可能会影响正确答案，使你永远找不到正确的解法。33.开关技术。产品34.升级到更高版本。也许您正在处理的问题已经解决，请先尝试升级到另一个版本。35.降级到以前的版本。也许问题恰恰是由于与您当前使用的其他产品/库不兼容造成的。36.打补丁。37.下载并安装源代码。文档38。阅读手册。大多数开发人员可能会认为这是一种低概率策略，但是，嘿，你永远不知道，也许答案就在文档中。39.阅读手册的正确版本。40.说明书是否正确？有时候代码已经更新了，但是手册还没有。调试器41.了解键盘快捷键。42.倒着走。这是调试器的一项功能，可让您在代码中后退一步。43.编写断点代码。44.异常中断。调试器的一个非常有用的功能是能够在任何地方捕获特定异常。45.专业的调试工具。例如：PlumbrAppDynamicsChrononWiresharkHTTP分析器：Fiddler2、Charles、LiveHttpHeadersSourceCodeControl46。编号并标记错误缺陷。你有没有遇到过这样的问题，有些东西是用一种方法修复的，几周后它变成了一个错误，而其他人用另一种方法修复了它。这个问题似乎有两个正确答案。解决方案是标记源代码中的相关错误，并记录一些更详细的说明，说明为何进行更改以及谁参与了决策。47.责备功能。这个可爱的小工具可以告诉你谁***改了代码。48.Git平分函数。Git有一个有趣的“二分法”命令，它会自动对您的提交历史执行二进制搜索以查找错误。找到答案49。谷歌搜索。50.论坛帖子。52.搜索堆栈交换。53.创建堆栈问题。其他54.聘请专家。在短时间内可能会很昂贵。55.招聘实习生。聘请专家的反面是聘请新手。有时初学者的热情可以使他们从不同的角度处理问题。56.变更要求。如果您无法修复缺陷，则可以更改需求。通过解释各种成本需求，有可能让客户改变主意。57.改变上游/下游系统。58.循序渐进地学习技术。59.检查带有断点的配置。更改关键配置值并确保我们有断点可以让我们无后顾之忧地设置配置。60.系统化。有时候我们需要组合三四个东西，那么我们可以把尝试过的组合记录下来，必要时可以尝试各种组合。
