【IT168 分析评论】

    在敏捷开发中，重构是一个必要条件，以Scrum为例，最充足的理由是：

    1.在传统的Scrum中，Sprint的长度为一个月，现在一般时间更短。所以团队就得在项目刚开始的两周或者一个月内交付完成的软件。

    2.软件来自于产品负责人的backlog。它必须由特征组成。要正确的做到Scrum，我们不能叫做基础架构之类的东西，我们要交付特征。

    3.所以，在开始几个Sprint中，团队就没时间把最终产品所需要的整个稳定的基础架构做好。我们只能做好一小部分而已。

    4.但是，整个产品肯定需要一个大型的，性能强劲的，更加稳定的架构。

    5.所以项目中的架构必须要改，不是因为我这样说你才这样做，而是因为刚一开始我们没有，而到最后我们得需要。

    6.要修改基础架构的方法不多。我们可以每个Sprint重写一次，或者是对它做改进。每次都重写的话效率太低。所以我们必须做改进。软件的改进就是重构。

    在实践中重构会遇到这样一些问题：

    1.重构最需要单元测试（如Junit）和QA自动化（如Fitness等），这样程序重构的稳定性很好，效率也高。但Junit和Fitness等工具使用纯熟的工程师并不多，同时公司也不愿意在Junit这样初期成本很高的地方多放置资源

    2.公司管理层一般看不到重构实际的商业价值，重构的成本不容易被接收

    3.很多时候确实需要更多的实现功能，这样才能拿到合同，虽然代码不怎么样。等拿到了合同，再来重构也来得及

    我们在实践中是这么做的：

    1.在Team的结构中明确了架构师的角色

    2.在第一个Sprint正式开始之前，先做Agile modeling的工作，确立了架构，我们现在用SSH架构，由架构师先期研究SSH的各个细节，并向Team其他成员介绍

    3.在Sprint中，如果需要优化，无论是架构还是业务程序，由架构师提出方案，并由Team讨论通过，优化由架构师来做。架构师编码规范，自身出错的几率要远远小于一般的开发工程师。Junit只是在最关键的模块的正常流程以及Exception捕捉中用到了。整个Team都明白本次优化的影响范围，Team其余成员还是在完成功能，QA也会偏重本次的影响区域。优化的成本会降到最低，同时会达到重构的目的。