高效程序员的七个习惯 | 程序猿DD

软件工程师花费大量时间通过练习leet code问题和完善简历来获得更好的面试通过可能。一旦他们最终被谷歌、亚马逊或其他公司录用，他们可能会发现：过去用来得到这份工作的技能与他们日常工作中需要的技能并不匹配。

我们的团队受到 TechLead 创建的高效程序员七项技能的启发。我们想提供我们自己对这个话题的看法。以下是我们总结的高效程序员的七项技能。

1. 学习如何阅读别人的代码

除了你，每个人写的代码都是垃圾？实际上，能够在别人的代码之上继续工作是一项有多重好处的伟大技能。

不管以前工程师的代码是多么混乱或者考虑不周，您仍然需要能够扩展它。毕竟，这是你的工作。同时，这个“以前的工程师”也可能是一年前的你。

这项技能在两个方面对你有益。第一，能够阅读他人的代码是一个了解什么是糟糕设计的好机会。当你浏览别人的代码时，你会知道什么是有效的，什么是无效的。更重要的是，您可以了解什么类型的代码对于其他工程师来说是容易扩展的，以及什么类型的代码难以扩展。

你需要确保在阅读他人代码时尽可能多地找出问题所在。这样，其他的工程师就会知道你是一个多么优秀的工程师。确保您提出了关于可维护代码和良好注释的重要性观点。这进一步显示了你在编程领域的优势。

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

能够阅读别人乱七八糟的代码的话，也使得在需要更新的时候变得容易。这有时意味着更新您缺乏经验的代码。例如，我们曾经将一个脚本从 Powershell 更新到 Python 再到 Perl。我们在Perl方面的经验有限，但我们仍然有足够的背景知识来弄清楚这段脚本到底做了什么，并做出必要的改变。

这一切都来自于对所有代码的良好理解以及能够阅读以往的代码。阅读别人的代码会让你变得有价值，因为这项技能甚至可以让你接手那些让别人难堪的过度工程化的系统。

2. 对坏项目的感觉

有许多技能需要花时间去学习。我们认为值得了解的技能之一是理解什么项目不值得做，什么项目显然是行尸走肉。

大公司总是有非常非常多的项目在进行（老板自己都不知道有多少），其中有些项目可能永远都不会完成，即时完成了，可能对公司也没有什么有利的影响。有些可能本身就没有任何商业意义(至少对你来说不是) ，还有一些项目可能存在管理不善的问题。这并不是说当你不认可一个项目时，你应该立即拒绝这个项目。最嗨还是看看项目干系人是如何看待这个项目的，如果他们自己都不能正确地解释他们对这个项目的最终成果会怎么样的，那么可能这个项目就不值得做。

此外，有些项目可能过于专注于技术而不是解决方案，以至于从一开始就很清楚不会有太多的影响。这个技能需要你在知道一个糟糕的项目到底是什么之前做很多糟糕的项目。所以，不要过早地花费太多时间试图辨别每个项目。

在你职业生涯的某个时刻，你会拥有良好的直觉与意识。

3. 避免不必要的会议

无论您是软件工程师还是数据科学家，会议都是必不可少的，因为您需要能够与项目经理、最终用户和客户达成共识。然而，也有一种倾向，会议会突然接管你的整个时间表。这就是为什么学会如何避免不必要的会议是很重要的。

也许一个更好的词是管理，而不是避免。这里的目标是确保你把时间花在能够推动决策和帮助你的团队前进的会议上。

最常见的方法就是每天抽出两个小时的时间，这是一个持续不断的会议。通常，大多数人会在他们认为有益的时候定期召开会议。他们会利用这段时间来赶上他们的开发工作。

另一个避免开会以便完成工作的方法是在别人之前出现。就我个人而言，我们喜欢早到，因为一般来说，办公室比较安静。大多数早到的人和你一样，只是想把工作做完，这样就不会有人打扰你了。

这对个人贡献者来说很重要，因为我们的工作需要我们集中注意力的时间，而且我们不会和其他人交谈。 是的，有时候你可能需要解决问题，你可能想和其他人一起工作。但是一旦你解决了阻塞问题，你只需要编码。它是关于进入那个区域，在那里你不断地在你的头脑中有许多关于你正在做的工作的复杂的想法。 如果你总是停下来，很难从中断的地方重新开始。

