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

阅读数:20396 2019 年 6 月 29 日

明年就是我的开发者生涯的第十个年头。整整十年!我有三分之二的时间都用在了 Web 开发上。在孩童时代,当其他小孩还在学习乐器或芭蕾舞的时候,我在自己的卧室里用代码编织了一个神奇的世界。为了给这十年来一个总结,我想分享一下我在过去的十年当中作为一名开发者的心路历程。

对于现今的初级开发者来说,或许他们会在这篇文章里找到一些能够引起他们共鸣的东西,或者让他们深受鼓舞的东西。对于现今的高级开发者来说,或许他们也有一些有趣的故事可以分享,因为他们都是过来人。

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/

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

Peter Cheung 2019 年 07 月 08 日 13:59 2 回复
香港IT业之严重腐败现象 大家好,我是来自香港的架构师,有十多年经验,现在我想告诉广大的内地同胞关于香港零Code PM的恶行。 零码PM就是一群完完全全不懂技术的IT经理(项目经理),他们占据了香港经理人数的99.5%,分散在香港不同的IT行业,例如政府,银行,大公司,中小企。他们不停向香港的年青技术人员散播编程没有用,编代码只是一条狗的邪恶思想,败坏香港技术风气,令香港IT振作不起来。他们用尽他们一切可以用的方法去奴役香港程序员,因为他们觉得他们是经理,技术人员什么都要管。 正因为他们完全不懂技术,基本上连for loop也写不出来,所以只能依靠一个“骂”字来管理团队,简单来说就是想dev team进入奴隶制,凡事不可以问经理,总之经理要他们干什么他们就只好干,干得不好一定不会是经理问题,所有错都是技术人员搞出来,他们要负上全部责任。零代码PM为了在年青技术人员表演自己对IT认识有多深,他们总会说自己ñ年前也是程序员,言下之意就是他们主动放弃编写程序而转做经理,做经理才是皇道,编码只是低能儿,智力一定有问题。他们提出此邪说完全摧毁了香港的IT传承,令刚出社会做事的年青人误信他们以为做程式设计师是不长久的。长远导致香港IT人才数目不足,社会技术气份无从建立等一系列的严重后果。零Code PM除了断交子孙这条重罪之外,他们更加犯下胡乱外判,胡乱采购IT系统等等恶行,令香港好多有源投放在IT的公司,他们所有项目仆街收场,最终吓怕老板,令他们再也不敢投资IT,令香港IT更加惨淡。 为了令内地IT业不受香港零码PM影响,请广传此贴。记好一点,一个香港PM如果去了内地工作,他可以​​干掉一百间内地IT公司,灭了几千个内地青年人对IT的信心,毒力非常强劲,请内地同胞小心!!!
Geek_68513e 2019 年 06 月 29 日 17:18 1 回复
最终衡量的成本和价值,所以才有梯队。 现在身边每天一群senior的人写单测真的是浪费,让找几个实习生跟便秘一样。。。
哈哈哈哈哈 0 回复
阿拉丁香油 2019 年 06 月 29 日 16:50 0 回复
写得很好
没有更多了