系统程序员怎样把代码写得又快又好？

很多初学者包括一些有经验的程序员，在敲完代码的最后一个字符后，马上开始编译和运行，迫不急待的想看到自己的工作成果。快速反馈有助于满足自己的成就感，但是同时也会带来一些问题：

让编译器帮你检查语法错误可以省些时间，但程序员往往太专注这些错误了，以为改完这些错误就万事大吉了。其实不然，很多错误编译器是发现不了的，像内存错误和线程死锁等等，这些错误可能逃过简单的测试而遗留在代码中，直到集成测试或者软件发布之后才暴露出来，那时就要花更大代价去修改它们了。

修改完编译错误之后就是运行程序了，运行起来有错误，就轮到调试器上场了。花了不少时间去调试，发现无非是些低级错误，或许你会自责自己粗心大意，但是下次可能还是犯同样的错误。更严重的是这种debug&fix的方法，往往是头痛医头脚痛医脚，导致低质量的软件。

让编译器帮你检查语法错误，让调试器帮你查BUG，这是天经地义的事，但这确实是又慢又烂的方法。就像你要到离家东边1000米的地方开会，结果你往西边走，又是坐车又是搭飞机，花了一周时间，也绕着地球转了一周，终于到了会议室，你还大发感慨说，现代的交通工具真是发达啊。其实你往东走，走路也只要十多分钟就到了。不管你的调试技巧有多高，都不如一次性写好更高效。

下面是我在阅读自己代码时的一些方法：

检查常见错误

第一遍阅读时主要关注语法错误、代码排版和命名规则等等问题，只要看不顺眼就修改它们。读完之后，你的代码很少有低级错误，看起来也比较干净清爽。第二遍重点关注常见编程错误，比如内存泄露和可能的越界访问，变量没有初始化，函数忘记返回值等等，在后面的章节中，我会介绍这些常见错误，避免这些错误可以为你省大量的时间。如果有时间，在测试完成之后，还可以考虑是否有更好的实现方法，甚至尝试重新去实现它们。说了读者可能不相信，在学习编程的前几年，我经常重写整个模块，只我觉得能做得更好，能验证我的一些想法，或提高我的编程能力，即使连续几天加班到晚上十一点，我也要重写它们。

模拟计算机执行

常见错误是比较死的东西，按照检查列表一条一条的做就行了。有些逻辑通常不是这么直观的，这时可以自己模拟计算机去执行，假想你自己是计算机，读入这些代码时你会怎么处理。北大青鸟认为这种方法能有效的完善我们的思路，考虑不同的输入数据，各种边界值，这能帮助我们想到一些没有处理的情况，让程序的逻辑更严谨。

总结了几条提高效率的要点

第一，要学会时间管理

一天就24小时，总要吃饭睡觉，用于工作的时间总是有限的，如何提高效率就变得十分重要了。

时间管理的关键是要事第一原则。在时间管理矩阵中，按照重要性和紧急性可以把事情分为四类：重要紧急、重要不紧急、不紧急重要、不紧急不重要。大量的时间应该花在那些重要不紧急的事情上，因为只有这样紧急的事情才会不断减少。

第二，要学会授权

学会工作授权不仅仅是leader要做的，普通的一线程序员也要有这个意识，否则会被大量紧急不重要或者不紧急也不重要的事情缠身，效率也不可能高。

很多新当上leader的程序员不敢放手，很多事情压倒自己身上，造成了过重的负担，要知道leader需要在自己的职责范围内提升整体效率，而非忙于处理各种杂事；

对于一线程序员，也会遇到很多的不重要的杂事，比如一会儿产品问你个事情，一会儿项目问你个事情，或者让你参加一些不必要的会议，一定要明确职责范围，该拒绝的拒绝，让他们去找职责范围内的人去处理。

千万不要当老好人，烂好人。

第三，动手前要明确需求和项目细节

程序员作为实现需求的一方，需要在需求方（不管是产品还是运营还是老板）传达需求的时候充分理解需求，遇到需求不明确的一定要让对方先明确了，有了明确的需求文档了再开发。

相信大家都遇到过不靠谱的产品或者运营或者项目经理，如果不在实际开发之前都明确了需求，理顺了，后面再返工的话，这样浪费了很多时间，效率必定低下。

你可以说是因为需求方不靠谱导致的，但是如果程序员本身有这个意识，会避免很多的风险。

另外，在开发过程中遇到了不明确的地方，感觉有风险的地方，要及时跟相关人反馈沟通，不要拖延。

第四，不重复造轮子

不重复造轮子 这个道理程序员应该都懂，为了快速完成需求已有的功能可以拿来封装和复用，不必重新进行开发。

其实真正能够造轮子的人还是少得可怜，能够把成熟的轮子使用的非常熟练并且在这个基础上能够做到精准的定制就非常不错了，毕竟日常工作中还是应用层面居多。

---