在维护期间维护系统的概念完整性

Question

当开始一个新的项目时，我们根据什么是“最新的”和什么是“已知的”来启动它。

这包括编程语言的选择，这些语言中的框架等。在使用特定框架和设计模式等方面，相当多的时间花在架构设计和详细级别设计上。

在我们完成开发并将其推向生产之前，一切都很顺利。

然后是维护(缺陷修复和增强)。人变了，建筑师和设计师搬出去了。

一群可能没有任何项目历史细节的新成员现在正在维护它。它们开始包含架构、设计原则等内容，以提供快速修复和添加增强功能。

在我工作过的许多项目中，我都看到了这种趋势。

在进行维护时，如何维护系统的“概念完整性”？

Answer 1

1. 从最小的更改开始。
2. 进入了这个项目的风格。
3. 创建了理智的孤岛。
4. 每次提交都必须改善代码的状态。

有关可以在不造成太多干扰的情况下对遗留代码执行哪些操作的示例，请参阅this excellent screencast。

当然，这需要管理层对代码质量优先策略的承诺，才能使这些修复“正确”。

Answer 2

维护概念上的完整性是困难的。这是一个在架构、设计和建设过程中需要不断解决的问题，当项目易手时，它只会变得更糟。

可以帮助的一件事是让原始开发团队的人员参与维护。与从头开始学习的人相比，已经对项目的概念性框架有了概念的人将能够更好地保持该框架。

除此之外，这可以归结到最佳实践这个庞大的主题上。几乎所有“好”的编程实践都是为了便于维护。良好的设计和构造实践可以使项目更容易被后来的开发人员掌握。Steve McConnell谈到管理复杂性是软件工作的中心任务。如果复杂性在前期得到了很好的管理，那么对于后来的人来说，保持项目的概念完整性将更容易。

另一方面，良好的维护实践涉及对熵的工作。保持系统处于测试状态。不要为了快速修复或新特性而降低内聚力或增加耦合性。事实上，目标是使项目与所做的每一次更改更加连贯。

如果系统的设计考虑到了可扩展性，那么对于维护程序员来说，在工作时保持概念上的完整性是不困难的。即使不是，他们仍然有可能在维护期间改进项目，而不是进一步降低它。

如果维护开发人员简单地将事情组合在一起，并以“简单”的方式做事情，那么它总是会降低概念的完整性，并增加项目的复杂性。开发人员必须意识到这一点，他们必须有意识地选择最能避免这种情况的实践。

主要思想是维护应该是一个不断改进项目的过程，而不是不断地降低它。关于这一主题的一本优秀的书是Michael Feathers的Working Effectively with Legacy Code。你可能会想去看看。