前言

大家好, 我是孙高飞, 目前在第四范式质量部中负责工程效能方向的工作。 我在这家公司有 4 年多的时间了, 刚来的时候整个质量部加上我也只有 2 个人。 基本上我是看着质量部一点点成长起来的。 而在去年年末的时候,经历了 4 年时间发展的质量部也是终于正式成立工程效能部, 我也是彻底告别了业务团队,作为工程效能的负责人开始了新的工作。 而回顾 4 年前质量部刚成立的时候, 我们做出了一个大胆的决定,那就是从一开始就以测试开发的标准来进行招聘工作, 即便是业务测试人员也要有自己构建自动化测试和开发测试工具的能力, 最终组建一个全员测试开发的技术团队。 这也是为什么 4 年来我们在技术上的实践好像上了高速公路一样。 而我个人也拒绝了管理岗的位置,选择在工程效能团队继续在技术领域深耕。 所以今天这个关于一些类似职业发展的分享呢,可能会跟其他人都不一样。 其他来分享职业经验的人呢,可能已经走到了一个比较高的位置上了, 分享的内容也是从很全面很综合的能力上表述的。 而我呢没有选择做管理岗, 所以虽然我是公司第 28 号员工,但是到现在我的 title 也只是质量部的一个测试开发工程师。 而今天分享的内容也主要是聚焦在技术能力这一个点上开展,并且我们今天不去划分什么能力模型, 技能体系,就单纯的从我们怎么去好好的做一个技术岗位上说起。 我觉得这也一个比较好的角度, 因为我们大多数人还都是普通的员工的,而我这已经逼近 35 岁大坎的一线技术人员今天就来分享一下我这 10 来年的一些经验, 希望能对大家有帮助。

做加法

首先我们讨论一个很普遍的问题, 当我们进入这个行业的时候,我们该怎么做。 现在比较主流的声音是我们要深耕一个领域,在一个领域内成为专家。 这句话是对的,但它有一个前提, 就是你已经在这个行业里摸爬滚打到了一定的程度了, 你确信自己擅长什么,自己想做什么。 而初出茅庐的人往往面对的是一种很迷茫的状态, 这个时候你什么都没见识过, 在这种状态下你怎么能确定你未来要伴随你一生的职业规划是什么呢?所以这里我可能会提出一个不太一样的声音。那就是刚进入这个行业的时候,可以不用急于去专研某个领域。 白岩松老师曾说过在 30 岁之前要玩命地做加法,要去尝试,因为你不知道自己有多少种可能,你也不知道命运将会给你怎样的机缘,所以,不试试你怎么知道呢。

同时这也是我对技术的态度,多去尝试不同的技术,不同的解决方案, 你会发现不一样的天空。 4 年多前一次很偶然间的想法,我想试试最近不少人在谈论的 docker, 就是这么一次很突然的想法, 造就了质量部后面大量的 docker 和 k8s 的实践, 也造就了我后面一直以容器生态为核心向外扩展的技术栈, 所以不去试试,你可能都不知道一门技术能给你带来多大的改变。我一直认为最可怕的不是我们学不会一样东西,而是我们跟本不知道这样东西能做什么或者根本不知道这样东西的存在。 在这个行业里, 很少出现靠个人努力学不会的东西,只要你肯砸时间耐心的去学, 总有学会的一天。 但是如果你墨守成规, 本着现有的东西已经能满足业务需要的心态而把自己与其他技术屏蔽掉。 这样不论新的技术有多好,能提高多少效率,你都不知道了, 那你又何谈进步呢。 不要把自己限制在一个小的圈子里, 因为这个小圈子没办法养活你一辈子, 技术永远在更新在淘汰,永远都有更好的方案出现。 所以多尝试,不是一件坏事。

做减法

