软件开发从业18年，我总结了9个最有价值的经验

从 14 岁起，我就开始在父母的卧室里写代码。当时，通过非常慢的网络，我阅读任何能够获得的东西。20 岁时，作为一名 Web 开发人员，我签了人生中的第一份劳动合同，当时学的是 PHP 和 JavaScript。

在这个领域，我花了 18 年时间，才发现编程只是职业的一小部分。即使是空闲时间出于兴趣，我也不会停止编码，但工作中还有很多其它事情。有些事情，开发者往往很晚才能领悟到，这也是为什么我想和大家分享我的经历，以及我觉得很重要的 9 个经验教训。

开发者通常很自负。这是事实。

为什么呢？我认为，任何认真对待自己职业的人都会认为自己有点儿像艺术家。我们虽然不会在数百万人面前唱歌或者作画，但我们有时候在以一种非常优雅高效的方式编写代码、解决非常复杂的问题，我们同样为自己的工作感到自豪。

开发者和数学家一样，解决问题的方式都有点儿像艺术家。

正因如此，我们很维护自己的代码——就像熊妈妈照顾她的后代那样。亲手写下这些代码的我们，无法忍受别人对他指指点点。

但这对任何人都没有帮助。我们热爱自己的工作，但更重要的是我们正在解决问题。通过与其他人讨论我们的想法和方案，可能会出现更好的替代方案。这没有什么不对的。事实上，合作通常会产生最佳解决方案。

我见过各种各样自负的开发者，但没有见过哪种自负对开发者会有所帮助。

因此我的建议是：当你开始作为一名开发者工作时，请把你的自负抛掉，多听听其他人对你工作的看法。学会接受这样一个事实：更好的想法可能来自你的头脑之外，它们只会帮你提高自己的技能。只有倾听反馈，你才能赢。

如果你只懂 JavaScript，所有的问题都会像钉子一样。不要再称自己是一名 Java 开发者或 JavaScript 开发者。

由于某些语言的特性或语法，你可能会偏爱一些语言，这很正常。然而，如果你能学点别的东西，就会受益匪浅。学习新语言，尤其与你日常工作所用的范式不同的语言，会帮助你打开思路，发现解决问题的不同办法。

这一点我怎么强调也不过分：学习多种语言并使用一段时间，你会从中受益。

我几年前读过一本书《七周七语言》，展示了各种可用的选项，这让我思路大开。很多选择是我从来没有想到过的，因为我太专注于自己的日常任务和日常工具，从来没有停下来看看其它东西。

https://www.amazon.com/-/es/Bruce-Tate/dp/193435659X/

我们是开发者，知道如何通过代码来解决问题，但不要把自己放到一个盒子中，你会被那个盒子的大小所限制。看看那个盒子外面的东西，跳出那个盒子思考，试试其它选项、其它语言、其它解决问题的方法。即使只是一会儿，你也会带着新的想法和更大的心态做出更好的抉择。

有时候，开发新手认为他们需要把所有事情都记在心里，因此当他们意识到自己开始忘记如何写一个简单的 for 语句时，就会感到很糟糕。

这不仅是正常的，而且我认为这也是健康的。

有太多东西需要记忆了，但我们其实不需要记忆，我们只需要拥抱这样一个事实：互联网是另一个有力的工具。就像我们需要 IDE 一样，我们需要互联网来寻找答案。

我们都这样做，如果你一开始就感觉不好，就不要在这种感觉上浪费时间。只需要寻找你的答案并解决你的问题。

这样想一想：每一种语言都有一种类似但又稍有不同的观察者（Observer）模式的实现方式。你认为什么更现实？理解观察者模式有什么好处以及它能解决什么问题，还是记住你所使用的每一种语言如何实现它？

如果你知道它能解决你的问题，那么你就真的解决了你的问题。剩下的只是搜索实现它的最佳方法。

其它搜索也是一样。只专注于我们职业中重要的解决问题的方面，让谷歌帮你慢慢回忆。这才是正确的方式。

或者说，“你应该终身学习”，这完全取决于你自己是否要跟上行业的最新发展。如果你想要保持相关性，那么你就必须一直学习。

技术在发展，语言在变化，这都很正常。诚然，有些生态系统比其它生态系统变化得更快，跟上他们的步伐似乎是一项艰巨的任务。但是，记住你只是一个人，不可能无所不知，只需专注于重要的事情。如果你必须学会一件事情，那么我的建议是学会如何学习。

这听起来很傻，但这可能是一名开发人员需要的首要技能。我们必须在快速学习新技能方面表现得更好。否则，你将陷入被标记为“过时”的风险。

同时，这也是本文提到的其它经验发挥作用的地方。变化、改变、新的挑战、没有自负——所有这些都会帮助你学习并拓展技能范围。你做的越多，效果就会越好。最终，你会发现所有的语言都是类似的。你将开始看到它们公共的根本，你将能够用其中任何一种语言工作。你所要做的就是阅读一些关键的东西。

你的整个职业生涯都要学习：

• 新语言

• 新（老）编程范式

• 新工作方法

• 解决问题的新方法

• 与团队互动的新方法

• 检查和测试代码的新方法

如果你还没有准备好永远当一名学生，那你需要考虑下这个职业是否适合你。请注意，我不是说“立刻辞职”，而是考虑下是否愿意开放思维来持续学习。

