高效程序员的7个重要习惯

1.理解你的需求

成为高效程序员的第一步是，保证时间的合理分配。没有什么比将时间花在完全没有前途的工作上更浪费的了。

尽快开工

尽快完成一个直观的系统。这意味着先创建界面，无论是程序界面还是用户界面，然后生成内部功能的存根代码（如果有必要的话）。这么做便于“客户”查看，通过执行用户界面或编写程序界面的代码，可以发现最初代码存在的矛盾或遗漏。甚至在第一次交付以前，你有可能会注意到问题或可改进的地方。

有一个经典观念认为，如果你提前设计好所有东西，那么之后你要做的就只剩写代码了。如果你之前做过完全相同的项目，那么这个说法当然正确。但如果不是，你很可能会陷入死角，也就是你只是在猜想或执行一个可疑的假设。

这不是说设计是没必要的。但在一定程度上，设计只是一种猜想。设计应该通实执行来确认，并且早执行总是比晚执行好。

即使原始设计是充分的，只要你发现可以调整的地方，你就要改进它。硬件产品、建筑和大型软件项目等会受到僵死的“预制”的损害，但对于软件，你可以在项目早期提炼项目要求，然后制作适合的界面。但是，这必须尽早完成。

尽早开工有利于树立你的职业形象。如果能向你的老板展示一些成果，他会很高兴的。另一方面，提早开工有助于缓解焦虑。

经常交付

一旦你完成一些可用的东西了，不要只是把它留作“概念实证”。要让其他人试执行它、看看他们的反应，然后让它指导开发过程的优先次序。观察人们如何使用你的软件，这是无可代替的方法。客户问卷调查和焦点研究可能会提供一些有用的意见，但有可能会让开发者的设计决定和特点被客户牵着鼻子走，这是一种冒险。

特别是要尽快将软件交付QA人员，经常提交成果，最好是按预定的时间间隔。让他们测试每天的成果，或至少是每周的成果也是好的。这会让QA人员觉得自己全程参与项目开发，从而培养职业责任感，更乐意发现和报告问题。最需要优先解决的是导致产品失效的问题，如崩溃或死循环——让问题尽可能涵盖多方面，熟悉整个产品，这样才有可能提早发现设计问题。

程序师常常不想过早将代码交付测试人员——他们不想听到自己已经知道的漏洞；而测试人员极有可能不想测试基本上行不通的东西。但测试人员的工作就是找到这些问题。如果程序师想尽快看到成果的话，应该把漏洞报告当成好东西。

2.把工作当真

将软件放在尽可能接近完工的状态下运行。你永远不知道你什么时候得演示系统、发送评估备份或甚至交付。

使用真实数据

如果你只用作为着冰山一角的样本数据作测试，那么，你的程序可能一撞上真实数据的大冰山就沉了。

使用正式版本

记住，用你自己的机器创建的东西不是正式的。

调试版本总是选择特定的默认值，但是交付版本会更改，最终结果是不太确定的。如果我注意经常地运行交付版本，我会立刻发现问题的，而不是损失大量的时间。

经常合并

及时将你的代码并入主代码库中——你拖得越久，这项工作就越累。

我曾与一名程序师共事，他觉得每天数据库中出现的所有新代码和数据变化都“很麻烦”。确实，这让所有其他程序师每天都要花一定时间合并，他才能够只扫视一下代码和数据就开始运行一些不错的独立样本。但每一次阶段性交付时，我们都要花好几天再次把单独的代码接到当前的代码库中，有时候甚至得拖延交付或冒着损失整个项目的风险。

将你的代码与正式版本分开意味着程序师不能评估你的代码，以及测试员不能尽早发现漏洞。可能你并不想其他人挑剔你的代码，但早发现问题总是比晚发现好的——所以，忍了罢。

3.理解你的代码

生活中充满了奇妙的神秘，但你的代码可不适合出现这些神秘。你不必知道你的车怎么工作的——如果引擎发出奇怪的声音，把它交给汽车技师就好了。但换成是你的代码，如果连你都不知道它是怎么运行的或出了什么错，那就没人知道了。

有自己的编写风格

编程是一种有些人能做有些人不能做的事，但还有一些人则是天才。我认为好程序就像好散文。散文和代码都是文本，有语法、句法、拼写和语义。对于大多数写代码的人和写作的人，有这些就够了，但好作家和好程序师还要有一种美感，他们的作品在结构和风格上是有特点的，往往能借此识别出作者。

许多Windows程序师都感到好奇：为什么坏脾气的老Unix/Mac/Amiga/Lisp程序师对Win32/MFC/.NET很不满，但如果所有应用界面都来自Microsoft，你可能就不知道还有什么东西是更好的。

