Do not allow to publish when there is a circular dependency
128
Views
8
Comments
New
1CP

To keep the code cleaner and avoid circular dependencies, it would be interesting not to let a module publish when you had to create circular dependencies.

Daniël Kuhlmann
mvp_badge
MVP
Changed the category to
1CP

Yes agree with this idea.
If circular dependencies found during compile, it should warn or stop developer.

Because at a later stage when product grows, it can be quite complicated to resolve circular dependencies. Better to stop or warn from beginning.

Regards,
Palak Patel

Agree, identification at early stage and forcing developer to review the module dependency will help in preventing major technical dept.

Thanks,

Preeti Kumari

Good idea, especially since circular dependencies can have many negative repercussions. I would go as far as to block publishing, but at least give a warning on service studio, not everyone as access to Discovery or Architecture Dashboard. I have been in clients where Architecture Dashboard was not allowed (go figure...) or where IT users where not given a Discovery user, being the task of the Tech Lead to validate these things. So I agree that it would be good if developers get a warning in service studio itself.

Good idea, but will it work in practice ? 

At least leave the option to: 'force publish' which behaves as it does now.

We inherited this large application where I have all kinds of circular, upward, side references. The client wants us to take over and fix a couple of things; we'll be doing a rebuild/refactor later. But I can't go to the client and say: your old supplier screwed up and I can't maintain the app anymore. I can just rebuild it and that will cost you 100's of €'s and it will take weeks maybe months in the situation I am in now.

Joost Miltenburg, you are absolutely right, but launch a pop-up with the explanation of circular dependencies so the programmer knows that he would publish a module that will have circular dependencies.

Of course, prevention works best. I would just want to be able to override the blockage. Let's try to keep thinking ourselves before we let the machines take over.

Of course, prevention works best. I would just want to be able to override the blockage. Let's try to keep thinking ourselves before we let the machines take over.

J.
mvp_badge
MVP

In itself it tends to be a good idea, but overall I would disagree on this.

for example: You prevent sandbox-modules to be published.

for example : When you do refactoring, you can end up temporarily with circular references, so you need to fix all the issues before you finally can publish...

Lastly, do you mean only a direct circular reference (module A - module B), or every circular reference, because that can take up some serious amount of calculation which slows the whole publishing down.

If it's only the first, you do not cover the whole spectrum of circulars, which is inconsistent and that might be even a worse result.