设计获胜策略设计获胜策略 一个好的取胜之道是制定在竞赛中指导你行动的策略。无论是在好的情况下还是在坏的情况下，它将帮助你决定你的行动。用这种方法你可以在竞赛中将时间花费在解决编程问题上而不是试图决定下一步该干什么…这有点像预先计算好你面对各种情况的反应。 心理上的准备也很重要。 竞赛中的策略 首先通读所有的题目；草拟出算法，复杂度，数量，数据结构，微妙的细节，… 集体讨论所有可能的算法 —— 然后选择最“笨”但却可行的算法。（注：请注意这一点，对参赛选手来说获奖就是唯一目的） 进行计算！（空间和时间复杂度，并且加上实际期望和最坏情况下的数量） 试图证明该算法错误（？？原文是 Try to break the algorithm）—— 使用特别的（退化的）测试数据。 将问题排序：根据你所需付出的努力，将最“短”（从原文理解是指解决问题费时最短）的问题排在前面。（从“短”到“长”的次序为：以前做过的，容易的，不熟悉的，困难的） 编写程序解决一个问题 —— 对每一道题而言，一次一道题 确定算法 构造特别情况的测试数据 写出数据结构 编写并测试输入子程序（编写额外的子程序来显示数据输入的正确性） 编写并测试输出子程序 逐步细化：通过写注释来刻划程序的逻辑轮廓 一个部分一个部分地填充并调试代码 完成代码使其正常运转，并验证代码的正确性（使用一般情况的测试数据） 试图证明代码错误（？？原文是 Try to break the code）——使用特别情况的测试数据来验证代码正确性 逐渐优化——但足够了即可，并且保存所有的版本（使用困难情况的（即运行时间长的）测试数据来计算出实际运行时间） 时间安排策略和“故障控制”方案 制定一个计划决定在各种（可预测的！）故障发生时的行动；想象你可能遇到的问题并计算出你所希望做出的反应。核心问题是：“你何时花费更多的时间在调试程序上，你何时放弃并继续做下一题？”。考虑以下问题： 你已经花费了多长时间来调试它？ 你可能有什么样的 BUG（BUG 是指程序中的错误）？ 你的算法有错吗？ 你的数据结构需要改变吗？ 你是否对什么地方可能会出错有一些头绪？ 花费较短的时间（20 分钟）在调试上比切换去做其他别的事要好；但是你或许能够在 45 分钟解决另一个问题（？？原文是 A short amount (20 mins) of debugging is better than switching to anything else; but you might be able to solv...