刚才说的是给自己做加法, 尝试更多的新的可能性。 但是到了一定的程度后, 要学会给自己做减法。30 岁,是你在做了一系列加法和四处乱跑之后,要做一次减法的重要时间,不然就晚了。 为什么要做减法,因为你不是所有的都适合,也不是适合你的所有的事你都该去做。八条线栓着你,你能跑多远?这 8 条线可能还会互相牵制。 我在之前面临了一个选择,我到底该做什么。 尤其是当时从产品上我再推进数据治理方案, 业务上我带着一条业务测试团队, 而技术上我当时也正在跟 k8s 较劲的正起劲。 所以当领导来找我问我要不要转管理岗的时候,我陷入了沉默。 我给了自己一周的时间来思考,我自己问自己,我可以做很多东西,可以做技术,可以做产品,也可以做管理以及其他一切好玩的东西。但是最后我对自己说,我发现自己只能做技术, 也最该做技术。 而我能拥有今天的一切,都是因为那时做的减法。

当然做减法不是只剩下一个技能其他的都减掉。 我们说的深耕也是在一个领域内的深耕而不是在一个技能上的深耕,这中间是有很大的差别的。不少人都很喜欢走极端, 你说要深耕, 要做专家, 那好,我就奔着一样技术使劲,除了这门技术其他的我都不管了。 这就是一个极端,这就好比独孤九剑, 独孤九剑专破天下武功。 有破刀式,破剑式,破气式,破掌式等一共 9 式, 每一式又有诸多变化, 比如破刀式里分为单刀、双刀、柳叶刀、鬼头刀、大砍刀、斩马刀种种刀法。 如果你只学了破刀式里的单刀, 就算你练的再怎么出神入化,对敌的时候人家拿一斩马刀出来, 你怎么破? 所以其实我挺不愿意回答社区里总有人提问到底是 java 好还是 python 好的问题, 说的好像我们只学一门语言就可以了一样,你 python 用的再好当你面对容器领域的工具开发的时候你敢不用 golang 么, 你 java 使的再溜当你要写一个 web 的时候你能不用 js 么?我们要知道对于一个好的测试开发来说,同时掌握几门语言和技术是完全是必要的。因为你面对的是各种不同的场景, 这不是一招鲜都解决的。

所以我要强调我们要解决的是这个领域内尽可能多的问题, 而不是只解决一个问题中的各种细节。解决不同的问题可能会用到不同的语言不同的技术, 这很正常。 不要陷入一个极端的状态我要做专家,我要把所有精力都放在一样事情上, 然后专到一个特别细节的东西上去了。 我见过有同学就冲着一个接口测试使劲,一做就是几年,你一问就说我接口测试做的特别好, 我开发了什么什么框架, 什么什么平台。 但是你接口测试做的再好,它也只是接口测试。 它也只是这个领域内庞大的测试体系中的一环。 所以一个领域和一个技能的差别我们需要明白, 如果你只专注一个细节, 那就只能偏安一偶做个执行者,因为你撑不起这个团队, 你能解决的只是这个团队要面对的形形色色的问题中的一个。 所以如果你想走的更远, 就去关注你所在领域里更多的问题。

几种不好的思维

走技术路线当中最不好的几种思维:

广度是深度的附属品

可能我一直都在表达一种不太一样的声音。 基本大多数人都会告诉你要做专家,这句话是没错的, 但是这个专是有一个度的,不能专的太窄, 你专的越窄,你的路就越窄。 能力越大责任越大, 你能力大,就应该去负责更多更高维度的事。 这时有人可能会说我们不是要一直专注于深度么, 怎么听上去好像你要让我们往广度发展。这里我要表达一个观点就是我一直认为广度是深度的附属品, 有深度的人在广度上一般都不会差。 我们说的深度的是深入这个领域里解决这个领域里足够多足够深的问题,而在解决一个又一个的问题的时候,我们就会接触各种各样的技术。 我给大家举个我自己的例子。 熟悉我的人都知道我很多的精力都在容器化的路上折腾,我们的整个产品架构,测试环境,测试服务等在容器化的路上历经了 4 年的演进。 从一开始的单机裸 docker 运行,到现在的 k8s 集群调度, 我们所精进的不仅仅是容器技术本身。 容器这个领域会面临很多问题。 我来列一下。

