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

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

见 this excellent screencast 例如,可以在不造成太多干扰的情况下对遗留代码执行的操作。

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

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

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

不过,除此之外,这可以归结为 最佳做法 . 几乎所有“好”的编程实践都是为了便于维护。良好的设计和施工实践会导致项目更容易被后来的开发人员掌握。steve mcconnell谈到管理复杂性是软件工作的中心任务。如果预先对复杂性进行了很好的管理,那么对于后来的人来说,保持项目的概念完整性将更容易。

另一方面,良好的维护实践包括 对抗熵 。保持系统处于测试状态。不要为了快速修复或新特性而降低内聚性或增加耦合。实际上,目标是使项目与所做的每一个更改更加一致。

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

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

其主要思想是,维护应该是一个不断改进项目的过程,而不是不断降低项目的质量。关于这个话题的一本好书是迈克尔·费瑟的 Working Effectively with Legacy Code . 你可能想看看。