“成为高效程序员的7个重要习性”

本篇文章8200字，读完约21分钟

作为软件工程师，我希望有稳定的工资，参加好项目的机会，好工作的跳板，或者和其他程序员成为好朋友。 这里的“高效”是指按时完成符合要求的项目的能力。 在经历了很多软件制作业务之后，我相信以下实践有助于你学习“高效”，提高专业性，延长职业寿命，获得个人满足

1 .理解你的控诉

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

尽快开工

尽快完成直观的系统。 这意味着，无论是程序接口还是客户接口，都将首先创建接口，并根据需要生成内部功能的存根代码。 这样，为了方便“顾客”的观看，可以通过运行顾客界面或编写程序界面的代码来发现最初代码中存在的矛盾和遗漏。 甚至在第一次交货之前，也有可能观察到问题和可能改进的地方。

某种经典的想法认为，如果预先设计好所有的东西，剩下的就只有写代码了。 如果你之前做过完全相同的项目，这个说法当然是正确的。 但是，否则，很可能陷入死角。 也就是说，他们只是在推测和执行可疑的假设。

以前，我在一家新的无线互联网公司工作时，我们来了两个月设计要在六个月内发布的无线门户和网关。 结果，我们厌倦了会议，开始写代码。 在前两周，我负责的部分和原设计不一致。 两个月后的第一次无线连接测试发现您完全误解了无线协议。

这并不是说不需要设计。 但是，设计只是某种程度上的预想。 设计应该实际执行和确认，同时早执行总比晚执行好。

即使原始设计充分，如果发现可以调整的地方，也必须对其进行改善。 硬件产品、建筑、大型软件项目等都会受到僵硬的“预制构件”的损害，但软件的情况下，可以在项目初期凝结项目的要求，建立适当的接口。 但是，必须尽快完成这个。

尽早开始有助于塑造你的职业形象。 如果能让你的上司看到一点成果，他会很高兴。 另一方面，提前开工有助于缓解不安。

经常交货

一旦完成了可以使用的东西，就不能只作为“概念实证”保留下来。 让别人试试它，看看它的反应，指导开发过程的优先顺序。 注意人们如何采用你的软件。 这不是替代的方法。 顾客问卷和焦点研究可能会提供一点有用的意见，但是开发者的设计决策和优势可能会被顾客所拖累。 这是一次冒险。

特别是，要尽快向qa工作人员交付软件，频繁提交成果，最好按照预定的时间间隔提交。 让他们测试每天的成果，或者至少每周的成果也是不错的。 这样，qa工作人员就会觉得自己愿意参加项目开发，培养职业责任感，发现问题并报告。 最需要优先考虑的是导致产品故障的问题，例如崩溃和死循环。 只要尽可能涵盖多个方面，熟悉整个产品，就能尽早发现设计问题。

一家小型3d软件企业，我负责从sgi制造的顶级产品移植到windows nt。 6个月后，移植没有完成，反而有崩溃的趋势，我很不情愿地把最初的成果交给了测试小组。 幸运的是，由于漏洞太多，qa经理多次要求我立即处理测试人员无法采用有意义的程序的问题。 自己测试时，应该会忙于看起来更困难、更重要的核心3d问题。 客户界面、加载-保存功能、与计划支持的硬件的兼容性等常见问题可能会被忽略。

程序员经常不愿意早点把代码交给测试人员。 他们不想听已经知道的漏洞测试人员很可能不想测试基本上做不好的东西。 但是测试人员的工作是找出这些问题。 如果程序员想早点看到成果，就应该把bug报告当成好东西。

2 .把工作当真

在尽量接近完成的状态下运行软件。 我不知道什么时候必须演示系统，发送判断备份，或者交货。

采用实际的数据

如果只测试冰山一角的样本数据，程序撞击到实际数据的大冰山时，可能会下沉。

我参加过用于判断先进半导体绝对值的供应链管理产品的开发。 在跨越了交货这个大门槛之后，我们收到了他们输入的第一批实际数据还在解决中的消息。 已经两天了。 我同情主程序员。 在管理者和顾客的催促下，他不得不忙碌地活两个星期。 遇到这件事的人不是我。

采用正式版

请记住，用自己的机器做的东西不是正式的。