上面是我列出来的一些主要的问题, 在解决这些问题的过程中,可以看出来我的主线还是容器领域的应用, 一开始是产品的编译,部署这种常规的 k8s 应用,到后面解决 k8s 周边的类似监控场景, 使用 k8s 开源的 client 定制 exporter,定制运维工具。 在到后面研究 k8s 源码,自己开发 k8s 的 operator 往容器中注入故障。 这一切还是围绕着 k8s 一步一步的深入 k8s 的各类场景中。 而在这一系列过程中,我们为了更好的解决问题而学习应用了 python,golang,js,typescript 4 种语言(如果算上其中编写测试用例的语言的话,那就还得算上 java),涉及前端,后端, CI,监控等各种技能。 所以我说广度是深度的附属品,因为只要在这个领域里解决足够多的问题,你必然就要面对形形色色各种不同的技术。

放弃偏见和强烈的个人偏好

我这里还想表达一个很重的观点就是在技术上尽量的不要带个人的喜好憎恶。 而带着强烈的个人喜好的工作方式其实是很危险的。 我见过不少人强烈的对技术有非常大的偏好,比如我见过只喜欢 Go 语言的,只喜欢 python 的,他们非常不喜欢其它的语言, 我也见过只喜欢做接口测试强烈排斥 UI 自动化的。 或者只喜欢写服务端的强烈排斥写前端的。 这些个人偏好足以让一个未来会很优秀的人被毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。 他把自己的技术栈封闭起来,自己封闭了自己的视野。偏见和不开放,对一个人的限制是真正有毁灭性的。主动让自己成为一个瞎子和聋子,主动把自己的能力阉割掉,这是一件很令人痛心的事。 要知道当你放弃一门语言或者一门测试类型的时候, 你放弃的是其对应的一整个的生态。 要记住技术是不分三六九等的,他们是解决问题的工具,就算很多人觉得这个技术再简单再 low,但是遇到相应的场景的时候,你还就只能用它。 同样在技术人眼里,问题也不应该分三六九等的, 不管是简单的还是困难的, 最终你都是要去解决的。比如你不能觉得 UI 自动化 low,就不去做它,因为做好 UI 自动化是大部分团队要面对的问题, 你需要为你的团队负责。 如果你的目标是能在技术上成为这个团队的领导者, 那我希望大家能放弃各种偏见和优越感。

如果陷入了这种带有偏见状态,那你一样撑不起一个团队。因为你这个人都已经在搞闭关锁国了,你怎么能在技术上去引领一个团队的发展呢。 你怎么能解决这个团队遇到的不同的问题呢, 就像我刚才拿我自己举的例子。 解决这一系列的问题涉及了多种语言及其技术栈, 而这种需要多种技术栈配合解决的问题,才正是我们工作中总会遇到的。 可能大家会说你不用一个去做这些事啊, 去指派会这些其他技术的人一起工作不就好了。 但是我想说的是哪来的那么多人让你指挥呢, 你在做事情的时候, 尤其是刚开始做这些事的时候, 哪来那么多资源投入进来呢。 做测试开发这个职位, 其实大多时候我都是习惯靠自己的。当然说到这里也可能会有人说我刚才举的例子中, 感觉我干的好多事情不是 QA 应该做的, 应该是 devops 或者研发做的。 这也是一种限制自己的行为, 你把自己限制在自己认为的 QA 的职责边界中, 放弃了去接触新的技术和解决更复杂的问题的机会。 而我认为技术的深度往往取决于你平日里解决的问题的复杂程度。只有经历过足够复杂的场景,才能锻炼出足够专业的能力。

