如何管理经常修改的生产代码？

Question

我的项目邀请我对生产代码进行大量更改。需求不断出现，我需要尽快进行更改并进行部署。我有时最终会创建补丁工作类代码，因为某些要求不适合软件的整体设计。如何有效处理？任何设计模式来处理这个？

Answer 1

我已经看过很多次这种情况，但它总是以泪水结束。客户最后一次在改进流程之前损失了数百万美元。

用户始终希望“尽快”提供新要求，但他们并不了解以与您相同的方式进行更改的风险。他们看到不拥有该功能的成本，但他们没有预料到会发生什么以及如果更改破坏了将会损失多少钱。 （我并不是说你不是一个好的开发人员，只是在任何非平凡的软件中都会出现错误，并且不受控制的更改可能会更快地暴露它们。）

所以，我认为你需要退后一步，并尝试制定定期的发布时间表。会有阻力，但你可以更有效。当然有时候会是一个需要立即进行的更改，但是如果有一个时间表，那么用户有责任证明为什么打破发布周期是有道理的。

哦，正如其他人所说，你需要技术基础设施，如登台/测试系统，一键发布程序等。（见The Joel Test。）

Answer 2

测试，您需要一个可靠的测试框架，以确保您的修复不会破坏其他任何内容。

编辑：回答评论的问题。

不幸的是，除了花时间重构“黑客”之外，我无法想到一个真正完善的模式/解决方案来保持架构的完整性。但是你可能没有多余的时间来备用，因为你已经在生产中了。所以这并不容易......

然而更重要的是，如果架构被损坏因为你真的需要“破解”解决方案，这实际上可能是原始设计不符合产品的标志实际要求，因为如果是，您应该能够在Architecture的当前框架内修复/补丁。

因此，为了对整个情况保持积极态度，您应该注意到您的修复程序，以及当前架构如何帮助/遵守，以便您可以在以后的路上，当热修复程序开始解决时，数据和提示，为了重新设计建筑的任何部分需要设计，因为您有在生产过程中发现的更准确的要求。

Answer 3

这里的每个人都提出了很好的建议，比如测试等。但我想我应该指出你可能会提出错误的问题。你在问是否有一种“模式”可以帮助解决这种情况。模式是解决设计问题的设计选择。你基本上有一个“过程”问题。

我会问“我可以用什么程序来防止这种情况？”

不幸的是，（和我工作的一样）设计对于开发人员和架构师来说是一个问题，但是流程对于管理者来说是一个问题。它确实需要领导才能实施良好的流程并坚持下去。可悲的是，这往往是缺乏的。

Answer 4

这可能是答案的基础，但我认为你应该对agile software development进行一些研究。

Answer 5

我处于幸运的位置，我的HEAD几乎总是可以释放的。至少每周一次，我在HEAD中有代码，作为开发人员，我很乐意发布。这并不意味着每个可释放的版本实际上都会发布，但它可以。在我的环境中，每周发布实际上非常实用，通常会发布......

在部署到暂存之前，我立即将我的代码提升到Release分支。我总是将相同的代码部署到先前已在测试阶段测试过的。

然后可以在发布分支中进行任何紧急修复，并在部署之前在Staging上进行测试。如果修复程序足够好，我可以将它合并回HEAD。如果这是一个可怕的黑客攻击，我可以在HEAD中正确地重新实现它。

我有一套很好的开发人员测试套件，可以在每次办理登机手续时自动运行，这确认我没有破坏任何重要的东西。我的应用程序每次部署时都会运行内部测试，这再次让我充满信心。

实际上，运气不是你想象的那么重要。这不仅仅是偶然发生的;我必须努力使它成为可能。我不得不承诺编写和维护良好的自动化测试，以及获得持续集成服务器和一键式构建和部署功能。

我经常花时间清理我的代码，这是我正常开发活动的一部分。这有两个好处。首先，这意味着我的代码库开始时相对干净，因此架构非常灵活。其次，这意味着我擅长重构，因为我一直这样做。通过这种方式，我的意思是在对现有代码进行一系列单独的小变换的意义上进行重构，而不是在一掷千金和重新实现的意义上（这有点更危险）。

在我看来，这种“持续可释放性”是敏捷方法的最大好处。

Answer 6

除了修订控制，单元测试和自动构建系统的明显答案之外，听起来你还需要做一些沉重的refactoring。如果您的设计根据不断变化的要求不断变化，那么您应该尝试隔离代码中不断变化的部分。

Answer 7

您需要对您的需求积压进行纪律处分。冒着听老学和吵闹的风险，告诉别人没有，他们需要和你坐在一起，了解痛苦和努力的具体要点，以便进行剧烈的设计变革。对于数据库，请解释基数以及如何导致心痛。把你的干草扔到笼子里并坚持计划的释放周期，你只会在每个星期二投入生产，但只有在用户接受后才能投入生产。将每个请求分成2,4和8周的段，并严格按照这些时间框架中的内容进行处理。

如果您有一个已定义的问题域及其解决方案，有许多设计模式可以帮助您。具体来说，请查看Command Pattern，Strategy Pattern和Plug-in architecture，因为它们可以帮助您更轻松地扩展解决方案集。如果您是.Net开发人员，请查看他在DNRTV上审核的Migeul Castro的插件架构。

Answer 8

有几个项目生命周期可以模拟您的方法。 This site列出了一些（听起来你正在使用“Code-And-Fix”一个！），但这绝不是一个明确的列表，可以找到一个更大的列表here。

Answer 9

正如Robert Gould指出的那样，你真的需要一个升级平台来检查你在部署到live时不会破坏任何东西。

Answer 10

两个明显的工具是版本控制和测试。尝试将发布系统与它们集成，因此您可以在每一步都提交更改，并且当所有测试通过时（包括新需求的那些），发布系统会选择“已知良好”版本，这将是新版本

我不知道其他系统，但monotone有一些专门用于使测试标记提交的钩子，因此有一个命令“给我通过所有测试的最后一个版本”

Answer 11

显然，测试很重要。但对我来说，自动化更是如此。您应该能够在少于3个命令中将整个项目从源代码控制部署到生产服务器。 Maven，Ant，Capistrano等工具（在此插入您最喜欢的工具＆lt; ...＆gt;）可以为您提供很多帮助。每当源控制发生变化时，拥有一个可自动部署到测试或集成服务器的持续集成系统也可以提供帮助。

将所有自动化设置到位后，第一次执行时需要花费时间......

Answer 12

这是一个过程事物，而不是设计事物。

您需要做的第一件事是教育您的用户，以便他们了解更改需求的成本。这并不是为了阻止他们更改它们，而是为了避免更改它们并尽快请求实施，除非有明确的业务需求。 （我认为这是一项商业活动，在这种情况下，您的工作就是尽最大努力完成业务需求，并让人们了解您的最佳能力，以及整体方案中的功能成本。的东西。）

第二件事是为快速修复建立一个双修复过程。首先，你得到适当的补丁，以保持应用程序运行或多或少令人满意，然后你需要一些时间，并提出真正的修复。这可能还需要一些用户教育，你可能会发现“技术债务”的概念对解释这一点很有用。

第三件事是确保你拥有资源。如果你无法跟上这样的需求变化，你需要帮助，你需要说明原因。如果决定不引入更多人的权力，并且他们明白限制修改的数量，这也是好的。

现在，您的用户可能无法访问，您无法让人们相信快速修复从长远来看非常昂贵，等等。在这种情况下，我建议第四件事：打磨你的简历并开始寻找新工作。现在，看起来你的设置失败了，这是一个非常糟糕的地方。俗话说，改变你的工作或改变你的工作。