奋是基础，一切的前提
奋之上是忍耐
大部分时候大部分人的“习惯”都是跟“效率”作对的
奋让你有机会去跟这些习惯做斗争
在 ACM 竞赛的级别，写代码不是在解题，而是实现早已在脑子里准备好的一个逻辑流程。
这个追求跟大部分没有训练过的人的习惯相反，要扭转这种习惯，第一步可以做尝试有：
1. 把准备和敲键盘分割为两个动作。
2. 把敲键盘和运行分割为两个动作。
3. 编译错误这件事情几乎总是会发生，但“尝试”减少编译错误的过程，确实对提高准备
效率很有帮助帮助。
写程序的 准备->写代码->测试 三阶段，普通人之间差距最小的就是第二个阶段。速度都
是在“短到完全不充分或者长得非常没建设性”的准备期，以及“没完没了地冒出计划外
BUG 或者遭受?到不行的 Debug 灾难”的测试期，被拖慢下来的。
如果你是队里的队员，那么以下几点是必须做到的：
1. 敲键盘中的任何时候，如果发呆超过三分钟，说明没准备好，滚下机器去想清楚。
2. 编译器告诉你某个变量没声明，结果你突然发现不知道应该在哪里声明它。这时候同样
说明准备没做好（根本就是对象和逻辑都是乱的），滚下机器去想清楚。
3. 为 ACM 竞赛而写的代码，不需要 DEBUG 模式。
作为一种粗略的判断标准，“一次过 Sample 的概率”是很重要的。好好准备了的程序，
如果经常不能写好立刻过 Sample，那一定是准备方法有问题。
最后再强调一件事情??发现程序有逻辑错，或者干脆算法有遗漏了的情况，别着急打补
丁。一个工作需要一个补丁，就很有概率需要更多的或者更大的补丁，很多时候你遗漏的
不是一个 Case 而是一类情况、一个大的角度，这种情况只有通过重新检查算法逻辑或者
实现逻辑才能扭转过来，拍脑袋打上的补丁只会增加未来差错的负担而已。