写了10年代码之后，我学到的7个绝对真理

  作者 | Monica Lent
  译者 | 阿拉丁
  编辑 | Natalie
  AI 前线导读：明年就是我的开发者生涯的第十个年头。整整十年！我有三分之二的时间都用在了 Web 开发上。在孩童时代，当其他小孩还在学习乐器或芭蕾舞的时候，我在自己的卧室里用代码编织了一个神奇的世界。为了给这十年来一个总结，我想分享一下我在过去的十年当中作为一名开发者的心路历程。对于现今的初级开发者来说，或许他们会在这篇文章里找到一些能够引起他们共鸣的东西，或者让他们深受鼓舞的东西。对于现今的高级开发者来说，或许他们也有一些有趣的故事可以分享，因为他们都是过来人。更多优质内容请关注微信公众号“AI 前线”（ID：ai-front）

  1. 我是高级开发者
我在 19 岁的时候开始应聘我的第一份开发工作，当时的那个职位叫作“Student Webmaster”。这个职位很有意思，因为如果你拿到这个职位，就变成了“学生”和“大师”的结合体。不过现在的人更希望成为“工程师”，因为这个头衔听起来似乎更有发烧友的味道。我当时的工作是负责 PHP 和 MySQL 方面的开发，维护 Drupal 网站，以及开发一些内部工具。
因为在孩童时代就开始写代码，并且我很肯定它们可以作为正式的经验，所以当被问及我有几年 PHP 经验时，我非常自信地回答道：”三到四年“！
我当时觉得我对 SQL 应该懂得挺多了，因为我都会用外连接了。
在当时，三到四年的经验意味着我可以拿到比较可观的薪水了。
五年之后，我开始了最近的这份工作。即使是到了这个时候，我的代码都没有给别人评审过。在部署代码的时候，我直接从 Git 上拉取代码，然后通过 SSH 部署到服务器上。我敢肯定我几乎没有提交过 PR。不过不要误会，其实我在头两份工作中学到了很多有用的东西，只是我从来没有真正地和其他开发者一起开发过同一个代码库。我就是这样去申请了”高级前端开发“的职位，并拿到了 offer。
就这样，我成了一名 24 岁的高级开发者。
我的意思是，如果我撑不起这个头衔，他们也不会给我这个职位的，对吧？我很确信的是，我之所以能够拿到这个职位，是因为我过去的那些令人印象深刻的经历。我感觉自己达到了职业生涯的巅峰，我是公司里最年轻的开发者。

  我最终学到了什么

每个时期的经验都是不一样的。孩童时期的编码经历、学生时期的编码经历、CS 研究员时期的编码经历，以及在成长型初创公司时期的编码经历，它们对我来说都是无价之宝。但各个时期的经历都是不一样的。在职业生涯早期，如果你加入了一个优秀的团队，那么在一年内学到的东西要比自己独立工作五年多十倍。如果你的代码没有拿给别人评审，就不会成长得那么快。
所以，导师很重要。加入团队比暂时多赚点钱要重要得多。如果有可能，不要接受那种独立工作的初级职位。在选择第一份工作时，不要只为了钱，加入好团队才是真正有价值的。
职位头衔什么的其实都是浮云。想象一下 5 人团队的 CTO 和 50 人团队或者 500 人团队的 CTO，虽然头衔一样，但它们所要求的工作技能却是完全不同的。所以，我也不会因为被安了“高级开发者”的头衔而变成高级工程师。而且头衔具有“迷惑性”，同样的职位在不同的公司之间也不具备严格的可比性。

