如何提高编写代码的速度

转载自 sunkehappy  http://hi.baidu.com/it_intheway/blog/item/2520f6374bfaa7d1a3cc2be9.html

Loirey (落英) 于 2008年06月26日23:40:42 星期四)

 提到：

奋是基础，一切的前提

奋之上是忍耐

大部分时候大部分人的“习惯”都是跟“效率”作对的

奋让你有机会去跟这些习惯做斗争

在 ACM 竞赛的级别，写代码不是在解题，而是实现早已在脑子里准备好的一个逻辑流程。

这个追求跟大部分没有训练过的人的习惯相反，要扭转这种习惯，第一步可以做尝试有：

1. 把准备和敲键盘分割为两个动作。

2. 把敲键盘和运行分割为两个动作。

3. 编译错误这件事情几乎总是会发生，但“尝试”减少编译错误的过程，确实对提高准备

效率很有帮助帮助。

写程序的 准备->写代码->测试 三阶段，普通人之间差距最小的就是第二个阶段。速度都

是在“短到完全不充分或者长得非常没建设性”的准备期，以及“没完没了地冒出计划外

 BUG 或者遭受囧到不行的 Debug 灾难”的测试期，被拖慢下来的。

如果你是队里的队员，那么以下几点是必须做到的：

1. 敲键盘中的任何时候，如果发呆超过三分钟，说明没准备好，滚下机器去想清楚。

2. 编译器告诉你某个变量没声明，结果你突然发现不知道应该在哪里声明它。这时候同样

说明准备没做好（根本就是对象和逻辑都是乱的），滚下机器去想清楚。

3. 为 ACM 竞赛而写的代码，不需要 DEBUG 模式。

作为一种粗略的判断标准，“一次过 Sample 的概率”是很重要的。好好准备了的程序，

如果经常不能写好立刻过 Sample，那一定是准备方法有问题。

最后再强调一件事情——发现程序有逻辑错，或者干脆算法有遗漏了的情况，别着急打补

丁。一个工作需要一个补丁，就很有概率需要更多的或者更大的补丁，很多时候你遗漏的

不是一个 Case 而是一类情况、一个大的角度，这种情况只有通过重新检查算法逻辑或者

实现逻辑才能扭转过来，拍脑袋打上的补丁只会增加未来差错的负担而已。