在最近的游戏开发项目中，我负责顾客界面。 我陆续从qa那里收到了一些颜色错了的报告。 最后，问题只发生在提供版本上，另一个程序员使用专用的主机调试工具发现了漏洞。 结果，是我两个月前犯的愚蠢错误，没有指定初期的色值。 调试版本总是选择特定的默认值，但提供的版本发生了改变，最终结果不明确。 如果观察频繁运行交货版本，不是失去很多时间，而是很快就会发现问题。

经常合并

把你的代码存入主代码库——拖得越久，这项工作就越累。

我曾与程序员共事，他认为每天出现在数据库中的所有新代码和数据的变化都“麻烦”。 确实，这样一来，所有其他程序员每天都要花一定的时间进行整合，只要看了代码和数据，就可以运行稍微好一点的独立样本了。 但是，每次分阶段交货，我们都要花好几天时间将个别代码重新连接到当前的代码库，有时不得不推迟交货，或者冒着失去整个项目的风险。

把你的代码从正式版本中分离出来，意味着程序员不能判断你的代码，测试者也不能尽早发现漏洞。 你可能不想让别人挑剔代码，但早发现问题总比晚发现好。 所以，我忍住了。

3 .理解你的代码

生活中充满了奇怪的神秘，但你的代码不适合这些神秘。 我不需要知道你的车是怎么工作的——如果发动机发出奇怪的声音，把它交给汽车工程师就行了。 但是，如果换成你的代码，甚至不知道它是怎么工作的，或者是什么错误，谁也不知道。

有自己的创作风格

我小时候的钢琴老师是这样评价我和姐姐哥哥的。 “你姐姐的时间感很强，你哥哥的键盘打得很好。 ”然后他停顿了一下，说:“你还行，还好好努力着呢。”

编程，有些人可以做一些人做不到的事，但另一个人是天才。 虽然我进行了多年的练习，但是钢琴弹得不好； 我那么喜欢打球，但水平一般。 但是，我认为我确实有编程和写作的才能。 请不要惊讶。 我认为好的节目就像好的散文。 散文和代码都是复制品，有语法、句法、拼写和意义。 很多写代码的人和写作的人，只有这些就足够了，但好作家和好程序员也有美。 他们的作品结构和风格都很好，经常可以据此识别作者。

许多windows程序员都很好奇。 为什么坏脾气的老unix/mac/amiga/lisp程序员对win32/mfc/.net不满意，但是如果所有的APP界面都来自微软，就会有更好的东西，从这一点可以看出

复制和粘贴

样式编程的反对是复制和粘贴。 从某个地方复制可能有用的代码，稍微调整一下，合并一下，重复一下，就这样结束了。 你的软件简直是大杂烩。

离开一家企业几个月后，前同事在电子邮件中问我，他复制贴了10页的代码做了算法，为什么不能运行？ 我不知道该怎么回答。 如果不能说明自己的代码应该怎么工作，谁会期待救你呢？

甚至在诊断从示例代码中复制粘贴的代码时也做过困难的事情。 从复制粘贴开始新代码是合理的，但不能因为看起来可以执行就放手。 我必须回去看看是否读了所有的东西，根据目的整理代码。

代码清理

保持你家/公寓/房间干净的最好方法是每天花时间打扫或者至少每周打扫一次。 地址混乱到一定程度再打扫的话，这个麻烦会非常大。 除非雇清洁工。

如果不能奢侈到雇身体每天帮我清理代码的程度，就必须定期检查代码，清理累积的死代码，废弃过时的评论和错误的名字。 否则，你会得到不敢拿出来的代码。 如果你不觉得失去不了人，就可以，你可以。

我指导的程序员总是向我汇报。 她的代码“完成”了。 这是管理者很高兴听到的话，但我很烦躁。 她的代码从来没有完成过——你必须调试它，保持它，改进它，直到它完全没问题。

有问题吗？ 评论？

有人认为编程是工匠的工作，也有人认为编程是工程。 而且，那是考古学。 你发掘代码沉积物，想知道这些奇怪的人造产品是用来做什么的。 为后人着想，留下线索吧。

我问前面提到的程序员是否“完成”了评论。 结果，函数名“getdata”的注释为“gets data”。 这不仅仅是胡说——简直是侮辱。 什么样的数据？ 什么风格？ 从哪里来的？ 请不要再详细讨论服务器不可用或传输中断时会发生什么。

