搞个产品研发，还能搞出债务问题？
在产品研发过程中，我们常常只关注功能的实现，却忽略了隐藏在背后的“债务”问题。测试不充分会积累测试债务，代码结构不健壮会形成开发债务，这些问题随着时间推移会越来越难以解决。本文将探讨如何通过测试驱动研发（TDD）这种敏捷开发思想，从一开始就解决这些问题，避免债务的积累。 一、产品研发的隐形债务，看不见≠不存在 如果只是研发出了产品功能，但是对其测试不充分，这个功能就附着了测试债务，并且随着时间推移，测试债务会越隐藏越深，偿还成本会越来越高。 同理，如果只是研发出了产品，但是代码结构不健壮（比如：代码逻辑繁杂不精简高效、跨模块耦合过高），这个产品也就附着了开发债务，随着产品架构的发展，开发债务越来越高，摇摇欲坠的代码如屎山一般，每次产品的进一步发展你都会被恶心一次。这个问题曾经进行过思考，在《换个视角，再看互联网产品研发效率！》中讨论了技术架构和产品架构的双螺旋发展关系。 二、打开新思路，TDD测试驱动研发 面对测试债务，测试驱动研发(Test-DrivenDevelopment,TDD)是一种新的思路以预防这种情况的发生。TDD是一种敏捷开发思想，既然所有的功能点都需要测试，而且是反复测试，为什么不把测试工作提到最前面并自动化呢? TDD要求在写任何功能代码之前，先写好它的测试代码，以保证所有的功能点都被自动化测试所覆盖。从而规避了【产品–>开发–>测试】这种低效的线性路径以及大概率会出现的信息传输漏斗，导致功能到代码到测试的不断衰减，最终交付质量堪忧、未来again时的巨大难题。 TDD正是从一开始就解决测试债务的方法，当产品变得很庞大的时候，TDD依然可以快速有效地检测各个功能点，这对于没有运用TDD的产品来说是一项不可能完成的任务。从研发驱动测试到测试驱动研发，是一个巨大的转变，其中涉及研发流程、测试人员的编程能力、研发平台对自动化测试的支持程度等环节。 不过，在测试驱动研发出现之前，那么多研发驱动测试的产品也获得了成功，所有这些因素都影响了TDD的普及。 三、TDD的根本是什么？ 话说至此，TDD测试驱动研发中的“Driven”一词值得思量，逻辑关系上测试始终是为研发服务，而非代码为测试而生。与其说是测试“驱动”研发，不如说测试“可视化”研发、测试“螺旋化”研发，那么可视化/螺旋化在于什么呢？ 研发服务于产品功能，产品功能服务于业务/用户需求，测试服务于研发并有助于研发。测试为纲，更是一种思想，使得研发过程时刻考虑到代码逻辑的可视化、可测试化、可自动化复测，从而促进提升代码质量、可检测性、可持续性。测试代码的领先搭建，有一个现实的例子可以对比。 1️⃣一栋大楼，是一个产品——满足于市场（商业、住宅）需求 2️⃣建筑设计图纸（土建/结构/装修）——可以算是产品设计方案 3️⃣建筑主体、装修装饰——对应代码主体的后端和前端 4️⃣施工自检/监理监察/三方质检——算是测试 在建筑施工管理过程中，本位上来看监理是在施工工序之后进行的，但实际上监理的大纲方案、监理细则，其实在产品设计方案出来之后，就已经在展开了。同样的，施工（研发）过程也会根据监理的监察原则，在指定的关键点做好检验预留。 由此也看出来二者并非严格的先后关系，更像是一种螺旋缠绕关系，监理/测试为纲、为镜，对施工/研发进行约束和检验，这是一种典型的共建、共生。 如果你的产品总是出现无法定位的奇怪问题，那么应该要考虑一下转用TDD了，当然，最终的决策权在测试经理或研发经理，更重要的是需要团队成员接受这种思想并在项目中进行践行。 作者：Kris_3zzz， 公众号：iSpiik产品说 本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可，禁止转载 题图来自 Unsplash，基于CC0协议 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
在产品研发过程中，我们常常只关注功能的实现，却忽略了隐藏在背后的“债务”问题。测试不充分会积累测试债务，代码结构不健壮会形成开发债务，这些问题随着时间推移会越来越难以解决。本文将探讨如何通过测试驱动研发（TDD）这种敏捷开发思想，从一开始就解决这些问题，避免债务的积累。
一、产品研发的隐形债务，看不见≠不存在
如果只是研发出了产品功能，但是对其测试不充分，这个功能就附着了测试债务，并且随着时间推移，测试债务会越隐藏越深，偿还成本会越来越高。
同理，如果只是研发出了产品，但是代码结构不健壮（比如：代码逻辑繁杂不精简高效、跨模块耦合过高），这个产品也就附着了开发债务，随着产品架构的发展，开发债务越来越高，摇摇欲坠的代码如屎山一般，每次产品的进一步发展你都会被恶心一次。这个问题曾经进行过思考，在《换个视角，再看互联网产品研发效率！》中讨论了技术架构和产品架构的双螺旋发展关系。
二、打开新思路，TDD测试驱动研发
面对测试债务，测试驱动研发(Test-DrivenDevelopment,TDD)是一种新的思路以预防这种情况的发生。TDD是一种敏捷开发思想，既然所有的功能点都需要测试，而且是反复测试，为什么不把测试工作提到最前面并自动化呢?
TDD要求在写任何功能代码之前，先写好它的测试代码，以保证所有的功能点都被自动化测试所覆盖。从而规避了【产品–>开发–>测试】这种低效的线性路径以及大概率会出现的信息传输漏斗，导致功能到代码到测试的不断衰减，最终交付质量堪忧、未来again时的巨大难题。
TDD正是从一开始就解决测试债务的方法，当产品变得很庞大的时候，TDD依然可以快速有效地检测各个功能点，这对于没有运用TDD的产品来说是一项不可能完成的任务。从研发驱动测试到测试驱动研发，是一个巨大的转变，其中涉及研发流程、测试人员的编程能力、研发平台对自动化测试的支持程度等环节。
不过，在测试驱动研发出现之前，那么多研发驱动测试的产品也获得了成功，所有这些因素都影响了TDD的普及。
三、TDD的根本是什么？
话说至此，TDD测试驱动研发中的“Driven”一词值得思量，逻辑关系上测试始终是为研发服务，而非代码为测试而生。与其说是测试“驱动”研发，不如说测试“可视化”研发、测试“螺旋化”研发，那么可视化/螺旋化在于什么呢？
研发服务于产品功能，产品功能服务于业务/用户需求，测试服务于研发并有助于研发。测试为纲，更是一种思想，使得研发过程时刻考虑到代码逻辑的可视化、可测试化、可自动化复测，从而促进提升代码质量、可检测性、可持续性。测试代码的领先搭建，有一个现实的例子可以对比。
1️⃣一栋大楼，是一个产品——满足于市场（商业、住宅）需求
2️⃣建筑设计图纸（土建/结构/装修）——可以算是产品设计方案
3️⃣建筑主体、装修装饰——对应代码主体的后端和前端
4️⃣施工自检/监理监察/三方质检——算是测试
在建筑施工管理过程中，本位上来看监理是在施工工序之后进行的，但实际上监理的大纲方案、监理细则，其实在产品设计方案出来之后，就已经在展开了。同样的，施工（研发）过程也会根据监理的监察原则，在指定的关键点做好检验预留。
由此也看出来二者并非严格的先后关系，更像是一种螺旋缠绕关系，监理/测试为纲、为镜，对施工/研发进行约束和检验，这是一种典型的共建、共生。
如果你的产品总是出现无法定位的奇怪问题，那么应该要考虑一下转用TDD了，当然，最终的决策权在测试经理或研发经理，更重要的是需要团队成员接受这种思想并在项目中进行践行。
作者：Kris_3zzz， 公众号：iSpiik产品说
本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
你的反应是什么？
