0%

2020 年终总结

又到了一年的结尾,大家今年过得如何呢?

2020 年,对于全世界而言会是非常不平凡的一年。肆虐的 COVID-19 疫情使世界经济受到了重大的打击。由于病毒的威胁,人们或主动或被迫接触 Work from Home(WFH)这一全新的工作形式。尽管,由于仓促上阵,人们没有掌握正确的 WFH 的工作方法,很难在 WFH 环境下发挥 100% 的工作效率。但是,这次突然的检验会暴露很多现有实践与工具的问题。WFH 是一种非常具性价比的工作方式,我看好 WFH 的未来。

各国对 COVID-19 疫情应对的方式不同导致了疫情发展的结果也不同。率先控制疫情的国家将会吃到后疫情时代起步早的红利。世界上巨头国家力量的相对变化到底会对人们的生活造成什么影响?这又是一个非常值得关注的发展方向。

2020 年是一切皆有可能之年——美国总统特朗普未能在大选中连任、英法美首脑确诊感染 COVID-19、桐生可可涉台问题导致 Hololive 被驱逐出中国市场等等。不禁令人感叹 2020 年真是魔幻的一年啊。

Life!

第一次完全独自一个人生活,有了足以养活自己的收入,两件快乐事情重合在一起…咳咳,就不咏唱圣经了。今年在生活中算是圆儿时梦的一年。

在大概初中的时候,我就拥有了一台自己的 PC。那是我爸从附近网吧淘汰的机器中淘回来的电脑。CPU 是一颗 Intel 赛扬处理器。在那台电脑上打一些大型游戏非常的卡。那时我非常沉迷《微软模拟飞行 2004》(也被称为 FS9),基本上只能跑出 20FPS 左右的帧率。这个习惯也因此培养了我现在 「10 帧能玩,20 帧流畅」的低要求。后来《微软模拟飞行 10》(FSX)流行起来,当时的主流配置都无法满足 FSX 的要求,更不用说我那赛扬老机器了。因此,我儿时最大的愿望可能就是拥有一台能够流畅运行 FSX 的 PC 了。

微软模拟飞行 2004 启动封面

在今年里,乘着 AMD YES!的风潮,我终于拥有了一台高性能的 PC。3900 + 2080Super + 32G 足以流畅运行市面上所有 3A 大作。初次之外也购置了 Honeycomb 飞行摇杆、节流阀与脚舵三件套。终于(在硬件上)成为了键盘飞行员(笑)。完成了儿时的愿望。另外值得一提的是,2080Super 却是被老黄暗算了啊。

Work!

2020 年是我作为全职前端工程师的第一年。由于所在的组是业务的第一线,这一年里主要的精力都投入到了这种业务之上。这一年在工作中的体会有两点:一是业务逻辑抽象的困难性;二是开发方式上的随意性。

业务不像理论有缜密的逻辑。业务是谈判、妥协与实验的产物。代码中充斥着特例,给抽象带来了很大困难,因此很难有业务逻辑上的沉淀。很多时候,我们都在重复造轮子,工作在编程语言与框架提供的最低的抽象层级,开发效率上难以提升。

在公司业务中开发方式是随意的。你可以使用任何开发方法论去开发一个功能。一个功能可以没有具体的结构设计,在开发过程中可以随意发散。最后的产物可能是一个功能完好,却很难重用与扩展的软件。另外,在开发过程中很少有单元测试与集成测试,使得后来人几乎无法重构,渐渐项目代码就腐化为了臭不可闻的遗留代码。

做的不好的地方

前几天和朋友开玩笑说:「2021 年的新年愿望是写完 2020 年的年终总结,2020 年未完成的愿望是写完 2019 年的年终总结」。的确,去年我没有发布 2019 年年终总结。但是很遗憾没能够完成它。它还躺静静地在我的草稿箱里。2020 年中,做的不好的地方可以总结为:

  • 没有计划性
  • 没有建立反馈

弃坑的总结

没有计划性

由于年初没有建立目标,可以说今年我是没有任何既定目标,在盲目地摸索。没有目标很爽,因为我无法得到一个「控制信号」 ,结果怎么样都好。但是长期而言,没有目标是很危险的,就像前面所说的随意发散的软件,没有目标的人非常容易沉沦与腐化。因此,明年一定要改变这一现状。

没有建立反馈

一个良性的渐进改良过程离不开正确的反馈。比如,目标是提高编码效率,首先我们需要定义「编码效率」这一概念的具体度量指标,是完成一个需求的平均天数?还是每日编码的平均行数?然后,通过实验备择的改良方式,观察备择方式对指标的影响,从而做出决策。但是,在今年,无论是生活还是工作中,都没有能够建立起正确的反馈渠道。因此无从对生活方式或者工作方法进行改良。久而久之就会一直陷在一个效率较低的方法论里。

2021 年的新年目标

谈到将要到来的 2021 年,为了终结「没有计划性」这一现状,为明年立一些 flag 就成为了 2020 年最后的重要工作。我为明年挑选的 flag 大概可以列为:

  • 基于 Jest 与 Cypress 的前端单元测试与 E2E 测试的系列教程;
  • 参与开源项目,向知名开源项目提交至少一个功能性或者修复性 PR;
  • 至少发布 12 篇有质量的技术文章
  • 掌握系统化的开发方法,并熟练运用于日常开发中;

今年,我在前端工作中实践了 TDD,使用了 Jest 与 Cypress 对前端项目编写了完整的单元测试与端到 E2E 测试。在实践中,收获了很多经验,也踩了很多坑。我认为任何严肃的软件项目都应该有一套完整的测试用例。我希望能够将这些经验系统化起来,形成一个系列文章。帮助软件项目逃离祖传代码的诅咒。

作为软件工程师,参与高质量的项目无疑是成长最快的方法。而在软件领域,能够参与的最高质量的项目无疑又是一些知名的开源项目,如 Node.js、React、Vue 等。这些项目支撑了全球数以亿计的前端业务。从中可以一窥究竟大型项目的组织、设计思路以及工程实践。对于工程师而言,这些经验是不可估量的宝贵财富。

第 3 个 flag 是「至少发布 12 篇有质量的技术文章」。在这里,「有质量的技术文章」指的是由自我思考得出来的具有严谨逻辑的技术文章。在工作中,我发现「输出观点」对于工程师是非常重要的。然而,没有人会认同毫无根据的观点。要「输出观点」,严谨的逻辑是必要的。锻炼逻辑,最有效的方式可能就是写文章了。

最后一个 flag 是「掌握系统化的开发方法,并熟练运用于日常开发中」。在前面,我也提到过,在公司中开发方式一般是随意的、不成系统的。随意的软件设计导致了成品代码耦合程度高,难以维护。在 2021 年,掌握系统化的开发设计方法,从像 Code Complete 这样的软件设计经典中取经,将这些标准流程用到日常的开发实践中。提高软件架构设计的能力。

在文章的最后,祝愿大家接下来的 2021 年里身体健康,万事如意。希望席卷全球的新冠疫情能够平息下来,世界各地的人们的生活能够恢复正常。 Everything will be better.

欢迎关注我的其它发布渠道