敏捷开发敏捷个人_您在维护中不能敏捷吗？（第2部分）-CSDN博客

敏捷开发敏捷个人

本文摘自“ 您在维护中不能敏捷吗？”。 （第1部分）

编码准则–遵守规则

在维护中，使团队遵循编码准则非常重要，有助于确保代码库随时间推移的一致性和完整性，并有助于确保软件安全性（PPT）。当然，根据他们在代码库中继承的内容，团队可能不得不在编码标准和样式约定上做出妥协。维护多个系统的团队将必须针对每个系统遵循不同的准则。

隐喻

在XP中，团队应该共享一个“ 隐喻” ：系统体系结构（系统是生产线或物料清单）的简单高层表达，以及可以用来描述系统的通用名称和模式。充其量是一个模糊的概念（PDF），不能替代更详细的体系结构或设计，并且在维护方面没有太大的实际价值。维护团队必须使用系统中已经存在的体系结构和模式。

重要的是确保团队对这些模式和基本体系结构有共同的理解，以确保完整性（如果尚未丢失）也不会丢失。使团队团结起来，审查架构，或对其进行反向工程，以确保他们都同意并以简单的方式对其进行记录，这一点很重要，尤其是在接管新系统的维护以及计划进行重大更改时。

简单设计

敏捷开发团队从简单的设计入手，并努力使它们保持简单。维护团队必须处理他们继承的任何设计和体系结构，这可能极其复杂，尤其是在较大和较旧的系统中。但是，驱动原理仍然应该是设计变更和新功能，就像现有系统所允许的那样简单-并尽可能地简化系统的设计。

尤其是在进行小的更改时，简单，足够的设计就可以了–这意味着更少的文档，更少的时间和更少的成本。但是，维护团队需要比开发团队承受更大的风险–即使是很小的错误也可能破坏兼容性或导致运行时故障或打开安全漏洞。这意味着维护人员不能像迭代那样自由地冒险，他们需要花更多的时间在前期进行分析，了解现有设计并通过依赖进行工作，以及在之后检查和测试其更改以进行回归。

重构

重构在维护中非常重要。每次开发人员进行更改或修复时，他们都应考虑应进行多少重构工作，以使代码和设计更清晰，更简单并还清技术债务。重构的内容和数量取决于他们正在进行的工作类型（进行深思熟虑的孤立更改，进行shot弹枪手术或推出紧急修补程序）以及所涉及的时间和风险，他们的理解程度代码，工具的性能（Java和.NET的开发IDE至少具有良好的内置工具，这些工具使许多重构变得简单和安全），以及它们可用来捕获错误的安全网络类型–自动测试，代码评论，静态分析。

一些维护团队不会重构，因为他们太怕犯错误。这是一个恶性循环-随着时间的流逝，代码将变得越来越难以理解和更改，并且他们将有更多的理由变得更加恐惧。其他人则声称，如果维护团队没有花费至少50％的时间进行重构，他们将无法正常工作（PDF）。

真正的答案介于两者之间–足以进行更改和修复的重构。在某些情况下，正确的做法是进行大量的重构，重组或重写代码。有些代码太危险而无法更改，或者bug太多而无法保持现状。研究表明，在大多数系统（尤其是大型系统）中， 80％的错误会聚集在20％的代码中。重组或重写此代码可以很快得到回报，从而减少生产中的问题，并显着减少进行更改和测试过程所需的时间。

连续测试

测试在维护中比在开发中更为重要和必要。这是维护成本的主要部分。大多数维护团队都依靠开发人员手动测试自己的更改和修正，以确保更改有效并且不会造成任何副作用。当然，这会使测试变得昂贵且效率低下，并且限制了团队可以完成的工作量。为了快速行动，使增量更改和重构安全，团队需要通过自动化单元和功能测试以及验收测试来获得更好的安全网。

放置测试支架和工具并编写一套良好的自动化测试可能需要很长时间。但是，即使是简单的测试框架和少量核心测试也可以在维护方面Swift获得回报，因为很多更改（和错误）往往集中在代码的相同部分，从而获得了相同的功能，框架代码和API。一遍又一遍地更改，并且需要一遍又一遍地进行测试。您可以从小处着手，使这些测试快速可靠地运行，并让团队依靠它们，通过手工测试和复查来填补空白，然后随着时间的推移填写测试。一旦有了基本的测试框架，开发人员就可以利用TFD / TDD特别是针对漏洞修复的问题–无论如何都必须测试该修复程序，所以为什么不先编写测试并确保已修复了应该做的事情？

