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

Question

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

这包括编程语言的选择，在这些语言等框架相当多的时间都花在了建筑设计和详细设计水平在使用特定的框架和设计模式等

事情精细走的条款直到我们完成开发并推动生产。

然后来维护（缺陷修复和增强）。人们改变了，建筑师和设计师搬了出去。

新的一组谁可能没有任何项目的历史细节正在维持它。他们开始构建架构，设计原则等方面的东西，以提供快速修复和增强功能。

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

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

Answer 1

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

查看this excellent screencast了解可以在没有太多中断的情况下对遗留代码进行的操作。

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

Answer 2

保持概念完整性很困难。这是一个在建筑，设计和施工过程中需要不断解决的问题，并且只有项目易手时才会变得更糟。

有一件事可以帮助原始开发团队的人参与维护。有人已经对项目的概念框架有了一个概念，但比从头开始学习的人能更好地保持这个框架。

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

另一方面，良好的维护做法涉及熵熵的工作。保持系统在测试中。为了快速修复或新功能，不要降低内聚力或增加耦合度。实际上，我们的目标是使项目与所做的每一项改变更加一致。如果系统的设计考虑到了可扩展性，那么维护程序员在完成工作时就能够保持概念完整性并不困难。即使不是这样，他们仍然可以在维护期间改进项目，而不是进一步降低项目。

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

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