一致性与设计指南

总的来说,我倾向于一致性。但有时有强烈的理由更喜欢进化的风格。也许最初的标准被发现是无效的,或者只是强加了太多的开销。回到过去并改进这些变化可能是过分的,但是继续以一致性的名义遵循现在已知的不好的做法,我认为这是一个不好的决定。

一个具体的例子:30人,三年项目。我们的标准是在每个方法之前放一些特定的文档(不记得细节,认为它是一个可以记录的消息列表或其他类似的东西)。 从未 使用,因为我们有一个代码munger来生成消息来源的最终列表。我们只是停止向新方法添加信息,没有时间获取和整理代码基的完整性。

一如既往,这取决于。

如果这是一个你将长期致力于的项目,那么为了达到一致性,进行更改或引入改进是值得的。对于寿命较短的项目,我不介意。

不过,通常这个问题最好问那些发明了指南的人——可以在指南中注意到,“现有的应用程序是外生的,但新的模块必须至少遵循……”之类的话。

一整天都很稳定。(除非所有的事情都不好,否则我会找到一个新的项目!)

我更倾向于在项目中保持一致性,但如果可能的话,我会说服“高层”相信重构是最小的(如果它只是命名约定的话),并且会使可维护性变得更容易,因为这个程序将与其他过去/将来的项目相一致。TS。

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

坚持一致性,但如果你的团队和管理层对建议持开放态度,一定要和他们讨论这个问题,因为适当的谈话会给你即将进行的项目增加很多东西。

一个伟大的问题和一个棘手的问题。

我看过一个项目,几个技术领先者接踵而至,每个人都将自己的体系结构和编码准则带到开发的新功能中,但保持现有代码的完整性。 这导致了一个杂乱无章的代码库,其中每个模块都与其他模块不同,这使得整个过程很难理解。

如果您可以根据新的准则重构现有的代码(如果团队的其他成员都同意的话),那么您绝对应该这样做。

否则,只要当前的编码实践没有滋生技术债务,在未来会变得不受控制,就只能坚持下去。