持续集成

要使持续测试生效，您需要一个持续集成环境。了解，自动化和简化构建过程，以及启动CI服务器并运行，在测试，静态分析检查和报告中进行接线可能会在企业系统中进行大量工作，尤其是当您必须处理多种语言和平台以及它们之间的依赖关系时系统。但是，执行此工作也是简化发行和部署的基础-频繁的短发行意味着必须尽可能简化发行和部署。

现场客户/产品负责人

与客户紧密合作，以确保团队在客户需要时交付客户所需的东西，在维护方面与开发新系统一样重要。在一个引人注目的开发项目上，要让有才干和忠诚的客户参与进来就足够了，但是维护起来却更加困难。您可能会遇到太多议程冲突的客户争夺团队的注意力，或者没有人有时间或能力回答问题并做出决定。维护团队通常必须做出让步，并帮助自己填补这一角色。

但这并不完全适合…。

Kilner 关注的主要点并不是维护中的敏捷方法。一般而言，这是通过增量设计和开发进行的–有些工作不太适合在短时间内完成。对于错误修复和小的增强（它们确实可以），短迭代可能可以工作，但是有时您需要进行较大的更改，而这些更改具有很多依赖性。他认为，尽管构建新系统的敏捷团队可以解决未完成的工作并保持步调一致，但维护团队必须使所有功能一次全部工作–要么全部要么一无所有。

很难看到有多大的变更可以分解成适合于短时间框的小步骤。我同意这很难维护，因为在进行更改之前，您必须更加谨慎地理解和弄清依赖关系，并且还必须更加谨慎，不要破坏事物。代码和设计有时会与您需要进行的各种更改作斗争，因为您需要做一些原始设计中未曾预料到的事情，或者随着时间的流逝而丢失的任何设计，任何更改都很难使。

这并不容易-但是团队始终会解决这些问题。您可以使用工具来计算代码中有多少依赖关系混乱，以及需要进行哪些更改才能摆脱这种混乱。如果您要花费“数周，数月甚至数年”来更改系统，则需要花些时间提前了解并分解构建依赖关系并隔离运行时依赖关系，并放入测试支架和测试以保护团队在犯错误时不会出错。所有这些都可以按时间框的步骤进行。仅仅因为您遵循时间框和简单的渐进式设计，并不意味着您在不作任何考虑就开始进行更改。

阅读使用遗留代码工作 – Michael Feathers详细介绍了如何使用面向对象和过程语言来处理这些问题。如果需要永久进行更改，该怎么办。如何打破依赖关系。如何找到拦截点和夹点。如何在设计和代码中找到结构。编写什么测试以及如何使自动化测试生效。

在生产系统中更改数据，尤其是与其他系统共享的数据，也不容易。您需要尽可能仔细地计划API更改和数据结构更改，但是仍然可以按照结构化的小步骤进行数据和数据库更改。

要逐步进行代码更改，您可以在有意义的地方使用“ 抽象分支” （例如进行后端更改），并且可以通过功能标志和Dark Launch（如Facebook和Twitter和Flickr所做的那样）来保护客户免受更改的影响，从而不断推出更改–尽管您需要特别小心，因为如果采取的过多，这些做法会使代码更脆弱，更难以使用。

敏捷开发团队遵循渐进式设计和开发，以帮助他们通过反复试验发现最佳解决方案。维护团队以不同的原因进行这种工作-通过分解大的更改并下小注而非大注来管理技术风险。

以这种方式工作意味着您必须安装脚手架（并记得在之后将其取出），并计划中间步骤，并在进行每次更改时检查并测试所有内容。有时，您可能感觉自己运行正常，花费的时间更长，成本更高。但是，一步一步到达那里更安全，并且可以给您更多的控制权。

在大型遗留代码库和旧技术平台上工作的团队将很难接受这些想法并获得成功。但这并不意味着它们将无法工作。是的，您可以灵活地进行维护。

参考： 您在维护方面不能敏捷吗？从我们的JCG合作伙伴 Jim Bird在“ Building Real Software”博客中获得。

相关文章：