这个问题我说过很多次，但是作为开发者，我们倾向于认为自己的代码在发布之前需要是完美的。虽然这并没有什么不对，但也可能是一个潜在的问题。

早期优化是一个问题，因为你可能在某件可能并不需要优化的事上花费大量时间，而且在某些情况下执行优化时，你会做出破坏功能的假设。

所以，把注意力集中在需要做的工作和你正在尝试解决的问题上，一旦问题修复，立马测试、迭代结果，看看团队对你的解决方案有什么想法——即使你已经看到了改进的方法。如果你需要花费两天以上的时间来让它完美，但它现在就可以投入生产，很有可能现在就应该投入生产。

归根结底，你是在解决问题。解决问题越快，对你的用户就越好。

跟上面提到的观点一样，不要陷入早期优化的黑洞。

即使你认为你可以快速优化，但一旦你开始做，你就会发现时间膨胀效应是真的。

作为软件开发人员的首要任务是写一个功能或修复一个 bug 来让它起作用——无论代码看起来多丑或者你的方案可能多么低效。如果它起作用了，你就证明了它是可行的。这就成功了一半。

第二步是优化它。这是可选的一步。一些人容易忘记的细节，你可以用来优化代码的时间取决于很多变量，这些变量有时候不受你的控制。因此，集中精力让它起作用，然后再看看你是否真有时间来优化它。

早期优化意味着要边写代码边优化，这是一种危险的方式，因为优化时，我们都是在对执行时间、数据要求、内存需求以及其它我们尚未看到的因素进行假设，任何这样的假设都可能是错误的，最终会在你的逻辑中引入 bug。

想想 TDD 工作流：

• 编写测试来理解你的功能需要做的所有事情（它将失败）。

• 编写代码来通过测试。

• 现在考虑优化你的代码。

步骤 2 是必需的。你首先需要考虑通过测试，也就是说让功能起作用。测试不关心你使用的算法或者你是否使用了三层嵌套的 if 语句。稍后才会做那些，可能是代码评审过程中的一部分。

如果你一个人独自工作，这一点尤其重要，但是团队也会有这种细节计算失误的问题。

任何一个做完项目的人都会告诉你同样的事情（这不仅仅适用于我们行业）：你一开始会略过很多细节，最后才不得不考虑它们。

这很正常。我们都倾向于一开始专注于重大的功能，将比较小的细节或已知的 bug 留到最后。但是它们仍然需要解决，这就是额外 90% 的工作。精细的工作比较花时间。你需要测试、修复、重新测试、写文档、执行用户培训、展示最终方案等等。

当然，这取决于你的环境、客户以及很多其它因素，但总会有一些东西。所以记住：当你认为你已经写完代码的时候，你很可能忘记了一些东西。

编码是关于抽象的行为。通过抽象通用逻辑，我们可以在其它地方复用它，但是一开始的时候，我们有时会注意不到抽象的重要性。

这是我个人的经验法则：如果我在两个地方写了相同的代码，那么就将它们放到一个函数中（或者一个方法，一个模块等等... 你懂的）。

即使数字二对你来说很低，但是要考虑到将来你可能在其它地方使用抽象后的代码。而且通过把它放到一个常用的地方，你现在就可以使用它了。

抽象和规模有关。一段抽象的逻辑可以用很少的精力就被复用很多次，而到处复制粘贴代码虽然很容易，但用的越多需要的精力就越多。想想，如果你因为一个 bug 不得不改变一段逻辑，而它在你的项目中被重复了 5 次，会发生什么？你在修复这个 bug 时，会有 5 次机会犯错。

同样的逻辑也适用于你的日常任务。如果你发现自己做某件事一次以上，那么它可能就可以用某种方式自动化。这是效率的关键，因此不要仅仅在代码中寻找重复模式，在你的动作中也可以寻找重复模式。如果你能自动化完成一项每天需要 10 分钟的任务，你一个月就能节省 5 个小时。

有人说，如果你想要成为一名成功的开发人员，你需要创建副业项目。我并不认同这一点。我个人认识很多优秀的开发者，他们只在朝九晚五工作时写代码。

老实说，我很钦佩他们。他们能够在做好工作的同时，享受他们的空闲时间做其它事情。这绝对没有什么问题。

然而，有时候你需要一些额外的练习。有时候你觉得自己落后于其它同事。而这时，副业项目就会有所帮助。

我不是说构建一个新项目，让数以百万计的人使用，或者对产业进行革命性改变，当然如果你喜欢的话，就去做。但是我讨论的是拷贝其他人的项目，以便从中学习。我说的是通过解决 bug 或者增加额外功能来向其他人的项目做贡献。

你可以用副业项目来体验你不经常看到的地方。如果你每天写 8 小时的单元测试，也许可以考虑从头创建一些东西并且开发一些功能。如果你厌倦了独自工作，可以考虑为现有的项目做贡献，体验一下如何与其他人协调工作。

你可以使用副业项目来强化自己的薄弱环节，从而帮助你提高自己的技能。但同样，不要为了被认为是一名严肃的开发人员，而认为你需要为他们工作或者拥有一个绿色的 GitHub 活动图。那太傻了。

这是我作为一名开发者在过去 18 年中学到的最难的 9 个经验教训，希望通过我的分享，能对你的新（或者已经从事的）职业有所启示。

原文链接：

https://medium.com/better-programming/9-hard-lessons-i-struggled-to-learn-during-my-18-years-as-a-software-developer-14f28512f647