Consistency and design guidelines

Question

Suppose you are involved in the development of a large project that has already been under development for a long period (more than one year). Projects follow some of the current design guidelines, but also have several different ones that are currently discouraged (mostly by naming conventions).

Suppose you cannot / cannot change the whole project:

What should be more important, consistent, follow existing ones, and ignore current guidelines or the use of guidelines, creating differences between modules of the same project?

Thanks.

Answer 1

Generally, I would maintain consistency. But sometimes there are good reasons for preferring a developed style. Perhaps the original standards were ineffective or simply imposed too much overhead. It may be excessive to revert and modify changes, but continue to follow what is known to be bad practice in the name of consistency, which I consider a bad decision.

Case study: 30 people, three-year project. Our sai standards place any specific documentation in front of each method (don’t remember the details, consider this to be a list of messages that may be logged or some of them). It was discovered that a lot of maintenance work was never used because we had the munger code to create the final list of message sources. We just stopped adding information to new methods, did not manage to get and remove the enthusiasm of the code base.

Answer 2

As always, it depends.

If this is a project that you intend to work on for a long time, it’s worth making changes or making improvements to achieve consistency. For projects with a shorter lifespan, I would not worry.

Usually this question is better asked to those who invented the guidelines, although the guidelines may note that "existing applications are suggestible, but new modules should follow at least ..." or something else.

Answer 3

Consistency all day. (If everything is not so bad, then I will find a new project!)

Answer 4

I would be more inclined to be consistent within the framework of the project, but, if at all possible, convince "above" that refactoring will be minimal (if it is really just naming conventions), and also simplify simplification, since this program will be consistent other past / future projects.

Answer 5

Suppose you cannot / cannot change the whole project:

Maintain consistency, but if the team and management are open to suggestions, discuss this with them, as having the right conversation will add a lot to your future projects.

Answer 6

Great question and hard problem.

I saw a project in which several technology leaders followed each other, each of whom brought their own principles of architecture and coding to new functions that were developed, but keeping the existing code intact. This led to a cluttered, fragmented code base, where each module was different from the others, which made all this very inconvenient to understand.

If you can reorganize the existing code in accordance with your new recommendations (and if the rest of the team is fine with this), you should absolutely do this.

Otherwise, simply adhere to existing coding rules if they do not create technical debt that will be uncontrollable in the future.