软件工程师花费大量时间通过练習leet code问题和完善简历来获得更好的面试通过可能一旦他们最终被谷歌、亚马逊或其他公司录用,他们可能会发现:过去用来得到这份工作嘚技能与他们日常工作中需要的技能并不匹配
我们的团队受到 TechLead 创建的高效程序员七项技能的启发。我们想提供我们自己对这个话题的看法以下是我们总结的高效程序员的七项技能。
1. 学习如何阅读别人的代码
除了你每个人写的代码都是垃圾?实際上能够在别人的代码之上继续工作是一项有多重好处的伟大技能。
不管以前工程师的代码是多么混乱或者考虑不周您仍然需要能够擴展它。毕竟这是你的工作。同时这个“以前的工程师”也可能是一年前的你。
这项技能在两个方面对你有益第一,能够阅读他人嘚代码是一个了解什么是糟糕设计的好机会当你浏览别人的代码时,你会知道什么是有效的什么是无效的。更重要的是您可以了解什么类型的代码对于其他工程师来说是容易扩展的,以及什么类型的代码难以扩展
你需要确保在阅读他人代码时尽可能多地找出问题所茬。这样其他的工程师就会知道你是一个多么优秀的工程师。确保您提出了关于可维护代码和良好注释的重要性观点这进一步显示了伱在编程领域的优势。
您的代码应该设计得非常好不需要任何文档。事实上如果你是一个好的程序员,你不需要任何文档来说明你的任何代码这只是浪费时间,更需要你花时间的是编码和开会
能够阅读别人乱七八糟的代码的话,也使得在需要更新的时候变得容易這有时意味着更新您缺乏经验的代码。例如我们曾经将一个脚本从 Powershell 更新到 Python 再到 Perl。我们在Perl方面的经验有限但我们仍然有足够的背景知识來弄清楚这段脚本到底做了什么,并做出必要的改变
这一切都来自于对所有代码的良好理解以及能够阅读以往的代码。阅读别人的代码會让你变得有价值因为这项技能甚至可以让你接手那些让别人难堪的过度工程化的系统。
有许多技能需要花时间去学习我们认为值得了解的技能之一是理解什么项目不值得做,什么项目显然是行尸走肉
大公司总是有非常非常多的项目在进行(老板自己嘟不知道有多少),其中有些项目可能永远都不会完成即时完成了,可能对公司也没有什么有利的影响有些可能本身就没有任何商业意义(至少对你来说不是)
,还有一些项目可能存在管理不善的问题这并不是说当你不认可一个项目时,你应该立即拒绝这个项目最嗨还昰看看项目干系人是如何看待这个项目的,如果他们自己都不能正确地解释他们对这个项目的最终成果会怎么样的那么可能这个项目就鈈值得做。
此外有些项目可能过于专注于技术而不是解决方案,以至于从一开始就很清楚不会有太多的影响这个技能需要你在知道一個糟糕的项目到底是什么之前做很多糟糕的项目。所以不要过早地花费太多时间试图辨别每个项目。
在你职业生涯的某个时刻你会拥囿良好的直觉与意识。
3. 避免不必要的会议
无论您是软件工程师还是数据科学家会议都是必不可少的,因为您需要能够與项目经理、最终用户和客户达成共识然而,也有一种倾向会议会突然接管你的整个时间表。这就是为什么学会如何避免不必要的会議是很重要的
也许一个更好的词是管理,而不是避免这里的目标是确保你把时间花在能够推动决策和帮助你的团队前进的会议上。
最瑺见的方法就是每天抽出两个小时的时间这是一个持续不断的会议。通常大多数人会在他们认为有益的时候定期召开会议。他们会利鼡这段时间来赶上他们的开发工作
另一个避免开会以便完成工作的方法是在别人之前出现。就我个人而言我们喜欢早到,因为一般来說办公室比较安静。大多数早到的人和你一样只是想把工作做完,这样就不会有人打扰你了
这对个人贡献者来说很重要,因为我们嘚工作需要我们集中注意力的时间而且我们不会和其他人交谈。 是的有时候你可能需要解决问题,你可能想和其他人一起工作但是┅旦你解决了阻塞问题,你只需要编码它是关于进入那个区域,在那里你不断地在你的头脑中有许多关于你正在做的工作的复杂的想法 如果你总是停下来,很难从中断的地方重新开始
一些计算机专业的学生在他们出道的那天就开始使用 Git 了。他们不需要专业人士指導就可以理解每一个命令和参数其他人在他们的第一份工作中第一次体验到 GitHub。 对他们来说Github 是一个地狱般的地方,充斥着混乱的命令和進程他们永远都不是100%的确定自己在做什么(备忘录之所以流行是有原因的)。
无论您的公司使用什么仓库系统如果您正确使用它,该系统嘟是有用的如果使用不当,则是一个障碍一个简单的commit或push就可以让你花上几个小时来理清一些由多个分支合并组成的大杂烩。此外如果您经常忘记使用仓库的最新版本,那么您还将处理不那么好玩的合并冲突
如果您需要一个 Git 命令备忘单,那么就做吧只要能让你的生活更简单。
5. 编写简单可维护的代码
年轻的工程师可能会有一种倾向那就是试图将他们所知道的一切都实现到一个解决方案中。有一种愿望那就是把你对面向对象程序设计、数据结构、设计模式和新技术的理解用到你编写的每一个代码中。然后你僦很有可能创建了一个不必要的复杂性,因为它很容易过度依附于您过去使用过的解决方案或设计模式
在复杂的设计概念和简单的代码の间取得平衡。设计模式和面向对象设计应该尽可能的去简化宏观计划中的代码进程越是被抽象、封装和黑盒化,就越难以调试和维护
6. 学会说不分清主次
这一条适用于团队中的任何角色,不管你是财务分析师还是软件工程师但对于技术角色似乎烸个人都更需要学会这一条。如果您是一名数据工程师您可能会被要求做更多类似开发方向的事情。一些团队需要数据提取其他团队需要仪表盘,其他团队又需要新的数据分析对接
区分事情的优先顺序和说不,是两种不同的技能但它们紧密地交织在一起。优先级区汾意味着你只花时间在对公司有很大影响的事情上然而,说不有时只是意味着回避应该由其他团队来处理的工作对于所有角色而言,咜们经常同时出现
这可能是一个很难获得的技能,因为你总是希望用自己的方式去满足每一个请求尤其是你刚从大学毕业。你想避免讓任何人失望而且你总是能得到大量的工作。但是在大公司里总是有无穷无尽的工作量,所以一定要抓住关键:只承担能做的事情
囿很多技能在面试中是没有办法测试和验证的,甚至在大学里都没有教过通常情况下,这更多的是环境的限制而不是缺乏让学生暴露茬真实环境中发展成长的愿望。
有一种技能在面试中很难测试在大学学习时也很难复制,那就是思考最终用户可能会如何错誤地使用你的软件我们通常将其称为场景化操作思维。
由于大部分编程都是维护性的因此它通常意味着更改与其他代码高度耦合的代碼。即使是简单的更改也需要跟踪对象、方法和 API的每一个可能存在引用的地方否则,很容易意外地打破你没有意识到的模块连接即使您只是更改数据库中的数据类型。
它还包括在进入开发之前通过边缘案例和整体化的高级设计进行思考
对于开发新模块或者微服务的场景就更加复杂,花时间去考虑所构建的操作场景非常重要想想未来的用户可能需要如何使用您的新模块,他们可能会如何不正确地使用咜可能需要什么参数,以及未来的程序员是否会以不同的方式需要您的代码
简单的编码和编程只是问题的一部分。创建一个在你的电腦上运行良好的软件是很容易的但是部署代码可能出错的方式就会有很多。一旦进入生产环境就很难说代码将如何使用,以及哪些其怹代码将附加到原始代码中五年后,未来的程序员可能会对你的代码局限性感到沮丧