2. 每个人都会写测试代码
我的职业生涯的前半部分主要从事学术方面的工作。具体地说，有三年半时间花在了一个由公共基金支持的项目上，然后一年半是在大学里。我可以告诉你：学术界的编程与业界的编程其实完全不一样。
你的大部分时间并不是在开发应用程序，而是在写算法或者解析数据集。如果凑巧你是在开发应用程序，那么它很可能也只是个公共项目——要么是免费的，要么是开源的。免费的项目意味着你不一定会全力以赴把它做到完美。
毕竟，天下没有免费的午餐。
后来，我带着很多期望离开了学术界。
我期望能够在业界看到我想看到的东西，比如自动化部署、PR 和代码评审，以及高质量的代码！我坚信业界的每个开发者都会写测试代码。
但是，在我加入第一家初创公司的那一天，居然没有看到任何测试代码。前端没有，后端也没有，什么测试代码都没有。
更糟糕的是，没有测试代码也就算了，居然没有人认为缺少测试代码是个问题！带着一点点的天真，我就当是他们不知道如何为 AngularJS 编写测试代码吧。如果我教他们怎么写测试代码，或许这个问题就解决了吧。但我错了！几年之后，我们在添加自动化测试代码方面有了长足的进步，但与我最初想象的并不一样！
他们之前不写测试代码并不是因为不知道该怎么写，而是他们体会不到没有测试代码的痛苦，或者不堪忍受维护遗留测试代码给他们带来的痛苦。

我最终学到了什么

很多公司或者初创企业压根就没有测试代码，即使有，数量也很少。为了让产品尽快上市，或者为了生存，很多初创公司忽略了早期的测试。即使是那些看起来挺不错、赞助过开发者大会或开源项目的公司，它们的一些项目也都是只包含少量测试的大单体。
没有一家公司的技术栈是完美的。每一家公司都有自己的问题，都逃不过技术债务，关键在于他们做了哪些事情来解决这些问题。
如果你在某些问题上缺乏实际经验，但又固执己见，这样就显得有点傲慢了。我给人的印象是一个无所不知的人，并坚持一定要写测试代码，但我在这方面其实也没有大量的经验可言。坚持原则固然重要，但也要试着开放心态，并真正从别人的经验和角度来看待问题。

3. 我们比别人落后太多
这个与上一个话题有点关系。我们公司没有人写单元测试代码，但是其他公司的人会写的，对吗？
我读过很多博文，在 YouTube 上看过很多大会演讲的视频。好像他们每个人都能做出非常复杂且质量很高的应用程序，不仅性能好，还非常有趣。而我呢，能够赶在截止日期之前把能用的东西拼凑在一起，并让它们运行起来就算不错了。
基本上，我对这些公司充满了崇拜之情，但同时又对自己的公司和项目落于人后而感到失望。

我最终学到了什么

很多大会演讲只涉及概念验证，并不是真实的案例。如果你在某某技术大会上看到某一项很特别的技术，那并不意味着他们公司一定会在日常开发中使用这项技术。通常，演讲者所使用的演示 App 并非真实的案例，所以要注意区分它们。
处理遗留代码是很正常的事情。通常，人们会理所当然地认为别人的公司不需要处理遗留代码。但在技术大会上与那些大公司的人交流过之后，我发现，他们和我们的处境是一样的。有遗留代码是很正常的，相比从头开发 App，学会如何处理好遗留代码将会让你学到更多的东西，因为你会接触到更多你之前没有接触过的概念。

4. 代码质量最重要
在以前，我对代码评审的要求是很严格的。
至少，我对代码风格是十分挑剔的。缩进、格式化、命名——你最好要做得和我一模一样。代码评审不留下任何评论的几率跟中彩票的几率一样低。
想象一下，一个 PR 里有我的 50 多个评论，都是因为缺少分号！
因为我有一双老鹰似的眼睛，不会漏掉任何一个分号！

我最终学到了什么

做到足够好就可以了。代码质量“好”到一定程度，它给我们带来的收益是递减的。代码不需要完美，只要维护起来不像是一场灾难就可以了。通常情况下，有点啰嗦的代码读起来反而更容易理解。而且，“好代码”与“它看起来就像是我写出来的代码”是两码事。
看清整体架构比对细节吹毛求疵更重要。少量有问题的代码可以加以改进，而架构方面的问题会导致更大的问题。我想我在一开始就应该更加关注应用程序的整体结构，而不是代码的细节。
代码质量很重要，但请注意，代码质量并不是指我以前所认为的那些东西，比如 linting、格式化，等等。

