我从 14 岁就开始在父母的卧室里写代码。我通过非常慢的网络阅读任何我能够获得的东西。20 岁时,作为一名 Web 开发人员,我签了人生中的第一份劳动合同,我当时学的是 PHP 和 JavaScript。
我在这个领域花了 18 年时间,才发现编程只是职业的一小部分。即使是空闲时间出于兴趣,我也不会停止编码,但工作中还有很多其它事情。有些事情,开发者往往很晚才能领悟到,这也是为什么我想和大家分享我的经历,以及我觉得很重要的 9 个经验教训。
1. 放下自负
开发者通常很自负。这是事实。
为什么呢?我认为,任何认真对待自己职业的人都会认为自己有点儿像艺术家。我们虽然不会在数百万人面前唱歌或者作画,但我们有时候在以一种非常优雅高效的方式编写代码、解决非常复杂的问题,我们同样为自己的工作感到自豪。
开发者和数学家一样,解决问题的方式都有点儿像艺术家。
正因如此,我们很维护自己的代码——就像熊妈妈照顾她的后代那样。亲手写下这些代码的我们,无法忍受别人对他指指点点。
但这对任何人都没有帮助。我们热爱自己的工作,但更重要的是我们正在解决问题。通过与其他人讨论我们的想法和方案,可能会出现更好的替代方案。这没有什么不对的。事实上,合作通常会产生最佳解决方案。
我见过各种各样自负的开发者,但没有见过哪种自负对开发者会有所帮助。
因此我的建议是:当你开始作为一名开发者工作时,请把你的自负抛掉,多听听其他人对你工作的看法。学会接受这样一个事实:更好的想法可能来自你的头脑之外,它们只会帮你提高自己的技能。只有倾听反馈,你才能赢。
2. 语言只是工具
如果你只懂 JavaScript,所有的问题都会像钉子一样。不要再称自己是一名 Java 开发者或 JavaScript 开发者。
由于某些语言的特性或语法,你可能会偏爱一些语言,这很正常。然而,如果你能学点别的东西,就会受益匪浅。学习新语言,尤其与你日常工作所用的范式不同的语言,会帮助你打开思路,发现解决问题的不同办法。
这一点我怎么强调也不过分:学习多种语言并使用一段时间,你会从中受益。
我几年前读过一本书《七周七语言》,展示了各种可用的选项,这让我思路大开。很多选择是我从来没有想到过的,因为我太专注于自己的日常任务和日常工具,从来没有停下来看看其它东西。
我们是开发者,知道如何通过代码来解决问题,但不要把自己放到一个盒子中,你会被那个盒子的大小所限制。看看那个盒子外面的东西,跳出那个盒子思考,试试其它选项、其它语言、其它解决问题的方法。即使只是一会儿,你也会带着新的想法和更大的心态做出更好的抉择。
3. 编程不需要记下所有的东西
有时候,开发新手认为他们需要把所有事情都记在心里,因此当他们意识到自己开始忘记如何写一个简单的for
语句时,就会感到很糟糕。
这不仅是正常的,而且我认为这也是健康的。
有太多东西需要记忆了,但我们其实不需要记忆,我们只需要拥抱这样一个事实:互联网是另一个有力的工具。就像我们需要 IDE 一样,我们需要互联网来寻找答案。
我们都这样做,如果你一开始就感觉不好,就不要在这种感觉上浪费时间。只需要寻找你的答案并解决你的问题。
这样想一想:每一种语言都有一种类似但又稍有不同的观察者(Observer)模式的实现方式。你认为什么更现实?理解观察者模式有什么好处以及它能解决什么问题,还是记住你所使用的每一种语言如何实现它?
如果你知道它能解决你的问题,那么你就真的解决了你的问题。剩下的只是搜索实现它的最佳方法。
其它搜索也是一样。只专注于我们职业中重要的解决问题的方面,让谷歌帮你慢慢回忆。这才是正确的方式。
4. 你将终身学习
或者说,“你应该终身学习”,这完全取决于你自己是否要跟上行业的最新发展。如果你想要保持相关性,那么你就必须一直学习。
技术在发展,语言在变化,这都很正常。诚然,有些生态系统比其它生态系统变化得更快,跟上他们的步伐似乎是一项艰巨的任务。但是,记住你只是一个人,不可能无所不知,只需专注于重要的事情。如果你必须学会一件事情,那么我的建议是学会如何学习。
这听起来很傻,但这可能是一名开发人员需要的首要技能。我们必须在快速学习新技能方面表现得更好。否则,你将陷入被标记为“过时”的风险。
同时,这也是本文提到的其它经验发挥作用的地方。变化、改变、新的挑战、没有自负——所有这些都会帮助你学习并拓展技能范围。你做的越多,效果就会越好。最终,你会发现所有的语言都是类似的。你将开始看到它们公共的根本,你将能够用其中任何一种语言工作。你所要做的就是阅读一些关键的东西。
你的整个职业生涯都要学习:
新语言
新(老)编程范式
新工作方法
解决问题的新方法
与团队互动的新方法
检查和测试代码的新方法
如果你还没有准备好永远当一名学生,那你需要考虑下这个职业是否适合你。请注意,我不是说“立刻辞职”,而是考虑下是否愿意开放思维来持续学习。
5. 代码要解决问题,而非完美
这个问题我说过很多次,但是作为开发者,我们倾向于认为自己的代码在发布之前需要是完美的。虽然这并没有什么不对,但也可能是一个潜在的问题。
早期优化是一个问题,因为你可能在某件可能并不需要优化的事上花费大量时间,而且在某些情况下执行优化时,你会做出破坏功能的假设。
所以,把注意力集中在需要做的工作和你正在尝试解决的问题上,一旦问题修复,立马测试、迭代结果,看看团队对你的解决方案有什么想法——即使你已经看到了改进的方法。如果你需要花费两天以上的时间来让它完美,但它现在就可以投入生产,很有可能现在就应该投入生产。
归根结底,你是在解决问题。解决问题越快,对你的用户就越好。
6. 先让代码起作用,然后再优化
跟上面提到的观点一样,不要陷入早期优化的黑洞。
即使你认为你可以快速优化,但一旦你开始做,你就会发现时间膨胀效应是真的。
作为软件开发人员的首要任务是写一个功能或修复一个 bug 来让它起作用——无论代码看起来多丑或者你的方案可能多么低效。如果它起作用了,你就证明了它是可行的。这就成功了一半。
第二步是优化它。这是可选的一步。一些人容易忘记的细节,你可以用来优化代码的时间取决于很多变量,这些变量有时候不受你的控制。因此,集中精力让它起作用,然后再看看你是否真有时间来优化它。
早期优化意味着要边写代码边优化,这是一种危险的方式,因为优化时,我们都是在对执行时间、数据要求、内存需求以及其它我们尚未看到的因素进行假设,任何这样的假设都可能是错误的,最终会在你的逻辑中引入 bug。
想想 TDD 工作流:
编写测试来理解你的功能需要做的所有事情(它将失败)。
编写代码来通过测试。
现在考虑优化你的代码。
步骤 2 是必需的。你首先需要考虑通过测试,也就是说让功能起作用。测试不关心你使用的算法或者你是否使用了三层嵌套的if
语句。稍后才会做那些,可能是代码评审过程中的一部分。
7. 项目最后的 10%往往要花费 90%的时间
如果你一个人独自工作,这一点尤其重要,但是团队也会有这种细节计算失误的问题。
任何一个做完项目的人都会告诉你同样的事情(这不仅仅适用于我们行业):你一开始会略过很多细节,最后才不得不考虑它们。
这很正常。我们都倾向于一开始专注于重大的功能,将比较小的细节或已知的 bug 留到最后。但是它们仍然需要解决,这就是额外 90%的工作。精细的工作比较花时间。你需要测试、修复、重新测试、写文档、执行用户培训、展示最终方案等等。
当然,这取决于你的环境、客户以及很多其它因素,但总会有一些东西。所以记住:当你认为你已经写完代码的时候,你很可能忘记了一些东西。
8. 写过一次以上的代码,需要进行抽象
编码是关于抽象的行为。通过抽象通用逻辑,我们可以在其它地方复用它,但是一开始的时候,我们有时会注意不到抽象的重要性。
这是我个人的经验法则:如果我在两个地方写了相同的代码,那么就将它们放到一个函数中(或者一个方法,一个模块等等...你懂的)。
即使数字二对你来说很低,但是要考虑到将来你可能在其它地方使用抽象后的代码。而且通过把它放到一个常用的地方,你现在就可以使用它了。
抽象和规模有关。一段抽象的逻辑可以用很少的精力就被复用很多次,而到处复制粘贴代码虽然很容易,但用的越多需要的精力就越多。想想,如果你因为一个 bug 不得不改变一段逻辑,而它在你的项目中被重复了 5 次,会发生什么?你在修复这个 bug 时,会有 5 次机会犯错。
同样的逻辑也适用于你的日常任务。如果你发现自己做某件事一次以上,那么它可能就可以用某种方式自动化。这是效率的关键,因此不要仅仅在代码中寻找重复模式,在你的动作中也可以寻找重复模式。如果你能自动化完成一项每天需要 10 分钟的任务,你一个月就能节省 5 个小时。
9. 副业项目不是必需的,但它们确实有帮助
有人说,如果你想要成为一名成功的开发人员,你需要创建副业项目。我并不认同这一点。我个人认识很多优秀的开发者,他们只在朝九晚五工作时写代码。
老实说,我很钦佩他们。他们能够在做好工作的同时,享受他们的空闲时间做其它事情。这绝对没有什么问题。
然而,有时候你需要一些额外的练习。有时候你觉得自己落后于其它同事。而这时,副业项目就会有所帮助。
我不是说构建一个新项目,让数以百万计的人使用,或者对产业进行革命性改变,当然如果你喜欢的话,就去做。但是我讨论的是拷贝其他人的项目,以便从中学习。我说的是通过解决 bug 或者增加额外功能来向其他人的项目做贡献。
你可以用副业项目来体验你不经常看到的地方。如果你每天写 8 小时的单元测试,也许可以考虑从头创建一些东西并且开发一些功能。如果你厌倦了独自工作,可以考虑为现有的项目做贡献,体验一下如何与其他人协调工作。
你可以使用副业项目来强化自己的薄弱环节,从而帮助你提高自己的技能。但同样,不要为了被认为是一名严肃的开发人员,而认为你需要为他们工作或者拥有一个绿色的 GitHub 活动图。那太傻了。
结论
这是我作为一名开发者在过去 18 年中学到的最难的 9 个经验教训,希望通过我的分享,能对你的新(或者已经从事的)职业有所启示。
你有想要分享的其它经验吗?请在下方留言。我很乐意向你学习。
作者介绍
Fernando Doglio 在 Globant 担任技术经理,撰写关于技术、生活方式和个人事业等方面的文章。热爱学习,自认为是个永远的学生。在过去 14 年一直从事软件行业,因此对于其运作方式和技术变迁有比较好的理解。
原文链接
9 Hard Lessons I Struggled to Learn During My 18 Years as a Software Developer
评论 6 条评论