高效程序员的 7 个习惯 - 灵感来自前谷歌 TechLead #humor
软件工程师花费大量时间通过练习 Leet 代码问题和完善简历来获得面试技巧。
一旦他们最终在初创公司、谷歌、亚马逊或其他公司找到工作,他们可能会发现他们用来获得这份工作的技能与他们日常工作所需的技能并不匹配。
我们的团队受到了 TechLead 提出的高效程序员七项技能的启发。我们想就此话题提出自己的看法。
以下是我们总结的高效程序员七项技能。
1. 学习如何阅读其他人的代码
除了你之外,其他人都写出了糟糕的代码。
这就是为什么能够遵循其他人的代码是一项具有多重好处的伟大技能。
无论前任工程师的代码多么混乱或多么缺乏思考,你仍然需要能够理解。毕竟,这是你的工作。即使那位工程师一年前还是你。
这项技能有两大益处。首先,能够阅读他人的代码是了解什么是糟糕设计的绝佳机会。在阅读他人代码的过程中,你可以了解哪些代码有效,哪些无效。更重要的是,你可以了解哪些类型的代码对其他工程师来说容易理解,哪些代码难以理解。
在阅读别人的代码时,你需要尽可能多地提出问题。这样,其他工程师才能明白你是多么优秀的工程师。
请务必强调可维护代码和良好注释的重要性。这进一步展现了你在编程领域的卓越实力。
你的代码应该设计得非常精良,以至于不需要任何文档。事实上,如果你是一名优秀的程序员,你根本不应该为你的程序编写任何文档。这只会浪费时间,你应该把时间花在编写代码和开会上。
能够读懂别人杂乱的代码也让我们在需要时更容易进行更新。这有时意味着需要更新你缺乏经验的代码。例如,我们曾经把一个脚本从 Powershell 改成 Python 再改成 Perl。虽然我们的 Perl 经验有限,但我们仍然具备足够的背景知识来弄清楚发生了什么,并做出必要的更改。
这源于你对所有代码的充分理解以及能够阅读 Perl 脚本的能力。
阅读他人的代码会让你更有价值,因为即使是那些过度设计的系统,即使别人可能难以理解,你也能理解。
2. 识别不良项目
很多技能都需要花时间学习。我们认为其中一项值得掌握的技能是了解哪些项目不值得做,哪些项目显然是“死亡行军”。
大公司总是有比最终完成或产生影响的项目数量更多的项目。有些项目可能没有任何商业意义(至少对你来说),而有些项目只是管理不善。这并不是说你应该在不同意项目意见时就立即放弃一个想法。但是,如果利益相关者无法正确解释他们将如何处理最终结果,那么这个项目或许就不值得做。
此外,有些项目可能过于注重技术而非解决方案,以至于从一开始就很明显不会产生太大的影响。这项技能需要你做过很多糟糕的项目,才能真正理解什么是糟糕的项目。所以,不要在早期就花太多时间去辨别每个项目。
在你职业生涯的某个阶段,你会拥有良好的直觉。
3. 逃避会议
无论您是软件工程师还是数据科学家,会议都是必需的,因为您需要与项目经理、最终用户和客户达成共识。然而,会议也常常会突然占据您的整个日程。因此,学习如何避免不必要的会议至关重要。
也许用“管理”而不是“避免”这个词更贴切。这样做的目的是确保你把时间花在那些能够推动决策、帮助团队前进的会议上。
最常见的方法是每天简单地预留出两个小时的固定会议时间。通常情况下,大多数人会在自己认为合适的时间安排定期会议。他们会利用这段时间来跟进开发工作。
避免开会、完成工作的另一个方法是比其他人更早到。就我个人而言,我们喜欢早到,因为通常情况下,办公室比较安静。大多数早到的人都和你一样,只想把工作完成,这样就不会有人打扰你。
这对于个人贡献者来说至关重要,因为我们的工作需要我们集中精力,不与他人交流。没错,有时你可能正在解决问题,需要与他人合作。但一旦你克服了阻碍,你只需要开始编码。关键在于进入一个状态,让你的头脑中不断涌现出许多关于你正在做的工作的复杂想法。如果你经常被打断,就很难从上次中断的地方继续下去。
4. Git
有些计算机专业的学生从出生那天起就开始使用 Git。他们了解每一个命令和参数,比专业人士都要熟练。
而另一些人则是在工作之初才第一次接触 GitHub。对他们来说,GitHub 就像一个地狱,充斥着令人困惑的命令和流程。他们永远无法 100% 确定自己在做什么(这就是备忘单流行的原因)。
无论贵公司使用哪种仓库系统,正确使用都会带来好处,但使用不当则会造成阻碍。一个简单的推送或提交操作,很容易就变成你花费数小时去理清一堆杂乱无章的分支和分叉。此外,如果你经常忘记拉取仓库的最新版本,你还会面临合并冲突,这可不是件容易的事。
如果你需要保存一份 Git 命令速查表,那就去做吧。只要能让你的生活更轻松就行。
5.编写简单可维护的代码
年轻工程师可能有一种倾向,就是试图将他们所知道的一切都融入到一个解决方案中。他们渴望将自己对面向对象编程、数据结构、设计模式和新技术的理解运用到自己编写的每一段代码中。由于很容易过度依赖过去使用过的解决方案或设计模式,这反而会造成不必要的复杂性。
复杂的设计理念和简单的代码之间需要找到平衡。设计模式和面向对象设计应该从宏观上简化代码。然而,一个流程越抽象、越封装、越黑盒化,调试起来就越困难。
6.学会说“不”,并分清轻重缓急
这实际上适用于任何职位,无论你是财务分析师还是软件工程师。但尤其对于技术职位来说,似乎每个人都有自己的需求。如果你是一名数据工程师,你可能会被要求做更多的事情,而不仅仅是开发流程。有些团队需要数据提取,有些团队需要仪表板,还有一些团队需要为其数据科学家构建新的流程。
确定优先级和说“不”或许真的是两种不同的技能,但它们却紧密相连。确定优先级意味着你只花时间去做对公司有重大影响的事情。而说“不”有时只是意味着回避那些应该由其他团队处理的工作。对于所有角色来说,这两者通常同时发生。
这可能是一项很难掌握的技能,因为很容易就接受所有交给你的请求。尤其是如果你刚从大学毕业。你不想让任何人失望,而且你总是能完成相当多的工作。
在大公司,工作量总是无穷无尽的。关键在于只做那些可以完成的事情。
很多技能在面试中不予考查,甚至在大学里也很少教授。很多时候,这更多的是环境的限制,而不是缺乏让学生接触实际开发环境中存在问题的意愿。
7. 操作设计思维
有一项技能在面试中很难考查,在大学学习中也很难复制,那就是思考最终用户可能会如何错误地使用你的软件。我们通常称之为“思考操作场景”。
然而,这只是一种礼貌的说法,表示您正在尝试伪造证明代码。
例如,由于编程的大部分工作是维护,这通常意味着修改与其他代码高度纠缠的代码。即使是简单的修改也需要追踪对象、方法和/或 API 的所有可能引用。否则,很容易意外破坏你没有意识到的模块。即使你只是更改数据库中的数据类型。
它还包括在进入开发之前考虑边缘情况并考虑整个高级设计。
对于开发新模块或微服务的更复杂情况,务必花时间仔细思考所构建内容的运营场景。思考一下未来的用户可能会如何使用你的新模块,他们可能会如何错误地使用它,可能需要哪些参数,以及未来的程序员是否会以不同的方式使用你的代码。
简单的编码和编程只是问题的一部分。编写在计算机上运行良好的软件很容易。但部署代码时,有很多方法可能会出错。一旦投入生产,就很难确定代码将如何使用,以及哪些其他代码会附加到原始代码上。五年后,未来的程序员可能会对你代码的局限性感到沮丧。
这篇文章的灵感来自TechLead
您是否有兴趣了解数据科学或技术?
如何获得你的第一个数据科学咨询客户
使用 Python 抓取 MeetUp API
我们最喜欢的 Coursera 免费机器学习课程
算法如何变得不道德和带有偏见
如何使用 SQL 加载多个文件
如何开发强大的
动态算法 将 CSV 数据批量插入 SQL Server
数据科学家必须具备的 4 项技能
SQL 最佳实践 - 设计 ETL 视频