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