重建 - 软件项目测试的高级模式

[yanyading]

当我们的软件系统经过一段时间运行以后，往往部分功能，或者大部分甚至整个系统都不同程度的无法适用于现实的环境，所以，进行部分或者全部重建的任务将被列入工作日程。

在这里，我们认为，以前旧的软件系统看起来或许在设计理念、需求上、技术上确实有所不足，但是它提供给我们的是一个能够测试包括业务需求，工作流程等等在内整个大环境，以及该环境和软件系统的结合工作方式的平台，通过这个平台，系统分析人员，程序员以及终端用户都可以显性或者非显性的发现软件系统中的某些经典设计方法（比如工作流程，也就是我们常说的"用的顺手"）以及缺点。软件系统经过大规模的、广泛的事实使用，几乎所有人都有自己对该系统的评估，仁者见仁；智者见智，终端用户可能会觉得某个打印票据的功能很是顺手，也可能觉得某些信息的显示非常不符合业务逻辑；而程序员或许会觉得某段代码写的太浪费资源，通过优化后可以提高运行速度2%，并且增加一定的稳定性；系统分析人员可能会觉得某些功能模块分类不合理，把两个较小的模块合并为一个等等。

总而言之，如果没有软件系统这样事实的大规模使用，也就无法收集到这么多有价值的抱怨和肯定，所以，从另外的一个角度而言，很多情况下，良好的、高效的重建是建立在一种以较大规模进行使用作为测试的基础之上的。

引用段落：
- - - - - - - - - - - - - - - - - - - - - -
我们可以从XP、Crystal、RUP、ClearRoom等方法学中对比、体会迭代设计的精妙之处：每一次的迭代都是在上一次迭代的基础上进行的，迭代将致力于重用、修改、增强目前的架构，以使架构越来越强壮。在软件生命周期的最后，我们除了得到软件，还得到了一个非常稳定的架构。对于一个软件组织来说，这个架构很有可能就是下一个软件的投入或参考。
- - - - - - - - - - - - - - - - - - - - - -
本文允许且欢迎在保留完整作者信息的前提下自由转载。

作者: 严亚丁
E & MSN: yading(at)644000.com
W: http://webe.644000.com
Q: 24138511

[gdkevin]

说实话，
第一遍，没看懂
第二遍，没看懂
第三遍，还是没看懂
堪称：软件业的大话西游，呵呵

开玩笑的，不过觉得真的看不出什么主题思想，楼主要表达什么意思呢？是更加用户化的快速原型法？？学习ing

个人观点、仅供参考
我爱红星,gdkevin

[yanyading]

一句话：用户的实际使用本身就是测试，而且是对下一套软件系统设计的开发提供信息。

[yanyading]

up

[fastpoint]

说虚的没用，给些代码说说怎么实践。

[Corporal]

mark

[yanyading]

知音啊,确实是这样的一个意思.

首先我同意“重构”确实是一个开发模式，但是如何进行归类确实是一个问题，比如“重构”应该属于“测试”、“分析”，还是“实施”，好像它本身与这些方面都有一点点的牵连。

[xiaohaiz]

我想,测试驱动,重构,结对编程等等这些敏捷的开发方法正在改变我的开发思路.
我做了一次XP开发项目的实践.把开发,设计,测试,集成融和在一个开发团队来实施,对于我来说是一次不错的实践.正是有了这次实践,也促进了更多的思考.
我的想法很有可能也不成熟,我现在还是倾向于敏捷的开发,测试与开发本来就是一体的,所以没有必要区别得很明细.不过有时也很难做,其实主要不是技术原因,而是因为团队的意识还不能达到一致.

[xiaohaiz]

多说几句吧,其实做这些比如说新的开发方法,新的开发迭代模式等等,最难的都不是技术性质的问题.原理也很简单. 关键在于很难达到团队的意识一致.不是一次两次项目就可以做到的.另外的制肘就是我们所处的整个软件业的环境.

[Schlemiel]

一堆废话，而且还是不高明的那种。短短三段话，“重建”两个字包含了好几重意思，有“系统无法适用于现实的环境”时的升级，有功能性的修改完善，有“可以提高运行速度2%”的性能优化，还有“把两个较小的模块合并为一个”的重构。外延越宽，内涵越窄，结果想要强调的“重建”根本什么都不是，只是一堆杂烩。亏得楼主还不辞辛劳发明了“重建”这样一个不伦不类的词，请问它到底是什么？

就这么几句不高明的废话，还一板正经地“允许自由转载”，您对转载者的智商也太没信心了吧。

[xiaohaiz]

一般认为 refactoring 翻译成"重构"会被大多数人理解,因为毕竟这是大家比较公认的译法.楼主文中的"重建"我相信就是 refactoring 的意思.
测试本来就是重构的基础,"如果没有测试保证,就不要做重构".
但是我觉得重构并不是软件测试的高级模式,而更加倾向于把之归结为一种开发的方法,它正在改变我们传统的"design first, then code"的模式.

[yanyading]

To: Schlemiel(维特根斯坦的扇子)
你的总结非常不错，很是感谢。我在这方面需要某种总结才可以。

[Schlemiel]

不客气。你如果是想到一个多少有点价值的东西，不妨把它抽象出来：它具体是做什么，不做有什么坏处，做了有什么好处。先别急着拔高，也别大而化之把什么东西都包含进去。有一点点价值的小东西，比一点价值都没有的大东西要好。

90年代以后，到处都流行“re”开头的单词，reconstruction、reengineering、refactoring……带着一个“re”的前缀，就说明这个东西肯定不是什么新玩意，也不是什么大话题，就是一点有价值的小东西。现在refactoring炒得够热了吧，国外的老家伙们怎么说？“我从70年代就开始这样做了。”William Opdyke的博士论文尚且如此，你就更不要着急把一个概念扩大化了。能找到一个准确的概念，以及一些有用的实例和操作方法，已经善莫大焉。

[yanyading]

up