干货｜软件开发，小步真能快跑吗？

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

作者简介

作者乐攀是非常优秀的程序员，有10多年的程序设计和开发经验，近年来致力于敏捷软件开发管理和技术实践的落地。

本文主要论证一个理念：哪怕仅仅只考虑软件正确性所付出的时间代价，小步快跑的效率也是优于大干快上的。希望能给一线程序员和开发经理一些启发。

软件行业似乎形成了约定俗成的理念：bug发现得越早，修复成本越低；发现越晚，修复成本越高。

这个结论是否真的成立？本文将对此进行讨论。根据金字塔原理，先抛出结论，是真的。

让我们来考虑这样一个典型需求的实现过程：软件接受一个矩阵输入，进行一系列矩阵变换，最后输出变换后的结果（仍然是个矩阵）。其数学表达为Yn = F1（F2（F3（……Fn（x）……）））。此过程中，我们只考虑正确性，而不对其它方面做过多研究。

在开发阶段，它可以被划分为多个过程模块，每个模块规模大致相当，模块和模块之间只传递输入输出数据，首尾相接。显而易见，只要一个模块实现有问题，则最终输出都是不正确的。小步快跑的开发方式，即开发一个，验证一个，集成一个，由于之前的假设，全部模块集成到一块以后，必然是一步到位。大干快上的开发方式，即先进行全部模块的开发，最后再集成到一块进行质量保证活动。究竟哪种开发方式，开发时间会更短？

选择合适的规模1（和团队开发水平息息相关），来满足以下假设

假设1，在规模1及以下，通过1次反馈就能保证其正确性，所需要的时间是：t开发+t质量保证，t质量保证=t反馈

假设2，在规模1以上，如不经过反馈，则必然出现至少1个bug

假设3，在规模1以上，一旦出bug，只能先通过二分查找法，把bug定位到某个规模为1的软件模块，才能解决

有以上假设后，不难得出以下推论，如果规模为N（N > 1），两种开发方式的时间对比：

小步快跑：N *（t开发+t质量保证）

大干快上：N *t开发+log2N*N*t质量保证/2

 

在开发上面花的时间，两者是一样的，都是N*t开发

在质量修复方面，小步快跑总共花费的时间是N*t质量保证，时间复杂度是O(N)

大干快上因为到了最后总还是会出1个bug，在二分查找法方面，需要进行log2N次反馈，才能定位bug，因为bug可能出在任意一个模块，平均下来，每次的反馈时长是N*t质量保证/2。则花在质量保证方面的时间是log2N*N*t质量保证/2，其时间复杂度是O(N*log2N)

 

结论很清晰，大干快上确实不如小步快跑，除了特殊情况：N<4时，此时log2N小于1，大干快上优于小步快跑。

姑且认为开发水平足够高，在不做任何的质量保障活动的前提下，每1000行的代码有3个bug（这在业界已经是非常恐怖的数据了）。那么300行的规模，或者可以满足假设2，不可能再大了。则以一个10万行规模的软件来看，其N值为333。哪怕只出1个bug，大干快上在质量保证方面花费的时间已经是小步快跑的4倍以上！

这已经是对大干快上非常偏袒了，首先，如此规模的软件，不可能只有1个bug；其次，编码水平已经是行业内数一数二的；再者，模块组织相当合理，二分查找法能发挥最大效用；最后，一次反馈就能解决bug，这也是非常理想化的，根本不敢想。

 

通过简单推导，再次证明了本文开头所述观点的正确性。但为什么还有那么多技术团队，愿意大干快上呢？原因无外乎几点：

1、早期软件规模不大，两者区分不明显，一直没更新观念；

2、由于各种原因，软件难以被划分为合适的规模；

3、可测试性不足，即使划分，也没法验证；

4、进度逆排序，发现bug解决阶段耗时多，则压缩开发时间为bug解决争取时间……

5、侥幸心理

由此导致的后果，依然还是技术团队自己承担。