知乎版本

题目所述,就是我最近很久一段时间都在用来思考的问题。

先说下个人的背景,目前已经毕业三年,第一年主要做前端开发,大约在两年前,我的主要精力从前端转向了 Rust,而后又开始在公司参与开发 c++。

在这三年里面,自己持续面临着一个问题,这个问题就是,如何从一个繁忙而重复的工作中,持续提升自己的技术深度。

因为我发现,当在一个公司久了以后,随着参与的业务增多,问题和 OnCall 也随之增多,另外随着你对业务的熟悉,会有越来越多的新同学向你问问题。处理这些问题会占据越来越多的精力。当然,如果你比较“幸运”中途业务黄掉或架构彻底变化了,你去参与新的项目,有可能能获得一次接近重新开始的机会,但大多数时候,你可能都没有这么幸运。

当这些问题处理的久了以后,你会发现甚至连完成工作都需要加班来解决,就更没有时间来进行技术的提升了,长此以往,焦虑感便倍增。

不过,最近我在思考这些问题的过程中,也渐渐总结了一些缓解的办法,接下来便和大家进行分享。

这里的核心点在于,减少犯错误的机会,提高处理问题的效率,释放出自己的更多时间

1. 提高对代码的要求,写更好的代码

我最近处理的众多问题,粗略估算,有大约 1/3 都是由于开发者代码水平不足带来的技术债务(即代码逻辑错误、边界情况未考虑、性能与稳定性不足等)。

我这里主要针对的是 PC 客户端,还有很多问题和特殊机器、其他模块干扰项、硬件驱动等关系密切,如果是纯前端项目,这个比例只会更高。

因为写代码的时候,并没有采用最合理的方式,导致有出现问题的隐患,如果你的问题出现的概率比较高,大概率会比较幸运地较早发现,但如果出现的概率低,甚至灰度阶段都没有暴露,那么当初几行代码的问题,会让自己之后花加倍的时间来去处理,甚至还可能面临更多后果。

那么,如何让自己写出更好的代码呢,我认为可以做到以下几点:

  • 请熟读文档,比如如果是在开发 Vue 项目,那么请至少把 Vue 的文档看一遍,React 同理,这样你会更加清楚,框架到底提供了那些能力,什么时候使用更合适的 API 来完成一个目标。
  • 注重注释,对于一些特殊处理的情况,注释是很有必要的,最好附上文档,否则可能时间久了,自己都不知道为什么这样去处理,会让修复问题花费更多的时间。
  • 除非迫不得已,不要提交带有已知优化项的代码,例如重复代码并没有完全处理、代码在某些情况还可能造成问题。时间允许的情况下,一步到位,通常比分两次到位能节约更多的时间,至少能节约一次测试的时间,另外大脑的上下文切换还有开销。
  • CI/CD 的建设,保证合并的代码是能够编译的。
  • 对于前端来说,全部采用 Typescript,使用 ESLint 约束代码,禁止直接使用 JavaScript。
  • 团队需要建立 Review 机制,并且对 Review 过程负责。对于别人提交 Review 的代码至少需要通读一遍,避免基本的错误。

2. 日志是语言的另一面,也很能体现代码水平

这里的日志,指的是在用户使用过程中,实时上传的的或者离线的日志。

这里单独提一点日志,是因为在实际中,我们大约有一半时间在写代码,而另外一半时间在查问题,那么为什么就不能好好写日志呢?

“日志不足/没打日志,需要加日志进一步定位”。

不知道你在 OnCall 的过程中,是否遇到过此类回复,当然并不能说每次这样的问题都是开发者水平不足导致日志不全,但的确有很多情况是我们可以提前规避的。

