一致性与设计指南

Question

让我们说你参与了一个已经开发了很长时间（超过一年）的大型项目的开发。这些项目遵循一些当前的设计指南，但也有一些不同的，目前不鼓励（主要是在命名指南）。

假设您不能/不允许更改整个项目：

什么应该更重要，一致性，遵循现有规范并违反当前指南或指南的使用，在同一项目的模块之间创建差异？

感谢。

Answer 1

一般来说，我赞成一致性。但有时候有很多理由偏爱进化的风格。也许最初的标准被认为是无效的，或者仅仅是施加了太大的开销。回过头来改造这些变化可能是过分的，但是继续遵循现在已知的以一致性为名的不良做法，我认为这是一个错误的决定。

一个具体的例子：30人，三年的项目。我们的标准是在每个方法之前放置一些特定的文档（不记得细节，认为它是可以记录的消息列表或者其他类似的。）这被发现需要维护很多工作并且是从不使用，因为我们有一个代码munger来生成消息来源的确定列表。我们只是停止将信息添加到新方法中，没有时间来整理代码库的完整性。

Answer 2

一如既往，这取决于。

如果这是一个你将要长期工作的项目，那么值得做出改变或引入改进以实现一致性。对于寿命较短的项目，我不会打扰。

通常这个问题最好是那些发明了这些指南的人 - 在指南中可以注意到“现有的应用程序已经过时，但新的模块必须至少遵循......”等等。

Answer 3

整天保持一致。 （除非一切都很糟糕，否则我会找到一个新项目！）

Answer 4

我更倾向于在项目中保持一致，但如果可能的话，说服“更高层次”，重构将是最小的（如果它真的只是命名约定），并且会使可维护性更容易，因为这该计划将与其他过去/未来的项目保持一致。

Answer 5

假设您不能/不允许更改整个项目：

坚持一致性，但如果您的团队和管理层愿意接受建议，请与他们讨论，因为正确的对话会为您即将开展的项目增添很多。

Answer 6

一个很好的问题和一个难以处理的问题。

我见过一个项目，其中有几个技术主管彼此跟随，每个项目都将自己的架构和编码指南带到了开发的新功能中，但保持现有代码的完整性。 这导致了一个混乱的，完全不同的代码库，每个模块都与其他模块不同，使整个事情难以理解。

如果您可以根据新指南重构现有代码（如果团队的其他成员都可以，那么您应该绝对这样做。）

否则只要坚持当前的编码实践，只要它们不会产生未来不受控制的技术债务。