程序员如何才算真正的高效编程？
我们团队受TechLead提出的高效能程序员的七项技能的启发，提出了一些自己的看法。以下是我们认为高效能程序员的七项技能。
学习如何阅读别人的代码
你总是会觉得，除你以外的每个人编写的代码都很糟糕。
因此，我们认为能够理解别人的代码是一项拥有诸多优势的伟大技能。
无论之前的工程师编写的代码有多么凌乱或考虑不周，你仍然需要读完这些代码。毕竟，这是你的工作。即便有时之前的那位工程师就是一年前的你。
这项技能有两个好处。首先，能够阅读别人的代码是学习设计上的反面教材的绝好机会。在浏览别人的代码时，你可以了解哪些代码有用，哪些无效。更重要的是，你可以了解到对于其他工程师而言，哪些代码容易理解，哪些代码不容易理解。
你需要确保尽可能多地阅读别人的代码。这样，其他工程师才能知道你是一名高级工程师。
你需要确保你提出的问题涉及重要代码的可维护性，并给出有用的评论。这可以彰显你在编程领域的主导地位。
你的代码应该设计得井井有条，因此不需要任何文档。实际上，如果你是一名优秀的程序员，那么你根本不需要给你的代码写任何文档。这只是浪费时间，你需要把时间花在编程和参加会议上。
能够阅读别人凌乱的代码，也方便你在有需要的时候修改代码。有时，你可以利用这种机会补足自己缺乏的经验。例如，我们的脚本曾经从Powershell换成了Python，然后又换成了Perl。我们的Perl经验非常有限，但是我们仍然有足够的背景信息来弄清楚实际的状况，并进行必要的改动。
这一切都因为我们了解所有的代码，以及对Perl脚本的理解。
阅读他人的代码可以提高你自身的价值，因为你甚至能轻易理解那些过度设计的系统。
感知有问题的项目
你需要花时间学习的技术非常多。我们认为值得了解的技能之一，就是了解哪些项目不值得做，哪些项目陷入了步履维艰。
在大公司中，无法完成或不具备影响力的项目往往很多。有些项目可能没有任何业务意义（至少对你而言没有意义），有些项目则有管理不善的问题。这并不是说如果你不赞同项目，就应该断了这种想法。但是，如果利益相关者无法正确解释最终的成果，那么该项目可能就不值得做。
此外，某些项目可能过于关注技术而不是解决方案，因此从一开始就不会产生太大影响。在了解到底什么是有问题的项目之前，首先你需要经历很多有问题的项目。因此，无需花太多时间思考每个项目是否有问题。
等到你的经验积累到一定程度，你就会拥有良好的直觉。
避免会议
无论你是软件工程师还是数据科学家，开会似乎都无可避免，因为你需要与项目经理、最终用户和客户达成共识。然而，会议也有可能突然占据你的所有工作时间，这就是为什么学会如何避免不必要的会议如此重要。
也许我应该使用一个更恰当的词：管理（而不是避免）。你的目标是花费在会议上的时间能够推动决策并帮助团队前进。
最常见的方法是，每天设定两个小时为“不开会”时段——在你的日历上设定为定期会议。通常，大多数人会在他们合适的时间段设定这样的定期会议，并利用这段时间追赶开发工作的进度。
为了保证完成工作，避免开会的另一种方法是早点去公司。就个人而言，我们喜欢早点去公司，因为那时办公室比较安静。大多数早到公司的人都跟你一样，只想着早点完成工作，所以没人会在这时候打扰你。
这对单独工作的人来说很重要，因为我们的工作需要我们集中精力，而且不需要与其他人交谈。有时候，你可能想与他人一起合作解决问题。但在问题得到解决后，你需要回去写代码。只有在个人安静的小角落，你的大脑才能高速运转，不断推进自己的工作。如果你不断停下来，那么就很难重新开始继续向前。
Git
有些计算机科学专业的学生从Git诞生之日就开始使用这个工具了。他们了解每个命令和参数，而且可以像专业人士一样玩转一切。也有人在第一份工作中才开始接触GitHub。对他们来说，Github充满了迷惑的命令和进程。他们无法确定自己究竟在做什么。
无论你们公司使用哪种代码库系统，但凡能够正确使用就很好，如果使用不当则会对系统带来阻碍。一个简单的push或commit并不需要花费很多时间，但有人会被诸多的分支和分叉搞得晕头转向。另外，如果你经常忘记pull最新的代码，那么将来还需要处理合并的冲突——这一点都不好玩。
如果你需要一份Git命令备忘单，那么就去找一份吧。这会减轻你的工作负担。
编写简单又便于维护的代码
年轻工程师往往会设法在一个解决方案中融合他们所知道的所有实现。如果你了解面向对象的编程、数据结构、设计模式和新技术，那么就可以在编写代码的时候能够用到所有这些技术，这只是一种美好的心愿。这种做法会创建不必要的复杂性，因为这很容易在过去使用的解决方案或设计模式的基础上增加难度。
你需要平衡复杂的设计概念和简单的代码。设计模式和面向对象的设计应该可以通过简单的代码实现复杂的模式。然而，随着越来越多的流程被抽象化、封装和黑盒化，调试起来也会越来越困难。
学会说不，划分优先级
无论你是财务分析师还是软件工程师，你都需要学会说不，然后还需要划分工作的优先级。尤其是技术人员，很多人都需要依赖他们。如果你是数据工程师，那么可能还需要承担很多工作，而不仅仅是开发数据流水线。有些团队需要数据提取，有些团队需要仪表板，还有团队需要为数据科学家提供新的流水线。
划分工作的优先级以及说“不”实际上是两种不同的技能，但是二者的关系紧密相关。划分工作的优先级意味着你的时间应该花费在对公司有重大影响的工作上。而有时候说不，也意味着避免处理应该由其他团队处理的工作。对于所有岗位来说，这二者常常有连带关系。
学会说不非常难，因为你无法拒绝别人向你提出的请求。尤其是如果你是刚毕业的大学生。你不希望别人对你感到失望，而且你希望能承担起更多工作。
在大公司中，工作总是无穷无尽。关键在于你如何完成这些工作。
很多技能在面试中不会问及，甚至大学也不会教。通常，这是因为环境的限制，而不是老师不想让学生接触现实世界的问题。
操作设计思维
无论是在大学的学习中，还是在面试中，有一个能力很难考察，那就是仔细考虑最终用户可能会以何种错误的方式使用你的软件。我们通常称其为操作场景的思考。
但是，这只是一种礼貌的说法，其实说到底还是如何让傻瓜也能理解你的代码。
例如，由于许多编程都是维护工作，因此通常意味着更改与其他代码高度纠缠的代码。即使是简单的更改，你也需要彻查对象、方法和/或API调用的所有可能性。否则，就很容意外第破坏你未曾意识到的连接模块。即使你只是修改了数据库中的数据类型。
另外，你需要在开发之前仔细考虑边缘情况，并仔细考虑整个高层设计。
对于开发新模块或微服务等更复杂的情况，你就更加需要花一些时间仔细考虑所构建功能的操作场景。考虑一下未来的用户将如何使用你的新模块，他们可能会采用哪些不正确的方式，可能需要哪些参数，而将来其他程序员可能会通过哪些不同的方式使用你的代码。
编程只是程序员工作的一部分。创建能够在你的计算机上正常运行的软件很容易。然而，部署代码的时候可能会出现很多问题。在投入生产后，又很难说用户会如何使用你的软件，而其他程序员又会如何修改你的代码。经过五年后，将来的程序员可能会因为你如今编写的代码的局限性而感到沮丧。
原文：https://dev.to/seattledataguy/7-habits-of-highly-effective-programmers-inspired-by-an-ex-google-techlead-humor-4b4k
本文为 CSDN 翻译，转载请注明来源出处。
【END】
☞金山云肖江：26 岁拿到博士学位，如今掌舵金山云 AIoT 研发 | 人物志
☞【光说不练假把式】今天说一说Kubernetes 在有赞的实践
☞真·上天！NASA招聘区块链"多功能复合型"人才, 欲保护飞行数据安全……