从“最后一公里”问题谈起

目录

1. 什么是最后一公里

2. 不得不说的“敏捷”

3. 效率！= 时间短

4. 测试随时随刻

5. 关于测试环境

6. 理想的测试

7. “最后一公里”的根源

８.  如何避免”最后一公里“

9. 总结

1. 什么是最后一公里

初次接触最后一公里这个概念，应该是在大学的计算机网络课程中。

“最后一公里”指从通信服务提供商的机房交换机到用户计算机等终端设备之间的连接。而“最后一公里”问题其实也就是指由于每个用户的位置，设备等的不同而造成的布线困难问题。

接下来，让我们把这个“最后一公里”的概念延伸开去：最后一公里指的是一件事情已经进行到最后，但是还欠缺一件事，而这件事还是非常关键的。

在软件世界里，这个“最后一公里”问题指的就是满足了功能需求，尚未投入实际运行并创造业务价值的阶段。

2. 不得不说的“敏捷”

“敏捷开发”这个词不知道从什么时候开始被无数次地提上台面。这个概念本身是没问题的，当然，他的意图是好的，思想也是好的。

错只错在太多人把“敏捷”的概念定位在了单独的快上，拿到需求不去架构设计，把数据库搭好，大家开始写页面。发生了需求变更，填个If，再改，加个局部标记变量，补上一个else if，我想这是很多公司都很常见的情况吧。

然后，Leader们美名其曰“敏捷”。然后，很多“小兵”也就跟风着说，我们公司是敏捷开发。

在我看来，敏捷有很多实施手段，但最后的目标有两点：A. 效率  B. 迭代。

注意，我这里说的是效率，而不是时间，那是因为敏捷解决的问题是节省从项目需求确定到最终版本的时间，而不是到Beta版，或者“垃圾”版本的时间。

关于迭代，敏捷中有这样一个概念，叫“拥抱变化”，在我看来，变化是能够保证敏捷软件完善的驱动，变化驱动迭代，架构师，开发者不去假想变化，而是由实际的变化去迭代，去完善软件，而我看来，这个才是敏捷真正的核心。

那好，接下来，我们就从这两个角度来谈“最后一公里问题”。

3. 效率！= 时间短

小学生都会了解这样一个公式：效率=质量 / 时间。在软件世界，让我们继续来完善这个公式：

效率=最终版本的质量/∑时间，也就是说最终版本的质量除以整个该项目所花费的时间。对于项目如此，对于网站也是如此。

在这里，我还是无法免俗地反复谈测试的重要性。

4. 测试随时随刻

在软件开发中，最早流行的应该是瀑布模型，然后逐渐地被螺旋模型取代，螺旋模型的核心在于：A. 每个阶段的风险评估 B. 一层一层迭代。在每个螺旋生命周期中，最后一步都是测试！

其实在我看来，这个模型还是不够完善的，测试应该是无处不在的。在我眼中，一个理想的状况应该是每个开发人员身旁都能配备着一个测试人员，测试人员需要对每个公开的方法进行测试，对每一个模块进行测试，这些不是在界面上点来点去，而是要编写详细的测试用例，对输入和输出都进行详细的控制。

接下来，是对功能性需求的测试，这个主要是针对需求文档编写测试用例，对模块或系统进行测试。这个是软件公司大多数测试都在做的事情。

接下来，还有很重要的一点就是性能测试以及一些附加功能，如权限的测试等等。

也许从眼前来看，这样的进度效率上是慢了，但是从整个项目的进度来说，这样来做会让我们交付的每个版本都是一个可靠的版本，换句话说，“增加了开发成本，减小了维护成本”。

对于产品公司来说，每个公司都不希望客户天天打客服电话抱怨Bug；对于网站来说，每个人都不希望用户点了某个按钮却来到了一个错误页面。

对于某些由用户来代作测试的做法，个人更认为是极其可笑的！这正如某个程序员写了一段效率极低的代码，当Code-Review时，他说，这是CPU太差，换个好的硬件，加内存，加CPU，就好了。都是非常不负责任的做法。

也许这个时候会有人说，大到微软，小到豆瓣还搞两个Beta版呢，可是这里不得不说一句，兄弟，你又错了，他们发布Beta版不是为了让你点出哪个按钮出错误，而是为了搜集用户的需求，更好地完善功能而已，改进！=改Bug。