机会是留给有准备的人的

可能有些同学会说我遇不到复杂的场景, 或者能锻炼技术的工作岗位轮不到我。 这是一个很现实的问题, 当你的技能不够好的时候,相应的工作岗位或者机会可能是不会选中你的, 这也是为什么我们要在平时就去主动学习的原因。 当你的技能不足以胜任你心仪的工作岗位的时候, 你就要努力的让自己的水平无限的接近那个岗位的要求。 这样机会来的时候你才能抓的住。 就如在我们这里是 QA 先搞了 k8s,推行了测试环境上 k8s 集群的实践, 而没有把这个任务交给 devops,直到现在我们这的 k8s 集群都是我们自己搭建自己维护,每个项目的一整条持续集成的 pipeline 包括从环境部署到最后的质量看板的负责人都是 QA。 那当初为什么没有交给 devops, 也很简单, 因为当时公司规模小根本没成立专门的 devops 团队。 打从以前就是 qa 跑来主动承担了研发和测试环境的搭建和维护。而这个没有人来做的现状就是机会。 但是在这个机会的背后, 在我去找 boss 要接下来 k8s 这个活的背后。 是我已经私下学习了 k8s 整整 3 个月并且我自己拿 k8s 重新搭建一套测试环境。 所以这个机会来的时候,我才能抓的住,否则的话,一个对 k8s 一点都不了解的人跑去请命要揽下这个任务,那可能就是个笑话了。 机会永远是给有准备的人的, 不想努力的去准备,还想让机会像天上掉馅饼一下砸中你, 那是做梦。 我听过好多人说我没有环境锻炼技术,只要给我个机会我能怎么样怎么样的。 或者说只要给我个机会我一定好好努力学习工作等等等等。 但是我都一直特别想说一句, 凭什么呢。 凭什么这个机会就要给一个什么都不会的人呢? 我们为什么不招一个有经验的或者起码是自学过懂一点的呢。 所以有些时候, 我们真的要改变一下思维方式, 不是有了机会才去努力, 而是努力了才能有机会。先尽人事,才能听天命

永远要留给自己学习的时间

说到学习就要聊一下我们总会说到的问题, 就是很多人忙到了没时间学习的程度, 他们一直都在加班。 这个问题也很现实。 但是没办法, 我们一定要想尽办法留给自己学习的时间,减少一点娱乐活动,少打一点游戏,多留给自己一点时间学习和思考。这也是为什么我每到一个项目, 可能第一件事就是开始想怎么做自动化。 一个项目比较好的状态是: 投入自动化项目-- 节省人力成本 -- 有更多的时间去投入到技术项目来 -- 节省更多的人力成本 -- 有更多的时间去做别的事情, 良性循环。 而比较差的状态是:自动化投入不够 -- 项目加班 -- 加班太多没时间做自动化 -- 继续加班, 恶性循环。 恶性循环也称技术債。 你越是把自动化项目往后拖延,你的技术債就越多, 因为产品是不会停下来的, 它会一直向前走。 会有越来越多的功能被开发出来需要被测试。 你越是往后拖延,你就越没有时间去做你想做的事情。 所以要从一开始就想尽办法去挤时间去把自动化项目建设起来, 即便是多加加班。

亲自去做

最后我想分享的一个经验就要多去自己感受, 如果要开发一个测试工具,或者要在业务线推广一个自动化测试类型。 不要只去听业务线上的人说什么, 最好要亲自去业务去做跟一轮项目。 因为这世上是没有什么感同身受的, 我习惯亲自去感受业务线上的痛点,而不是听其他人描述。 沟通的再怎么顺畅都会有信息的缺失。 所以自己去测试这个任务, 自己去开发这个工具,自己去使用这个工具。 才能得到好的结果。

尾声

好了今天就讲到这里,希望这些经验对大家有用


↙↙↙阅读原文可查看相关链接,并与作者交流