在开始一个新项目时，我们会根据“最新”和“已知”的内容启动它。
这包括选择编程语言，这些语言的框架等。在使用特定框架和设计模式等方面，花费了大量时间在架构设计和详细级别设计上。
在我们完成开发并将产品投入生产之前，事情一直很顺利。
然后是维护（缺陷修复和增强）。人们改变了，建筑师和设计师搬了出来。
可能没有任何项目历史细节的新人现在正在维护它。他们开始在架构，设计原则等方面构建内容，以提供快速修复和添加增强功能。
我在许多项目中看到过这种趋势。
如何在进行维护时保持系统的“概念完整性”？
答案 0 :(得分：1)
请参阅this excellent screencast，了解遗留代码可以执行的操作，而不会造成太多中断。
当然，这要求管理层致力于采用代码质量优先的策略，使这些修复能够“正确”。
答案 1 :(得分：1)
维护概念完整性很困难。这是一个需要在架构，设计和构造过程中不断解决的问题，而且只有在项目转手时才会变得更糟。
有一点可以帮助原始开发团队的人员参与维护。已经了解项目概念框架的人将比从头学习它的人更能够保持该框架。
除此之外，这可归结为最佳实践这一巨大的主题。几乎所有“好的”编程实践都旨在简化维护。良好的设计和施工实践使得后期开发人员更容易掌握项目。 Steve McConnell谈到管理复杂性是软件工作的核心要求。如果事先很好地管理复杂性，那么后来的人将更容易保持项目的概念完整性。
另一方面，良好的维护实践涉及反对熵。保持系统正在测试中。为了快速修复或新功能，不要降低内聚力或增加耦合。实际上，旨在使项目与每次变更更加一致。
如果系统的设计考虑了可扩展性，那么维护程序员在完成工作时保持概念完整性并不困难。即使不是这样，它们仍然有可能在维护期间改进项目而不是进一步降低项目。
如果维护开发人员简单地将事情放在一起并以“简单”的方式执行操作，那么它将始终降低概念完整性并增加项目的复杂性。开发人员必须意识到这一点，他们必须有意识地选择最能让他们避免的做法。
主要思想是维护应该是一个不断改进项目的过程，而不是经常降低它。 Michael Feathers'Working Effectively with Legacy Code是一本关于这个主题的优秀书籍。你可能想看一下。