对照检查高效程序员几乎都有这七项技能

　　图片来源：pexels。comanastasiyagepp654466
　　软件工程师们总是花费许多时间磨练面试技巧，如练习力扣题（leetcode）和完善各自的简历。而一旦他们在一家新创企业、谷歌、亚马逊、或其他公司得到了工作，也许就会发现，其实日常工作中用不到当初为了得到这份工作所获得的技能。
　　谷歌的TechLead提出了高效程序员该有的七项技能。本文受到启发，提出高效程序员该有的七项技能。
　　1。学习如何阅读别人的代码
　　能够阅读其他人的代码是一个很厉害的技能，且能带来许多好处。
　　不管上一个工程师的代码有多乱有多糟，你还是得读懂它。这毕竟是你的工作。就算那些烂代码是你一年前写的。
　　这个技能有两个好处。第一，学会如何阅读其他人的代码可帮助你更了解什么是糟糕的设计。在看过其他人的代码时，可以学会看出代码可不可用。更重要的是，也可从中得知哪些代码更易被其他工程师理解或否。
　　在阅读其他人的代码时，尽可能地对其评价。这样，其他工程师才会知道眼前的工程师多么的不简单。
　　作出评价时，记得提起可维护代码和清楚注释的重要性。这将给编程领域里的优势加分。
　　你本身的代码应该设计得好，好到无需注释。事实上，一个优秀的程序员本就不应该给自己代码进行注释。那只是在浪费时间，而宝贵的时间应该用在编码和开会上。
　　学会阅读其他人杂乱的代码也有助于必要时对其进行更新。这有时意味着更新你可能不那么熟悉的代码。举个例子，我们曾沿着一个脚本语言，编程语言从PowerShell换到Python，再改成Perl。虽然我们对Perl的经验有限，但是任然有足够的上下文来搞懂其中的代码，并做出所需的更改。
　　这都归功于我们对所有代码有一定的认识，以及阅读Perl脚本的能力。
　　阅读别人代码这个技能可提升个人价值，因为就算是别人望而却步的过度工程化的系统也难不倒你。
　　2。感知烂项目
　　图片来源：ChrisRied，Unsplash
　　许多技能都需花费时间来学习。其中一项技能是值得去获取的，那就是知道哪些项目不值得去做，哪些项目显然注定死路一条。
　　大企业总是有很多进行中的项目，而其中可完成或有作用的却不多。有些项目也许没有任何商业意义（至少对你来说），也有一些项目就是没管理好。这并不意味着当你对某个项目有异议时就直接拒绝。但是，如果股东们无法清楚解释项目用途时，那这个项目很可能不值得去做。
　　此外，一些项目也许过于专注在技术方面而忽略了寻找解决方案。因此，从一开始就可显然看出不会有太大的作用。只有在接触过很多烂项目后，方能得到感知它们的技能。所以刚开始时不需要花太多时间去识别每个项目。
　　在你职业生涯的某个阶段，自然就会练就一种直觉。
　　3。避开会议
　　无论软件工程师还是数据科学家，都必须参与会议，以确保能与项目经理、终端用户和客户达成共识。然而，参与太多会议反而会占据一整天的工作时间。所以学会避免不必要参与的会议是很重要的。或者，管理一词比避免会更好听一些。这里的目标是确保时间能用于参与推动决策的会议上，并且能帮助团队前进。
　　最常见的方法就是每天留出两个小时的时间，用来进行定期开会。通常多数人会在他们最方便的时候安排例常会议。这段时间便可用来了解所负责开发项目的最新情况。
　　另一种为了完成工作而避开会议的方法就是比其他人早报到。笔者们认为，我们喜欢早到的原因是因为，总的来说，办公室会比较清静。多数早到的人也一样，都想把工作做完，这样就不会有人打扰了。
　　这对独自工作者来说很重要，因为我们的工作有一段时间需要极度专注，而不和其他人交谈。当然，有些时候也许得和别人合作来解决问题。但是一旦越过了障碍，剩下的只需编程。这时候就得进入状态，在脑中不断地思考有关手上项目的种种复杂想法。如果不停地被打断，那就很难恢复状态。
　　4。Github
　　有些计算机科学专业的学生从出生那天起就开始使用GitHub。他们能够理解每一个指令和参数，能力甚至超越了教授们。
　　其他人则是在第一份工作后第一次接触到GitHub。对他们来说，GitHub是个充满令人困惑的指令和程序的地狱。他们从不100确定自己在做什么（这也就是为什么cheatsheet如此的受欢迎）。
　　不管公司用的是哪种存储库系统，该系统只有在正确使用时才有用；反之，则会成为阻碍。一个简单的push或者commit，和花数小时尝试梳理乱成一团的分支，其实只有一线之差。除此之外，如果经常忘记提取存储库的最新版本，那也将面临处理合并冲突的难题。
　　如果有需要保存GitHub的指令cheatsheet，那就保存起来。只要有帮助即可。
　　5。编写简单且可维护的代码
　　通常出现于资历较浅工程师的一个问题就是，他们总试图将所有所知的东西放到一个解决方案中。他们有一种渴望，想把所学到的面向对象编程、数据结构、设计模式和新技术统统用于所编写的每一段代码中。这反而形成了不必要的复杂性，因为你很容易过度依赖过去使用的解决方案或设计模式。
　　复杂的设计概念和简单的代码之间存在着一种平衡。整体上来说，设计模式和面向对象的设计应该将代码简化。然而，当一个程序越被抽象化、概括化、和黑箱化，则越难侦错。
　　6。懂得拒绝，学会分轻重缓急
　　这个技巧其实适用于任何职位，无论金融分析师还是软件工程师。但尤其值得一提的是，每个人似乎都会因为某种原因找技术性人员。如果你是数据工程师，处理开发管道外还可能会被要求做其他东西。一些团队也许需要数据提取，其他则需要控制面板，更有一些需要新管道给他们的数据科学家。
　　其实，分轻重缓急和拒绝可能是两种不同的技能，但他们是紧密交织在一起的。前者意味着只把时间花在对公司有重大影响的事情上。后者则意味着避免处理本应属于其他团队的工作。这两个技能的需求在所有职位中都是相互存在的。
　　这是一项很难掌握的技能，因为有时候面对别人请求的时候，会很难拒绝他们。尤其是刚毕业的大学生，都会想尽量满足所有人，手上也都是可完成的工作量。
　　在大企业里，总是会有穷无止尽的工作要完成。关键在于扛下可完成的任务。
　　事实上很多技能都没有在面试测试到，甚至在大学里也没有教过。通常，这更多是环境的限制，而不是没意愿让学生接触真实开发环境下存在的问题。
　　7。操作性设计思维
　　有一项技能，面试中难以测试，大学课程里又难以复制的，就是想透终端用户使用软件时会出错的地方。我们通常将此称为操作性场景思考。
　　然而，这其实只是一个较好听的说法。事实上你只是在确保你的代码连白痴也可以使用。
　　例如，既然编码大多都是在进行维护，这通常代表改编互相极度缠结的代码。就连一个简单的调整，都需要追踪对象、方法、和或API的所有可能关联。否则，很容易意外地破坏之前没注意到附加着的模块。就算只是更改数据库中的数据类型也是。
　　这也包括在进入开发阶段前想透边角案例和整体的高层设计。
　　而对于开发新模块或微服务的更复杂案例，重要的是花点时间思考一下你手中任务的操作性场景。想一想未来用户将如何需要用到你的新模块，他们将如何错误使用，什么参数将被需要，以及是否有其他时候未来程序员将会用到你的代码。
　　纯粹的代码和编程只是问题的一部分。创造一个可以在你电脑完好运行的软件并不难。但利用代码时可以出错的地方却很多。一旦投入生产，就很难说代码将如何被使用，以及其他代码中哪些将会附加到原始代码中。五年后，一个未来的程序员也许会因为你代码的限制而感到烦躁也说不定呢。