5. 所有代码都需要注释
在加入第一家公司时，我需要处理大量别人留给我的代码。我在干第一份工作时有做过一些类似的事情，但后来都没有真正深入到已有的代码库，弄跟无头苍蝇一样到处乱撞。我宁愿重写所有代码，也不想一点一点去理清楚老代码是怎么写的。
但即使是这样又能怎样？一个 Ruby 程序员写出来的 AngularJS 代码，或者一个自认为自己很厉害的初级程序员写出来的代码，别人照样看不懂。
所以，我开始在所有可能的地方添加注释，给所有函数加了注解。
我学会了所有与 Angular 相关的 JSDoc 语法。我的代码行数因此增加了一倍，因为有太多的注释。

我最终学到了什么

有时候注释也会撒谎。有人把注释当成了万灵丹。“我们需要注释！”不要因为写注释很难，就认为完全不值得这么去做，我只是认为要用正确的方式给需要注释的地方加上注释。错误的过度注释只会给后面修复代码 bug 的人添加更多的麻烦。
在适当的情况下用自动化代替注释。自动化测试代码通常不太会出现不同步的情况。我开始专注于编写清晰的测试代码，当其他人在阅读我的代码时就可以知道这些代码是干什么用的。

6. 技术债务是不可容忍的
在很长一段时间里，我认为任何“混乱”的代码都是技术债务。技术债务这个东西很有意思，如果你让不同的人例举技术债务的例子，他们会给出不同的答案。
因此，作为一个将“混乱”代码视为技术债务的人，我会立即使用最严格的方式消除这类代码！
我曾经花了一整个周末修复了 800 个 linting 错误（当然是在出现自动修复工具之前）。
可见我是一个多么神经质的人。

我最终学到了什么

不完美的代码不一定就是技术债务。一些看起来不是那么好的代码并不意味着它就是技术债务。技术债务会以某种形式阻碍项目的进展，或者让你很难对项目做出变更。如果代码有点美中不足，就放过它们吧，花太多时间清理它们可能不值得。
有点技术债务是正常的。有时候我们不得不走捷径，因为时间紧迫。有一点技术债务是没有问题的，只要记得回过头来把这些债务还掉。如果你想让你的项目零技术债务，那么你很可能把代码本身凌驾在交付价值之上。我之前就是这样的！

7.“高级开发者”就是指编程最厉害的人
因为从小就写代码，编程对我来说就像呼吸一样。写代码就像在写博客或者邮件，通常比别人更快给出解决方案。
在很长一段时间里，我一直在思考这个问题：这就是成为高级开发者要做的事情的吗？
难道不是这样吗？因为头衔是叫“高级开发者”，又不是叫“高级沟通者”或者“高级项目经理”，不是吗？我不知道要成为高级开发者，除了编程还需要其他什么技能。

我最终学到了什么

高级工程师除了编程，还需要发展其他技能。与我已经掌握的技能相比，我还欠缺的技能简直就是一个天文数字。从通信、依赖管理到共享上下文、项目管理、估算，以及与非开发人员合作。这些技能是不太好量化的，所以需要更多的试错才能获得。
不是每个人都能成为“高级开发者”。资历是多年经验积累的结果，但这也只是必要条件，而非充要条件。而且你的经验还得是用得上的，你要把它们内化了，并可以用来解决问题。有时候，一些很重要的经验需要一年甚至更长的时间才能显化出来。
在某些领域，我们仍然很嫩。不管你的经验多么丰富，总有很多东西是你不懂的。承认自己的“无知”是第一步，然后向更有经验的人学习，争取把中间的差距弥补起来。

原文链接：
https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/

你也「在看」吗？