把你的代码做成文档，以防有人随时拿来使用。 用的人可能是你自己。 如果不这样做，请想想必须重新访问代码几次。

和以前的上司合作的时候，他叫我看谁都没时间看的代码。 一开始，我觉得那个不好。 我不知道写了什么。 之后，我慢慢摸索了一下这段代码是干什么的，所以勉强同意了这不是坏事。 最后，我终于明白了这个商品是我两年前写的。 教训:留下很多评论。

写代码时，请记住注释，而不是等待有什么有用的清理短语出现。 给代码加注释，以便能清晰地反映出编写时的想法。 你可以成为自己的创作伙伴。

现在，可以使用javadoc、doxygen等从漂亮的html和源代码注释中生成其他样式化的文件。 理想情况下，你每天晚上做的是doc生成的部分，可以在内部网得到。

观察警告

无视器皿和运行时间的警告会危害你自己。 有“警告”就有理由。

我制作过基于unix的APP。 那个没能成功连接到某些函数上。 在运行时通过重新连接这些函数来处理问题。 6个月后，我们意识到，当我们运行新的清洁版本时，我们已经关闭了提醒未知连接漏洞的警告。 在供应商的斥责下，我们处理了连接问题。 结果，只需重新排列库即可进行连接。

提高器皿的警告等级、注释代码、记录制作和执行时间的警告新闻，优选包含处理警告的标准，以便能够知道是否处理问题或忽略问题。

4 .编程优化

有目的地写代码

复制和粘贴代码的人的另一个极端是为了让代码看起来更漂亮而改变代码。 有编程的审美感是值得称赞的，但是为了觉得漂亮而改变代码是浪费时间(徒劳的冒险)。 看到别人写的代码，改成看起来更漂亮，真的很生气。

我有个很烦人的同事，在看我们的代码库时删除了所有的附加词。 如果他只是清理了入门级员工写的代码，可能谁也不会说什么，但是哪个附加词是我们团队的技术领导写的，他是我们企业最优秀的人物之一。

请不要破坏

虽然“代码重构”现在非常流行，但程序员往往会把代码清理和重新设计作为目标。 这个妙招就是重组代码，不破坏其他东西。 如果你以已经改善的名义破坏已经存在的功能，意味着你的时间比别人的时间高，或者不破坏就不整理代码。

我有一个很讨人嫌的同事。 他决定重新运行我们系统的解析器，结果其他所有人都不知道怎么写代码了。 我把他放回去，发现代码可以编写，但不能执行。 我问他发生了什么事，他说“按你的要求”，他删除了整个解析器。 没有团队精神。

维持代码的执行需要一点耐心和额外的工作。 当你勤奋地恢复你的工作并将函数添加到新代码中时，可能需要暂时保留旧代码和接口。 但是，对所有与此代码库相关的人来说，这是必须的。

找到瓶颈

人们总是谈论“背心”，但这不是正确的词。 我们很少以最好为目标。 相反，我们的目标是通过改善和权衡来达到足够的性能。

在谷歌的电话面试中，我被询问如何在有序的数字组中搜索数字。 很明显，提问的人在问二进制搜索法。 但是，在现实生活中，我可能会做出“错误”的选择。 从头到尾找出来。 如果程序运行充分，花两倍的时间写需要维护和调试的代码，那就没有意义了。 特别是在该代码不是程序瓶颈的情况下(如果该数据是瓶颈部分，你是否会将其直线排列，我非常怀疑)。

如果需要在程序速度和空之间进行优化，则挥舞瓶颈以外的任何部分都只是需要时间。

5 .自我管理

你可能在向你讨厌的上司抱怨很多，但你的抱怨可能没有错。 所以你必须成为自己的管理者。 即使你的上司是好人，他也不会站在你后面告诉你该写什么，怎么写(虽然一定有好几个上司想这么做)。

估计时间

程序员不能提供有用的时间估算是很有名的。 但是，我认为这是无理的谴责。 因为管理层经常做出更坏的预测，而程序员的警告经常被忽视(这可能是全工序的共同灾难)。 但合理的时间估算对按时完成项目很重要。

在一个商业软件项目中，我的一些同事忘记了产品的交货日期。 有人问是否交货，另一个人惊讶地注意到，日子已经过去好几天了。

