跳出弱鸡循环

本文的后续:跳出弱鸡循环2

昨天的直播中我提到了广泛存在于工作两三年的Java开发者身上的一个情况,我们叫它“弱鸡循环”:

while(做弱鸡业务){
    薪资低;
    难跳槽;
    幸福感弱;
    成就感弱;
    技术提升慢;
}

结束之后有个同学跟我私聊,提到这个循环,问我怎么办。她(嗯,是个有上进心的妹子)工作三年,在某不知名小公司写Spring的后端代码,问我,自己应该怎么提升。

我想了想,问,你们平时开发完了,怎么测试。

她说,开发完之后会研发自己跑一遍流程,保证没有问题之后才能上线。

我说,也就是说,没有自动化测试了?

她反问,什么是自动化测试?

这是很多公司(甚至包括阿里这样的公司)的典型开发流程:一堆人吭哧吭哧写完代码,发布到某个环境上,找一堆人来点点点,没问题,发布上线。我在阿里呆了两年时间,一个测试也没有写过。

我告诉她,对于这种典型的情况,一个放之四海而皆准的方向是,尝试对你们的Web应用添加自动化测试。终极目标说起来很简单:你们的应用上线之前,应该跑一个命令,不需要任何手工测试就可以放心上线。

先说好处:

  • 方向明确。很多人谈到工作之外的“学习”或感到十分茫然,因为他们不知道要做什么。刷题?又难又坚持不下去。看书?不知道看什么,看完了做什么。而我上面说的这件事,目标非常明确,虽然看上去很难,但是却是十分可行的。关键是,它可以分解成很多的小步骤,循序渐进地完成。
  • 贴近实践。刷算法题之类的“学习”方式在实际工作中用处不大,看上去非常像是……屠龙之技。如果你不是为了进微软这样的公司,大可不必狂刷面试题。
  • 可行性高。很多人想要在公司发起各种各样的技术革新,面临的最大问题是,老大不同意。老大说,现在跑的这么稳定,换了你说的技术,出了问题怎么办?当然,你要是像我一样对某种新技术了如指掌(我指的是Gradle),那么你大可以狂妄地把担子揽过来。进行自动化测试的好处是,你不需要对生产代码做任何变更,你不对别人的工作造成任何影响——一切都可以发生在本地。一旦你完成了这项工作向别人展示,一个命令可以完成之前几个小时的手工测试的时候,相信我,不会会有人再愿意回到人工测试的时代。人们拒绝新技术的唯一原因是因为他们还没有看到新技术带来的价值。
  • 有助于职业发展。做完这件事情,你猜你的同事会不会高看你一眼?你猜你的老大会不会请你分享你的成就?你猜你能不能放到自己的简历里,在下次跳槽时大吹特吹?

再说方法。我自己是Gradle的核心团队开发,因此对自动化构建非常推崇。Gradle自己从自动化测试中受益无穷——每月的下载量在两百万次以上,但是核心团队只有不到十个人。如果没有数万个自动化测试的保障,我们一定会疯掉。

如果你的公司符合以下条件,那么本文提到的方法百分百适合你。

  • 一个庞大的Web application,连接了奇奇怪怪的数据库。
  • 你的日常工作就是实现各种各样的需求,会熟练的:
    • pom.xml里引入依赖
    • 建立、注入各种各样奇奇怪怪的Cotroller/Service/Dao
    • 写SQL取数据,进行各种处理,返回给前端
  • 每次发布之后都在部门群里大吼一声:我们在测试服务器上部署了新版本,大家快去用鼠标点点点测试啊!

现在,你要跳出弱鸡循环的第一步,你需要:

  • 第一步,去看一下《Maven实战》,了解一下Maven的测试是怎么工作的。之所以让你去研究Maven,是因为你们这种系统,99%不会采用Gradle这种新技术的。
  • 第二步,写第一个测试,代码如下:
public class MyTest {
    @Test
    public void 跳出弱鸡循环() {
    }
}

是的,Java代码是可以用中文写的。

  • 第三步,去搞一份你们线上数据库的表结构。各种数据库都有相应的命令dump表结构。有困难的的话,手写建表语句。
  • 第四步,本地用Docker启动一个临时的数据库。
  • 第五步,去研究一下flyway,用自动化方式把表结构灌到这个临时数据库里。
  • 第六步,去了解一下你们的应用是怎么部署的,你们上线的应用不可能是通过在IDE里面点绿色三角来部署的。把部署的命令行要过来。
  • 第七步,研究一下这个命令行,尝试在本地启动起来。碰到数据库没起来的问题,就把连接串改成刚刚那个Docker的临时数据库。
  • 第八步,你平时怎么在网页上点点点测试的,把它翻译成Java。比如你平时会手工测试登录接口,那就用HttpClient写一段代码,模拟登录。
  • 第九步,把上面这些整合起来:
public class MyTest {
    @Test
    public void 跳出弱鸡循环() {
        启动测试数据库();
        把表结构灌进去();
        本地启动应用();
        自动化方式测试接口();
    }
}

碰到任何问题的话,就一点一点地解决。在这个过程中,你会发现自己达到了你最初的目的:提高自己。必须说一句,这其实不是非常科学的集成测试,真正的集成测试应该把相关的步骤绑定到pre-integration-test/integration-test之类的phase。但是……反正我写这么多,99%的人是不会坚持下去的,所以也无所谓了。如果你真的做完了我说的这一切,私聊我,我告诉你应该怎么继续改进你的集成测试流程。

虽然这些步骤看上去很简单,但实际上每一步都可能要花掉你几个周末的时间,因此,请做好思想准备,坚持不下去也无所谓(毕竟99%的人是坚持不下去的),没关系,在弱鸡循环里呆着吧,反正,你不是一个人。

====================================

感觉很多人误解了我的意思。我这篇文章是写给那些“想要持续学习提高自己,又不知道去做什么的人”看的。做这些事情的时候不要把它当成工作,当成业余对自己的一个挑战——换句话说,不要抱着给老板干活的心态去做,抱着“学习充实提高自己,顺便改进一下工作中的流程“的心态去做。下班后做,周末做,如果能做成当然好,做不成的话也没关系,没人责骂你——起码它证明了一点:你并不是学习的那块料。

====================================

2019.6.12 更新

我不知道是因为我没写清楚还是没人仔细看文章,评论区各种群魔乱舞。

我要表达的意思不是“每个人都应该写测试用例,所有的项目都应该保证测试覆盖率”,我想要表达的是,“当你觉得技术上遇到瓶颈的时候,可以通过学习和实践自动化测试,来补全自己在相关工程领域的技术短板,提升自己的技术能力”。还有人说,这个技能的市场价值极低,对此我不敢苟同,我个人从测试中学到的不仅是写测试用例的能力,而是一整套的工程化、自动化的能力。质疑这一点的,我非常建议你先去写几万行的测试再来讨论。

====================================

2019.6.27更新

本文的后续:跳出弱鸡循环2 其中介绍了另外一条跳出弱鸡循环的捷径

编辑于 2019-06-27

文章被以下专栏收录