高效程序员的7个习惯——来自一位前谷歌技术主管

软件工程师花费大量时间通过练习解决代码问题和完善简历来获得面试技巧。

一旦他们最终在一家初创公司、谷歌、亚马逊或其他公司找到了那份工作，他们可能会发现，他们获得这份工作所需的技能与他们日常工作所需的技能并不匹配。

我们的团队受到了一位前谷歌技术主管创造的七个高效程序员技能的启发。我们想就这个话题发表我们自己的看法。下面是关于高效程序员的七种技巧。

学习如何阅读别人的代码

除了你，所有人的代码都很糟糕。

这就是为什么一项具有多重好处的伟大技能是能够遵循他人的代码。

不管以前的工程师的代码有多混乱或考虑得多么糟糕，您仍然需要能够仔细阅读它。毕竟，这是你的工作。甚至在一年前那个工程师还是你的时候。

这项技能对你有两个好处。第一，能够阅读别人的代码是一个很好的机会去了解什么是糟糕的设计。当你在浏览别人的代码时，你会学到什么有用，什么没用。更重要的是，您将了解哪些代码类型对其他工程师来说比较容易理解，哪些代码比较难理解。

您需要确保在阅读其他人的代码时尽可能多地抱怨。这样，其他工程师就会明白你是一个多么优秀的工程师。

确保您提到了可维护代码和良好注释的重要性。这进一步显示了您在编程领域的优势。

您的代码应该设计得非常好，不需要任何文档。事实上，如果您是一个优秀的程序员，就不应该编写任何代码的文档。这只是浪费时间，你需要把时间花在编程和开会上。

能够阅读其他人混乱的代码也使得在需要时进行更新变得很容易。这有时意味着更新您缺乏经验的代码。例如，我们曾经遵循一个脚本，从Powershell到Python再到Perl。虽然我们在Perl方面的经验有限，但是我们仍然有足够的上下文来了解发生了什么，并做出所需的更改。

这来自于对所有代码的良好理解以及能够阅读Perl脚本。

阅读别人的代码会让你更有价值，因为即使是那些过于复杂的系统也会让别人感到困惑。

对糟糕项目的感觉

有很多技能需要花时间去学习。我们相信有一项技能是值得知道的，那就是了解哪些项目不值得去做，哪些项目显然是在走向死亡。

大公司总是有很多项目在进行，而这些项目可能永远无法完成或产生影响。有一些项目可能没有任何商业意义(至少对您来说没有)，还有一些项目管理不善。这并不是说，当你不同意某个项目的时候，你就应该打断它。然而，如果涉众不能正确地解释他们将对最终结果做什么，那么项目可能不值得做。

此外，有些项目可能过于关注技术而不是解决方案，因此从一开始就很明显不会有太大的影响。这一技能要求在你对一个糟糕的项目真正是什么有概念之前做很多糟糕的项目。所以，不要过早地花太多时间去分辨每个项目。

在你职业生涯的某个时候，你会有一个很好的直觉。

避免会议

无论您是软件工程师还是数据科学家，会议都是必要的，因为您需要能够与项目经理、最终用户和客户保持一致。然而，会议也有突然占据你整个日程的趋势。这就是为什么学习如何避免不必要的会议很重要。

也许用“管理”这个词比“避免”更好。这里的目标是确保你把时间花在会议上，以推动决策并帮助你的团队前进。

最常见的方法就是每天留出两个小时的时间，那就是经常开会。通常，大多数人会在他们认为有益的时候安排一次经常性的会议。他们将利用这段时间来赶上他们的开发工作。

另一种避免开会的方法是比其他人早到，这样你就能完成工作。就我个人而言，我们喜欢早到，因为总的来说，办公室比较安静。大多数早起的人和你一样，只是想把工作做完，这样就不会有人打扰你了。

这对个人贡献者来说很重要，因为我们的工作需要我们专注的时间，我们不需要和其他人交谈。有时候你可能想和别人一起解决问题。但是一旦您解决了阻塞问题，您只需要编写代码。它是关于进入一个区域，在这个区域里，你的头脑中不断地持有许多关于你正在做的工作的复杂想法。如果你不停地停下来，你就很难从停止的地方继续。

Git

一些CS专业的学生从出生那天就开始使用Git。他们能够理解每一个命令和参数，并且能够围绕专业人员运行。

其他人则是在第一份工作中第一次接触到GitHub。对他们来说，Github是一个混乱的命令和进程的地狱。他们从不100%确定自己在做什么(备忘单受欢迎是有原因的)。

无论您的公司使用哪种存储库系统，如果正确使用该系统，那么该系统都是有用的;如果使用不当，则会成为障碍。一个简单的推动或承诺并不会让你花费很多时间去理清由多个分支和叉组成的大杂烩。此外，如果您经常忘记提取存储库的最新版本，那么您还将处理从未有过乐趣的合并冲突。

如果需要保存Git命令备忘单，那么就这么做。只要能让你的生活更简单。

编写简单的可维护代码

年轻工程师可能有一种倾向，就是试图将他们所知道的所有东西都实现到一个解决方案中。人们希望理解面向对象编程、数据结构、设计模式和新技术，并在编写的每一段代码中使用所有这些知识。您创建了不必要的复杂性，因为很容易过度依赖于过去使用的解决方案或设计模式。

复杂的设计概念和简单的代码之间存在一种平衡。设计模式和面向对象的设计应该从整体上简化代码。然而，一个过程被抽象、封装和黑盒化的越多，调试就越困难。

学会说“不”，分清轻重缓急

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!