复制粘贴

风格化编程的反面是复制粘贴。从什么地方复制一些可能有用的代码，稍作调整，合并，重复，然后就大功告成了。你的软件简直就是大杂烩。

我甚至在诊断自己从样本代码复制粘贴过来的代码时也犯过难。从复制粘贴开始新代码是合情理的，但你不能因为看起来能运行就放手不管了——你得返回去看看你是否读懂了每一条，根据自己的目的理清代码。

清理代码

保持你的房子/公寓/房间整洁的最好办法就是每天花一点时间清理它，或至少每周清理一次吧。如果等到住所乱到一定程度才打扫，那么这麻烦就非常大了。除非你雇个清洁工。

假设你没办法奢侈到雇一个人每天帮你清理代码的程度，那么你就应该定时地检查你的代码、清理累积的死代码、淘汰过时的注释和错误的名称，否则你必定会得到一份不敢拿出来见人的代码。如果你不觉得丢不起人，好吧，你行。

你得调试它、维护它、改进它，直到它彻底没问题。

问题？注释？

有些人认为编程是一门手艺活，也有些人认为编程是一项工程。更经常的是，它是一门考古学。你挖掘代码的沉积物，想知道这些奇怪的人工产品是用来干什么的。为后来人着想一下，留点线索吧。

将你的代码做成文档，以防有人随时要拿来用。可能要用的人就是你本人——想想如果不这么做，你得重新访问代码多少次啊？

当你写代码时，记得注释，而不是等着出现什么方便的清理短语——注释你的代码，让它甚至可以清楚地反映你在编写时的想法。你可以成为自己的编写伙伴。

现在你可以用javadoc和doxygen等生成漂亮的HTML或来自源代码注释的其他格式化的文件。理想的情况是，你每天晚上做的就是doc生成的部分，可以通过你的内联网获得。

注意警告

无视编辑器和运行时间警告会害到你自己。有“警告”就有原因。

我曾做过一个基于Unix的应用，它不能成功地连接某些函数。我们通过在运行时再次连接这些函数解决问题。六个月后，当我们执行一个干净的新版本时，我们才发现原来我们关掉了能提醒我们未知连接漏洞的警告。在供应商的斥责下，我们将连接问题解决了。但结果是，原来我们只要通过重新排列库就能连接上了。

提高编辑器的警告水平，注释代码以及记录创建和运行时间的警告信息，最好包括解决警告的标准，这样你就会知道是否解决问题或忽略问题。

4.优化编程

带着目的写代码

复制粘贴代码的人的另一个极端是，只是为了让代码看起来更漂亮（至少对他们而言）而改变代码。虽然有编程审美感是值得赞扬的，但改变代码以便让你觉得漂亮只是浪费时间（无用的冒险）。浏览并改变别人写的代码，让它看起来更漂亮，真是让人生气。

不要搞破坏

“代码重构”现在十分流行，但程序员往往以为它是指代码清理或重新设计。这个技巧是指重新组织代码，同时不破坏其他东西。如果你以改进的名义破坏已经存在的功能，那么你的意思就是：要么你的时间比其他人的时间金贵，要么你不破坏就不会整代码。

保持代码运行需要一些耐心和额外的工作——你勤奋地回归测试你的工作，在将函数添加到新代码中时，你可能需要暂时留住老代码和界面。但对于所有与这个代码库有关的人来说，这是必须做的。

找到瓶颈

人们总是谈论“最佳”，但这不是一个正确的词。我们极少将最佳作为目标——相反的，我们的目标是改进和权衡以达到足够好的表现。

如果程序表现足够好了，还花两倍的时间写两倍的、必须维护和调试的代码，那是毫无意义的，特别是如果那段代码并非程序的瓶颈（我严重怀疑如果那个数据是瓶颈部分，你居然还会将它线性排列）。

如果你确实需要在程序的速度或空间方面达到最佳，折腾除了瓶颈以外的其他任何部分都只是浪费时间。

5.自我管理

你可能对你那位讨厌的老板有各种抱怨，你的抱怨可能没错。所以你得成为你自己的管理者。即使你的老板人不错，他也不会站在你背后告诉你该写什么、怎么写才会快（尽管我肯定许多老板恨不得这么做）。

估计时间

程序师不能提供有用的时间估计，这是出了名的。但我认为这是无理指责，因为管理层往往作出更差的预测，并且程序员的警告往往被无视（这可能是所有工程的共同灾难）。但是，合理的时间估计对于按时完成项目仍然是关键的。

