Topic on Talk:Architecture:MediaWiki/Technical layers

As I understand the proposal, code in "higher" layers can call code in "lower" layers. But the reverse is not allowed, If a class/function/etc. is determined to be miscategorized and is moved from a lower layer to a higher layer, some code that previously called it may no longer be able to.

Does this introduce a maintenance/deprecation situation that we should (a) be aware of and (b) create policies around.

Clearly, the best answer is "don't get it wrong in the first place", but ... stuff happens.

Also, this highlights the need for tooling around layers. It would be easy to miss some callers when refactoring after moving code between layers. Without tooling to help us catch the mistake, the code will happily continue to execute and it might be some time before the violation is noticed.

Yes, you are right, we need a tool to generate reports before we can truly establish layers. This tool could work something like this:

Group all classes by their layer (according to the @layer annotation). Classes without such an annotation go into a special "unknown" group, which is allowed to access most layers. Count "bad" dependencies for each group. For a given patch, the size of the "unknown" group should not grow, and the total number of "bad" dependencies should not grow. To allow us to incrementally introduce annotations, it's ok for the number of "bad" relationships to grow if the size of the Unknown group goes down at the same time.

This analysis should be integrated with CI. It should of course only start voting and blocking patches once we have annotated a good portion of the code.

This should not be hard to do, a simple version sounds like a nice weekend project. But we need to survey which software we want to build on and what we want to integrate with.

It's a bit of a chicken and egg problem, though. If we don't have agreement that we want to establish layers, there is no point in spending time on the tooling. But without the tooling, it's hard to establish a layer system.

As to deprecation: it would be very useful if we could ignore dependencies caused by deprecated code. I have not seen any analysis tool that does this, but I have talked to the maintainer of one such tool, and they seem open to adding it: https://github.com/mihaeu/dephpend/issues/42