软件开发与攀岩运动_程序员搞攀岩俱乐部-CSDN博客

本文链接：https://blog.csdn.net/darxin/article/details/5523165

本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

【本文成文于2004年6月，曾作为公司内部资料使用。日前重拾旧文，感慨颇多。时至今日，文中的部分内容已经过时（如频繁测试的概念已经被测试驱动开发所取代），但作为软件开发工作流程的通俗版仍有一定的价值，希望对涉足软件开发领域的新人能有所帮助。】

逐渐变大的BUG！

在软件系统的开发过程中，不管是系统的全部生命周期，还是一个模块的开发过程。贯穿其中的软件问题往往有逐步扩大的趋势。

系统开发过程中的BUG

需求分析时的BUG	设计时的BUG	编码时的BUG	发布时的BUG

编码过程中的BUG

编码初期发现的BUG	编码过程中发现的BUG	编码后期发现的BUG

与此同时，令我们感到困惑的是，随着BUG的逐渐变大，寻找和消灭这些BUG的难度也随之变大。也就是说，越到后期，其危险性也越大。尤其是在编码过程中发现的BUG，如果在编码后期发现错误，那将是我们程序员的灾难！想一想在30分钟内完成的代码我们将用一天的时间寻找其中的BUG。这对我们的身心将是多么大的考验！那么如何在编码过程中避免这种BUG逐渐变大的趋势呢？

攀岩运动

攀岩是一项充满刺激的运动，为了不使你在攀岩过程中有个三长两短，安全装备是必要的。那么攀岩活动中我们需要使用哪些工具，注意哪些问题呢？

最高峰：
最高峰就是攀岩的目标，这几乎是第一要素，我们不可能在岩壁上胡乱爬吧！

大地：
我们生命的保障，也是冒险活动的起始点。

攀登点：
攀岩过程的每一步我们都在寻找下一个攀登点。攀登点是稳定的，所谓一步一个脚印。攀登点间隔不易过小，否则则有停滞不前的趋势；攀登点间隔不易过大，否则将有很大的风险。

铁钎和安全绳：
我们每攀登几步，就应该在岩壁上打上一个铁钎，并将安全绳固定在上边。如果我们在攀爬过程中失足，还好有刚刚固定的铁钎保护，我们可以从最后一个铁钎处重新向上攀爬。如果我们在攀岩过程中忘记使用铁钎，一旦失足，那…

在攀岩过程中，每爬一步，离目标就越近一步，但我们的危险就越大。这跟软件开发是不是很象呢？在攀岩活动中，有很多工具和措施保护我们远离危险，软件开发是否有相似的工具和措施呢？

软件开发——程序员的攀岩活动

常规的开发流程

下图是我们常见的软件开发流程，让我们看看它与攀岩活动是否有相似的地方？

式样书与最高峰

作为软件开发的第一要素，式样书的重要性怎样形容都不过分。它是我们软件开发的最高峰，我们的所有活动都以式样书为准。大型系统的式样书主要以用例说明为主；模块开发的式样书主要以函数说明为主。

原型与大地

任何软件系统都有一个原型，这就是我们软件开发的大地。它是基础，是我们行动的指南。在大型系统中原型意味着架构，它是综合测试的基础；在模块开发中原型意味着测试环境，它是单元测试的基础。

频繁测试与攀登点

软件开发是一个充满创造性的工作，每一步都充满了不稳定的因素。和攀登点的概念相似，我们在开发过程中的攀登点必须准确、间隔必须适中。准确性可由测试完成，而间隔适中意味着频繁。频繁测试可以达到降低风险的目的，也是避免BUG变大的首要手段。要想实施频繁测试，单元测试将起主导作用。

版本管理与铁钎

在攀岩运动中，铁钎起着至关重要的作用。它首先是一个攀登点，其次它比攀登点更稳定。在软件开发过程中，版本管理与铁钎起着异曲同工的作用。在软件开发过程中，只要软件功能达到一定的稳定性之后，就应将其导入到版本库中。也就是说在版本库中存放的版本都是相对稳定的版本。这里所谓的“稳定”有两个含意：经过单元测试没有BUG；实现了某个功能。

类似攀岩的开发流程

回过头来，我们再看一下上面提到的软件开发流程图，这一次让我们变换一下观察的角度。如下图，这样看是否觉得软件开发更像攀岩呢？