5. 关于测试环境

什么是测试环境？我的定义是可以基本模拟真实生产环境的供开发，测试人员使用的虚拟的，不对外公开的环境。

在这里我突出两个要点：A. 基本模拟真实环境 B. 虚拟的环境

A否定了把本机作为测试环境。B否定了把真实环境作为测试环境。

本机的作用用于保证代码的基本逻辑无误，但是想用本机的简单测试来作为发布的测试环境，是非常可怕的。首先，本机连接的数据库与真实的环境一般来说都是有较大差距的，其次，本机的配置与服务器的配置差距是很大的，用本机做出的测试的响应时间几乎是没有任何参考价值的。最后，很多的真实环境是本机无法模拟出来的。

对于产品公司来说，一台测试服务器，对于互联网公司来说，一个测试站点的重要性都是不言而喻的。也许有些朋友认为我在说废话，可是我们看看身边，没有去投入去做的公司，我想大大存在。

6. 理想的测试

在Roy的文章中，提到了要把测试脚本，安装脚本，配置文件也作为产品交付的一部分。

从理论上说，我认同这样的观点，迭代不仅仅是对代码的迭代，同样应该包含对这些测试脚本的迭代。

可是考虑中国大多数公司的现状，这一点，只能停留在理论阶段。

7. “最后一公里”的根源

Roy在文章中举了一个让我觉得非常恰当的例子。大致意思是这样的：

一个人白手起家开公司，做了一个软件，功能很少，加上这个人的人手很紧，时间很急，项目做的很垃圾，但是因为功能很少，所以还看不出来，也涉及不到什么维护的成本。软件的销量不错。

但是逐渐的，这个软件庞大了起来，这个人一想，唉，在这个基础上加功能吧，这样比较容易，好吧，功能还是很少，没有问题。

这个项目越做越大，终于有一天，原来的项目已经被修得惨不忍睹了，维护成本也大得惊人了，不得不对产品进行重构了。可是这个时候，项目已经太大了，重构的成本也太大了。

这就是存在“最后一公里”问题的软件的根源！

一句话总结，“得过且过”成全了“最后一公里”。

８.  如何避免”最后一公里“

在这里，我只谈符合中国国情的软件行业，其实不只是软件行业，根源在什么？等级观念！

我不愿承认，却不得不承认，我们都在一个等级观念很强的社会里，你是老大，好吧，你说的都是对的，错的也是对的。你说重构没用，那就没用；你说技术没用，那就没用；你说可维护性没用，那就没用。

我们都是小兵，我们又能做什么呢？

在这里解决问题的不是技术，而是一个在企业中都会考虑的问题：牵制力！

在我眼中，CTO存在的价值是什么，明明都有CEO了，CEO是不擅长技术的，他关注的是结果，他关注的是这个产品能不能赚钱。而CTO是关注技术的，这个时候不至于让这个企业完全地朝着一条，不可持续发展的路线去发展。这就是CTO对CEO的牵制力。

同样，一个团队应该至少是有两个Leader的，一个是注重技术的，一个是注重业务的，两人等级相同，互相牵制。这样不至于让整个团队沉迷于技术的海洋中，也不至于让整个团队忽略技术的重要性。

关注业务的Leader会知道，我们要用多少时间去做这个东西，要做什么样才合适。他关注的是端对端的软件交付。

而关注技术的Leader会知道，我们这样去做会对今后产生什么样的影响，哪段代码的变化是频繁的，这段代码我们需要重构，这个技术是过时的，我们需要用新技术去重构代码。

两个人的牵制会让团队达到最好的平衡点。

当然，这个只是下下策，最好的情况是废除“等级制度”，至少在技术上废除（待遇上废除暂时在中国的大部分企业看来不太可能）如果可以的话。

9. 总结

写到最后一节，回去看之前所有的文字，其实发觉都是废话，这些道理都浅显得很。

测试的重要性，如何建立一个好的团队，这都是“软件工程”这门课的基础理论。

可是，读了这篇文章的各位Leader们，你们还记得这些最基本的理论么？你的团队还是一个健康的发展的团队么？

当代码出现Bug时，当项目延期再延期时，当你的软件整天被客户追着骂时，当你责骂你手下那群无用的程序员时，不妨先扪心自问，这些基本的道理，你都做到了么？

那么，你还该做些什么呢？