4. 使用Git

一些计算机专业的学生在他们出道的那天就开始使用 Git 了。他们不需要专业人士指导就可以理解每一个命令和参数。其他人在他们的第一份工作中第一次体验到 GitHub。 对他们来说，Github 是一个地狱般的地方，充斥着混乱的命令和进程。他们永远都不是100%的确定自己在做什么(备忘录之所以流行是有原因的)。

无论您的公司使用什么仓库系统，如果您正确使用它，该系统都是有用的，如果使用不当，则是一个障碍。一个简单的commit或push就可以让你花上几个小时来理清一些由多个分支合并组成的大杂烩。此外，如果您经常忘记使用仓库的最新版本，那么您还将处理不那么好玩的合并冲突。

如果您需要一个 Git 命令备忘单，那么就做吧。只要能让你的生活更简单。

5. 编写简单可维护的代码

年轻的工程师可能会有一种倾向，那就是试图将他们所知道的一切都实现到一个解决方案中。有一种愿望，那就是把你对面向对象程序设计、数据结构、设计模式和新技术的理解用到你编写的每一个代码中。然后，你就很有可能创建了一个不必要的复杂性，因为它很容易过度依附于您过去使用过的解决方案或设计模式。

在复杂的设计概念和简单的代码之间取得平衡。设计模式和面向对象设计应该尽可能的去简化宏观计划中的代码。进程越是被抽象、封装和黑盒化，就越难以调试和维护。

6. 学会说不，分清主次

这一条适用于团队中的任何角色，不管你是财务分析师还是软件工程师。但对于技术角色似乎每个人都更需要学会这一条。如果您是一名数据工程师，您可能会被要求做更多类似开发方向的事情。一些团队需要数据提取，其他团队需要仪表盘，其他团队又需要新的数据分析对接。

区分事情的优先顺序和说不，是两种不同的技能，但它们紧密地交织在一起。优先级区分意味着你只花时间在对公司有很大影响的事情上。然而，说不有时只是意味着回避应该由其他团队来处理的工作。对于所有角色而言，它们经常同时出现。

这可能是一个很难获得的技能，因为你总是希望用自己的方式去满足每一个请求。尤其是你刚从大学毕业。你想避免让任何人失望，而且你总是能得到大量的工作。但是，在大公司里总是有无穷无尽的工作量，所以一定要抓住关键：只承担能做的事情。

有很多技能在面试中是没有办法测试和验证的，甚至在大学里都没有教过。通常情况下，这更多的是环境的限制，而不是缺乏让学生暴露在真实环境中发展成长的愿望。

7. 场景化思维

有一种技能在面试中很难测试，在大学学习时也很难复制，那就是思考最终用户可能会如何错误地使用你的软件。我们通常将其称为场景化操作思维。

由于大部分编程都是维护性的，因此它通常意味着更改与其他代码高度耦合的代码。即使是简单的更改也需要跟踪对象、方法和 API的每一个可能存在引用的地方。否则，很容易意外地打破你没有意识到的模块连接。即使您只是更改数据库中的数据类型。

它还包括在进入开发之前通过边缘案例和整体化的高级设计进行思考。

对于开发新模块或者微服务的场景就更加复杂，花时间去考虑所构建的操作场景非常重要。想想未来的用户可能需要如何使用您的新模块，他们可能会如何不正确地使用它，可能需要什么参数，以及未来的程序员是否会以不同的方式需要您的代码。

简单的编码和编程只是问题的一部分。创建一个在你的电脑上运行良好的软件是很容易的。但是部署代码可能出错的方式就会有很多。一旦进入生产环境，就很难说代码将如何使用，以及哪些其他代码将附加到原始代码中。五年后，未来的程序员可能会对你的代码局限性感到沮丧。

本文译自：https://dev.to/seattledataguy/7-habits-of-highly-effective-programmers-inspired-by-an-ex-google-techlead-humor-4b4k