如何向涉众解释重构的价值？
我如何说服项目经理、产品所有者、业务分析师、客户和各种其他涉众，认为重构是开发过程中一个有价值和有成效的部分？
作为开发人员，我们都知道需求从一开始就会发生变化，或者从一开始就没有得到充分的解释，因此，我们过去如何编写一段代码，现在没有意义，需要改变。我们知道，如果我们现在重新设计一些代码，从长远来看，它将给我们带来麻烦。我们知道，如果我们保持代码库的整洁，它将提高可维护性，并最终导致更好的代码。
但是，不管我把这件事交给利益相关者，我似乎无法让他们明白我的价值。对他们来说，重构是对时间的一种非建设性的浪费(根据其定义，用户应该不会看到应用程序中的任何变化)。对于他们来说，它没有提供任何业务价值(或者至少没有直接的业务价值)，因为它没有提供任何新的特性，而且他们会强烈抵制任何重构。
我不可能在代码库中不进行重构，因为我以前也有过这样的经历，我已经看到了它是如何结束的。所以，当我在做一个功能的时候，我会偷偷地把它藏进去。我更愿意公开地这样做，这样利益相关者就可以更清楚地了解开发过程。
有什么办法让这件事过去吗？
回答 2
Software Engineering用户
发布于 2013-06-13 08:52:23
我更不愿意用这样的技术细节来打扰非技术人员。对我来说，重构只是交付特性的过程的一部分(因此也是特性评估的一部分)。
如果你真的要把重构卖给非技术人员，我会把它作为防止错误的措施(通过降低复杂性和复制，减少引入bug的风险)和为下一个特性节省X倍的时间(向结构良好的可维护代码添加新特性要容易得多)。这样，价值不在于它现在增加的业务价值，而在于下周/月/年生产率的提高。
Software Engineering用户
发布于 2013-06-13 10:57:31
我认为我们需要在这里区分重构与重新设计。
- 重构嵌入到小的开发循环中，它不应该跨越一个TDD周期或任务，当然也不应该是一个单独的故事。这是使您的代码质量代码的那些微观实践之一。由于敏捷质量是不可协商的，而且重构在涉众级别上基本上是不可见的，您甚至不应该告诉您的涉众您正在这么做，就像您没有告诉他们您正在使用这种设计模式或那种编程风格一样。
- 另一方面，重新设计可以持续更长的时间。它正在改变代码库的所有部分，以减少技术债务。它可能在整个模块上用依赖注入取代紧密耦合，它可能正在引入AOP以消除重复的日志记录代码，它可能正在修改您的数据访问对象的工作方式，以允许更高效的数据库查询。当然，您并没有改变任何功能，但是这么大的重构可能对项目产生的影响是值得决策者提及的。在这里，您通常会创建一个技术案例，或者在涉众批准了这个想法之后，您的待办事项会激增。即使它们不是那么容易找到，但与简单的重构(性能、错误修复、维护成本、部署成本、代码库学习曲线成本等)相比，通常可以使用更多的论据。如果他们认为这种努力不值得--好吧，这是他们的产品，你一定要警告他们可能会发生什么。
所以我的建议是:不要试图说服利益相关者，让他们相信你作为一名专业人士的每一分钟都是如何工作的--这是不可商量的。尝试做更多的重构，以尽量减少重新设计的数量，您将不得不证明以后。
https://softwareengineering.stackexchange.com/questions/201396
复制相似问题
腾讯云开发者
