创业前期的技术债与交付速度 0


cucumber

 

在创业初期,创业团队的首要任务是活下去。此时团队没收入,要么没工资,要么烧着创始人自己的积蓄,要么烧着第一笔天使投资(有的团队干脆接点项目,用项目先养着)。总之,大家每天都是屁股后面点着火,只能不停的往前冲,用最短的时间获取用户并产生价值,要么转化为收入,要么吸引到更多的投资。这可不像在大公司里做产品,有的是时间多次确认需求,评审设计和代码,许多人投入到多轮各种测试中,可以悠哉的慢工出细活。创业团队只能快速的上线,收集反馈并再次上线,迅速的推进业务。因此创业团队的压力是极大的。

这就要求创业团队有极高的交付速度,这意味着在短时间内快速的完成功能的设计,编码,测试并上线。可是你压力再大,再怎么拼命加班,获取更多的工作时间,你完成功能总的工作量并没有减少,还是不够快。于是你为了降低工作量开始妥协,妥协什么呢?主要是质量。这里是包括外部质量(用户可感知的)和内部质量(代码的质量)。当然对于外部质量,一般创业团队还是会很注意的,但还是会妥协一些交互的质量;对待内部质量,呵呵,创业团队就不那么客气了。就别提那些测试驱动开发(TDD),验收测试驱动开发(ATDD)了,包括单元测试在内的各种自动化测试都几乎没有,代码本身的设计和可维护性等质量那可谓是岌岌可危,各种基础设施和自动化脚本也十分有限。于是产生了大量的技术债。

技术债这种东西看起来不痛不痒的,别说创业团队了,就算是很多大公司都不太在意。但是累积到一定程度,它会逼你一次性还清,比如把某一个模块甚至应用推倒重来。它主要体现在几个方面:

  • 代码质量差。代码可维护性低,修改或添加功能变复杂。代码中各种臭味,常见的就是大量重复代码,或是一个方法翻几页都看不完。
  • 缺少自动化测试。包括单元测试,业务自动化测试,集成测试,兼容性测试,性能测试等等。自动化测试最直接的好处是改代码时有没有破坏已有逻辑可以迅速知道。而特别在创业前期手工测试力度不是那么强,很少团队能做到频繁的全回归。回归质量基本靠祈祷。
  • 缺少基础设施。包括自动化部署等在内的各种自动化脚本,以及基础设施,比如CI系统监控质量。

这些技术债给创业团队带来的影响主要是两方面:潜在的质量风险,难以进行回归测试;交付速度逐渐降低,高速的交付难以持续,只能开始招募更多的人。

然而创业初期的业务又是十分不确定的,许多业务还在不断探索中,那意味着今天做的功能,过两天也许就发现已经不再需要。那代码写的再好,自动化体系构建的再完善,都不会给创业团队带来更多的收益,只会徒增成本。

创业团队需要衡量偿还技术债的中短期收益,从中做出选择。我的判断原则是从快不从优,对团队交付速度有影响的技术债优先偿还,并且只选择最简单的方式,而不是最好的方式。

  • 与业务相关的逻辑代码单元测试全覆盖,其余的诸如如前端展现逻辑以及状态持久化,只需抽取部分复杂逻辑用单元测试覆盖。
  • 对主要业务的基本场景做端到端的自动化测试,确保业务的稳定。
  • 代码随时随地持续重构,主要修复显著代码臭味,如重复代码,长方法。另外代码耦合度降低到以上单元测试可测即可。
  • 自动化部署脚本只需完成系统的部署,环境的搭建可以使用虚拟化的镜像。
  • 手工频繁运行自动化测试取代CI系统,其它基础设施尽量全部使用第三方服务,即使是收费的,这些费用比完全自己开发还是低不少的。

 

2.pic

 

易伙的在开发过程中就遇到了这样的选择。易伙的在优化前端的时候,选择使用React.js。然而React.js对我们来说是一个相当陌生的技术,一切都在摸索过程中,单元测试就更加麻烦了。但是要保证在开发过程中的质量,需要有自动化测试覆盖,我们采用Cucumber模拟用户操作浏览器的方式来测试,跑通所有基本场景,单元测试只覆盖后台的逻辑。这样基本保证所有代码都有自动化测试覆盖,业务的稳定性是有保证的。

 

1.pic

 

 

这样我们就有信心快速调整系统,快速响应用户的需求了。早期用户对于创业团队十分重要,当用户提出一个想法,创业团队迅速响应立刻完成开发,运行自动化测试并自动部署上线,马上让用户用到,这会让用户十分的爽,这样用户会越来越信任团队,从而更多的使用提供反馈,用户的粘度也会上升。

扫描二维码分享这篇文章吧:

QR:  创业前期的技术债与交付速度

发表评论

电子邮件地址不会被公开。 必填项已用*标注


− 五 = 4