如果你是一名有经验的工程师，你就知道你以前做类似的工作需要多长时间，如果你不是，那你就问问有经验的人。

如果你确实估计不准需要多少时间，那么你就不是做这项任务的合适人选。

有时候程序师不情愿承诺时间是因为他们害怕保证。确实，这个世界没那么美好，经理会在时间上跟你讨价还价，竞争对手可能用严苛或不切实际的安排来挤兑你，希望你失败。在你承诺时间后，你就悲剧了，你别想得到任何你希望的结果。

我能说的只有，抓紧时间以及给出现实估计。任何让步都应该根据实际的介于产品和资源之间的交易。要根据假设、相关事宜和资源做时间安排，找个地方写下来，这样以后你就不用麻烦你不太给力的记性了。

计划进度

在决定上哪去以前，你不会跳上车的，对吧？你在开车时心里可能就有路线了。相同地，在你开始用电脑写以前，你应该知道你今天想完成什么，有一些想法了。

每天都会遇到分心的事，所以你不可能总是完成你想完成的事。与那些将软件工程团队当作自动贩卖机的人的想法相反的是，有些任务不是一天就能完成的。所以想想你到周五要完成什么，如果你完成了，那么周末你就可以好好过了。

6.不断学习

“C语言编程的秘密是什么？”对不起，没有捷径——你必须学习、练习和犯错。你不一定得依靠团体训练或学校教育——有许多国立的和当地的专业团体、书籍，当然还有网络。

编程是科学

编程被称作“计算机科学”是有原因的。无需正规的计算机科学教育，任何人都可以轻易地开始编程（可能太容易了）。特别是，那些学过其他工程和理科的人，可以非常快地上手编程，然后以此谋生。但对于高效地处理重大任务，你必须知道软件的固有功能和限制、识别前提，这样你才不会白费力气地做重复的工作。你不必知道所有事，但你应该至少粗略地了解许多领域，必要时能做一些额外的研究。

只会将简单的脚本和用户界面放在一起的程序员和可以处理实际问题的程序员，如果说这二者有什么区别的话，那就是对复杂计算的理解能力，如算法怎么影响问题的大小。每一位程序员都应该知道基本的复杂性术语和对常见问题的复杂程度有常识性认识。

免费啤酒、自由讨论、免费软件

好吧，其实没有免费啤酒；但现在程序员过得还不错（尽管经济衰退和外包业惹争议）——毕竟你需要的东西网上教程、讨论组上都有，还有免费软件可以用。你要解决的只有硬件和宽带问题。

7.尊重

高效软件工程师的要求之一是，被认真对待。你必须得到你的同事和老板的尊重，至少出于你的技术能力、对自己的工作有主导权、对他人有一定影响力。

愚蠢问题

真的，这个世界上存在许多愚蠢的问题。提出一个聪明的问题会增加别人对你的尊重，但这是一项技术活。一个揭露未解决的事的好问题会让别人看到你深刻的内涵，你敏锐的思维。要求说明关于技术参数的问题，显示了你阅读和发现问题的能力。

如果你的问题没有得到答案，可能是问题本身有误，所以不要再重复发问了。换一种方式提问，带上更多细节或背景。如果被提问的是你或花时间回复新手问题的是你，你会感谢上述考虑的。

能与技术支持人员保持良好关系，这是让我对自己都感到骄傲的事。

粗鲁无礼是没有回报的，特别是如果你是要求免费指导或咨询讨论组。即使你是在支持协议的保护之下发问，激怒了你的技术顾问对长期合作也会很不利。

让所有人知道你读了文件和谷歌搜索了该问题。除了避免回复必然的“RTFM”（游戏邦注：RTFM意为：去读该死的指导手册。当你需要信息或者解决问题时，在请求对方帮助之前，应该花一些时间尝试自己去寻找需要的东西。）和“Google is your friend”，都显示了你做足了功课，那些帮助的人不必搜索相同的资源。如果你确实指望他们为你搜索那些资源，那你的意思就是，你的时间比他们的金贵，你在谋杀他们的时间。

白痴答案

如果你要表现得你知道自己在说什么，那么你确实应该知道你到底在说什么。工程师的交流有时候更多地是炫耀自己的知识而不是提供信息（如果你也能这么做，那我向你致敬）。这往往无益于求职面试，面试官其实是假借“发现你是怎么想的”的幌子，向求职者抛出空洞的问题。当然，如果求职者有一点自知之明的话，也可能产生出乎意料的结果。

作为一名工程师，信誉才是你的资本。所以如果你犯错了，就坦率承认吧。

最后，一个节省时间的建议：不要纠结于愚蠢的争论。愚蠢是会传染的。