那么一个好的日志应该是什么样的呢?

  1. 前提:废话不要多,能简写就简写,这是因为一般日志都是存在用户本地的,日志量比较大的情况下会影响用户的硬盘占用,当然日志本身的打印也是消耗 CPU 的。
  2. 关键路径的日志要有,可能出问题的地方不要存在侥幸心理,把日志打全,特别是不同负责模块之间衔接的日志,一定打全,这样之后甩锅的时候有实锤也会方便一点。
  3. 关键日志需要有关键字,方便后面自动化分析,毕竟,对于一个比较完善的项目而言,机器人分析日志甚至比人分析更为靠谱。
  4. 日志也需要向前兼容,最好不要对以前的日志进行改动,这点我们可能通常会忽略,如果没有必要,建议不要对日志进行大的变动,防止自动化工具和其他分析日志的同学不知情。

什么?你说你们团队还没有日志系统?

那么第一件事,就是要有一个完善的离线日志回捞系统或在线日志系统。

3. 打破边界有助于开阔视野,但是是否深入需要慎重决定

虽然有的时候,员工打破边界对于公司来书并不是一个好事情,但大多数情况来说,对个人还是会有所帮助的。

为什么说不是一个好事情呢,比如一个客户端的同学,去做 c++ 了,这个时候应该鼓励还是反对呢。实际上这个时候,他除了仅存的业务熟悉度和一些通用的编程能力,c++ 的能力也许就只有应届生的水平,如果从新招聘可能连初试都过不了。公司就必须要承担因为他的编程能力不熟练带来的效率损失,甚至因为更容易引发问题造成更大的损失。

为什么说,对于个人来说是一个好事情呢,这个主要体现在以下几个方面:

  • 在公司中大多数情况下都是多个语言的开发者相互配合的,而当你同时参与了你上游或者下游的工作,你会发现沟通会更加顺畅了,甚至自己也拥有了简单的处理需求和问题的能力,底气会高很多。
  • 在你学习多个语言的过程中你会发现一些精华的部分,比如通用的框架设计方法、模块组织方法等各个语言都是通用的,甚至有些代码你直接翻译过来就可以直接用了,这也可以让你更深刻地了解到哪些是编程的精髓。

当然,有的时候如果你跨界参与的太多,例如本身是一个资深的前端开发者,当你跨界参与了 c++ 开发,你会发现短时间内你的前端水平是在下降的,而 c++ 水平也没有达到独立承担工作的程度,这短时间内你的市场价值其实是有所下降的,这也是你需要慎重考虑到底要参与多少的原因之一。

4. 复杂系统的初始架构设计,可以作为一个最后兜底

实际上,复杂的系统大多一开始都不复杂,但是如何正确地预判系统的走向,设计出可以沿用很久的基础骨架、约束性强却扩展型足够的组件系统(即使后来来的人水平差也不至于写出太难维护的代码),以及和外界其他系统进行灵活的配合,是对水平有一定的考验的。

这里我以某视频会议 App 举例,其最开始只有视频+音频的简单能力,在此基础上,团队负责人设计并编写了基于 Typescript 的核心状态机、按照 minor repo 划分了主要模块,设计了 Store 状态存储,设计了一套 API 注入方式可以注入系统外的 API 等等。

这套架构沿用了三年,核心代码基本没有发生变化,功能上却新增了共享屏幕、共享网页、聊天/表情、标注/白板、远程控制、字幕/录制/翻译、日程会议、面试等若干重要的模块。

虽然实际上,随着后面的同学的增多,以及最初核心开发者的离职,开发人员已经几乎换了一批,但是这套代码和架构基本上没发生太多变化,也一直支撑着若干项目。

(p.s. 据说最开始参与设计的同学吐槽后面的维护有点渐渐跑题,但是整体还是可用性比较高的)。

如果没有一定水平,想必业务框架早就随着业务的变更重构过多次了,肯定会带来巨大的人力浪费。

5. 持续练习,持续关注行业动态

最后一点,持续学习,大概是程序员的宿命吧。

这里其实不用多说了,但是想提一点,其实有的时候如果你发现主动的持续学习会比较难的情况下,可以选择一种半被动的方式。

比如,每周给自己定日程参与 leetcode 周赛,你把它当作自己工作的无可推脱的一部分,这样持续几次,你就会慢慢习惯这个过程。


以上共勉。