maintenance - 在维护期间保持系统的概念完整性

Question

在开始一个新项目时，我们会根据“最新”和“已知”来启动它。

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

事情进展顺利，直到我们完成开发并将其推向生产。

然后是维护（缺陷修复和增强）。人变了，建筑师和设计师搬走了。

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

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

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

Answer 1

1. 从最小的改变开始。
2. 进入项目的风格。
3. 创造理智岛。
4. 每次提交都必须改进代码的状态。

请参阅此出色的截屏视频，了解可以在没有太多中断的情况下对遗留代码执行哪些操作。

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

Answer 2

保持概念的完整性是困难的。这是一个需要在架构、设计和施工过程中不断解决的问题，而且当项目易手时，情况只会变得更糟。

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

不过，除此之外，这归结为最佳实践这个巨大的话题。几乎所有“好的”编程实践都旨在易于维护。良好的设计和施工实践导致项目更容易被后来的开发人员掌握。Steve McConnell 谈到管理复杂性是软件工作的核心要求。如果事先对复杂性进行了良好的管理，那么对于后来者来说，保持项目概念完整性的完整性会更容易。

另一方面，良好的维护实践涉及对抗熵。保持系统处于测试状态。不要为了快速修复或新功能而降低内聚或增加耦合。事实上，旨在使项目与所做的每一次更改都更加一致。

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

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

主要思想是维护应该是一个不断改进项目的过程，而不是不断降低它。Michael Feathers 的《有效地处理遗留代码》是一本涉及该主题的优秀书籍。你可能想检查一下。