更糟的是，程序员能提供的时间“只需要几天。 ”。 每次我听到这话，或者自己说这话，我都感到很惭愧。

一家图像软件公司的总裁希望产品支持vrml。 那个时候，那是下一个很大的任务。 包括我们将在两个月内发布的产品在内，都支持vrml。 他(他是对的)可能以为我会拒绝开始新项目，所以他问另一个工程师，“只需要几天。 ”回答说。 两天后，我告诉总经理，我们刚刚浪费了他和我两天的时间。 因为，有200多个更重要的洞。 他认为我的理由很充分。 (后话: vrml不太成功。 ）

另一个程序员完全没有时间估算的概念。 但是，没有必要完全拒绝时间的模糊属性。 只不过是推测，实际上应该不太准确。 如果是有经验的工程师，就已经知道做同样的工作需要多长时间了。 否则，问问有经验的人。

我有一个聪明的朋友，经常被指派开发实验的原型。 他问我:“你怎么估算时间？ ”。 我认为这是反问句，甚至纯粹的研究者也需要估算时间。 有人想付给他们，得到结果。 即使那是多个演示样本或某个时期发表的复制品。

如果你确实不知道要花多长时间，你就不是做这个任务的合适人选。

程序员不愿意约时间是因为他们害怕保证。 确实，这个世界没那么美好。 经理在时间上和你谈判。 同行的竞争对手可能会用严格的安排或不现实的安排来兑换你。 我希望失败。 约定好时间后，就会悲剧。 不要试图得到希望的结果。

一位上司在询问完成时间后说:“你保证吗？ ”我追问道。 但是，当我询问硬件条件和其他相关情况时，我会说“我会尽量”。

我只能说，抓紧时间给出现实的估计。 任何让步都应该取决于实际产品和资源之间的交易。 请根据假设、相关事项、资源制定时间表，并写在某个地方。 这样的话，以后就没必要给没什么力气的记忆添麻烦了。

计划的进度

在你做出决定去哪里之前，你不会跳上车，对吧？ 开车的时候心里可能有路线。 同样，在你开始用电脑写作之前，你应该有点想你今天想完成什么。

因为每天都会遇到分心的事，所以并不能总是完成想完成的事。 与那些把软件工程团队当作自动售货机的人的想法相反，有些任务不是一天就能完成的。 所以想想星期五之前要完成什么。 如果完成了，周末就可以悠闲地度过了。

6 .继续学习

从一个社团足球队的成员那里得知，我们每天都拧着防滑钉练习，但是你们却在问:“c语言编程的秘密是什么？ ”有人问。 如果有这样的秘密，我一定会在晚间电视节目中传播我通过房地产发财的方法。 对不起，没有捷径。 你必须学习，练习，犯错。 不需要依赖团体训练和学校教育。 有多个国立和当地的专业团体，书，当然还有互联网。

编程是一门科学

编程被称为“计算机科学”是有理由的。 不需要正规的计算机科学教育，谁都可以简单地开始编程。 特别是学过其他工程学和理科的人，可以非常快地拿到编程，以此谋生。 但是，为了有效地解决重要任务，必须知道软件的固有功能和限制、识别前提，才能避免无谓的重复工作。 虽然不需要知道所有的事情，但是至少应该能大致了解多个行业，必要时做一点额外的研究。

例如，创建新文件样式的人应该对器皿有一些了解。 是指基本问题、各种短语、大多数指定标记和语法的重要性，而不是像循环展开这样的所有代码生成优化。 今天，很多人默认采用xml。 那是件好事。

但是，在此之前，一般情况下，我只是稍微粗略地写一下复印格式，然后将生成的示例文档作为文件指出来。 之后，再加上写其他解析器的其他人在文档中看到的一些东西，但不是全部。 如果有错误，你可以通过两种方式来推卸责任。 也就是说，网民不行还是作者不好。 无论如何，更受欢迎的产品都会获胜。

我在3d影像领域最不能容忍的事件之一是，太多文件的样式不清楚。 运行3d作品的obj文件解析器会生成明显不同的文件，如每个测试的导出作品的空白色和换行符不同。 对此，我的新手同事利用语法和词法分析器设计了新的游戏交换风格。 (现在，这已经不算什么了。 大多数新的图像文件样式似乎都基于xml。

一个只会将简单的脚本和客户界面结合在一起的程序员，一个能够解决实际问题的程序员，要说它的区别是什么，那就是对算法如何影响问题大小等多而复杂的计算的理解能力。 每个程序员都必须从常识上认识到基本的许多复杂术语和常见问题的许多复杂之处。

我的第一份工作是计算机辅助半导体设计，涉及多个可扩展性问题，包括np-complete问题。 但是，每当看到无法用线性时间应对的问题时，每当看到大部分可能意味着这是线性时间的“线性”算法时，有些工程师就会说:“这是旅行者问题！ ”有些人很兴奋。 (证实了旅行商问题，即tsp是具有重要工程背景的图论中的典型组合优化问题，是np完全问题。 也就是说，如果一个旅行者必须在几个城市做生意，他如何通过最短的路线一次到达这些城市？ ）

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

是的，其实没有免费的啤酒； 但是，现在程序员生活得还不错。 虽然经济衰退和外包业引起了争议。 毕竟，你需要的东西在网上教程、讨论组里，也有免费软件。 你要处理的只是硬件和宽带的问题。

7 .尊重

高效软件工程师的要求之一是认真对待。 你必须受到同事和上司的尊敬。 至少从你的技术能力来看，对自己的工作有主导权，对别人有很大的影响。

愚蠢的问题

真的，这个世界上有很多愚蠢的问题。 问聪明的问题会增加别人的尊敬，但这是一项技术工作。 暴露未处理事情的好问题，让别人看到你深刻的内涵，你敏锐的思维。 要求证明有关技术参数的问题，说明了你浏览和发现问题的能力。

如果不能回答你的问题，请不要再重复问题，因为问题本身可能是错的。 用其他形式提问，越来越有细节和背景。 如果被提问的是你，或者花时间回复初学者问题的是你的话，就像上述那样考虑了，非常感谢。

能与技术支持人员保持良好的关系，这是我为自己感到自豪的事。 但是，我确实记得很久以前的事。 那时，我提出了问题。 “几周前提出的那个问题怎么样了？ “你可以想象别人是多么生气地回答:“你在说什么，你在说什么，同时你在说什么。”

失礼是没有回报的。 特别是要求免费指导和咨询讨论小组的情况。 即使在支持协议的保护下提问，冒犯技术顾问也不利于长时间的合作。

我曾经向臭新人们解释过为什么他们的问题，或者他们从一开始就做错了什么，但是我很累了。 现在，我给你一个早日生效的笨蛋过滤器。 “我想知道的是……”或者干脆无视。

通知所有人你读了文件和谷歌搜索了这个问题。 不必然回复的“rtfm”( rtfm是指去读该死的指导手册。 需要处理新闻和问题时，在向对方求助之前，应该花点时间试着自己寻找需要的东西。 和“谷歌is your friend”表明，你充分学习，什么样的援助者不需要搜索同样的资源。 如果他们期待着为你检索什么样的资源，那就意味着你的时间比他们的钱贵，你在杀害他们的时间。

愚蠢的回答

如果你表现得知道自己在说什么，你肯定知道自己在说什么。 工程师的交流有时不是提供新闻，而是炫耀自己的知识(如果你也能这样做，我向你致敬)。 这在很多情况下对求职面试没有帮助，但面试官实际上是借着“发现你是怎么想的”的招牌，向求职者开空的口子的提问。 当然，如果求职者有自觉的话，也有可能产生意想不到的结果。

一位技术总监给我打电话面试。 他要求我在概述c +的结果堆栈框架的同时口头回答他。 我一步一步地写草稿，每次我给他正确的答案，他都反过来要我说错误的答案，好检查为什么那个选择没用。 我不知道我这么写是表示我有多聪明，或者说他有多聪明。

作为工程师，不能太依赖金钱和长相。 信用才是你的资本。 所以如果你犯了错误，就坦白承认吧。

我有幸和一位老工程师共事，但他从不犯错。 他的java代码在多处理器系统崩溃的时候，本来就有很大的漏洞。 当ui代码用代码指示不支持多线程执行时，他再说一遍只有一个线程。 当我列出代码中的7个线程时，他同意不应该保存这么多线程，最好同时编辑。 但是，他还是老样子写代码。 他没有修正任何漏洞。 他只是用越来越多的代码隐藏漏洞。

最后，是节省时间的建议。 不要被愚蠢的争论所困扰。 愚蠢会传染。