How to maintain/document a monster project?

Question

Project management

Good afternoon.

There is a web engine on which there are a bunch of sites.
The project is under constant development.
Initially, the project was very beautiful and all sites worked the same way.
But constantly one, another, third site is asked for unique functionality.
Plus, there is an addition of additional general functionality.

As a result:
There is a functioning and not very crutch project (in my opinion).
But after a while, no one can remember how everything works. In general terms, everyone knows, but little things - no.
For example - who changes the status of a user? It is clear that there is a component directly managing the table and so on, but who uses it? At what moments? console script, maybe api? maybe the user is not logged in yet? Or was it blocked?

There is documentation of classes, methods, etc., but in this case it most likely will not help.
What are the options for management, knowledge bases or something else?
Thanks

Answer 1

Rewrite everything again

Answer 2

You have two different questions.

who uses it? At what moments? console script, maybe api?

There must be a correct project structure.
Framework and other third-party libraries - in the vendor or node_modules
folder. Your engine - in a different folder.
Each site is in a separate folder. If it has its own functionality or redefinition of the base - inheritance from the base.
Then the answers to your questions are very simple:
* what kind of functionality - to open an inherited class. The IDE has a tooltip icon.
* who uses - the IDE has "Find usages"

maybe the user is not logged in yet? Or was it blocked?

For this, there must be logging. If we are talking about scripts, then git. If about a change in the database, then triggers at the database level or prohibition of direct access to the database, and work only through the model and logging.

Answer 3

The difference must necessarily be an extension of the basic functionality (statically - through inheritance), or work through a standardized interface (dynamically - API for plugins).
It is better to replace crutches with a bunch of ifs with polymorphism using IoC via DI and the idea of ​​the Strategy pattern .
It makes no sense to maintain detailed development documentation, as practice shows - it is difficult to maintain it. You can start a wiki or even documents that describe in general terms the operation of certain non-obvious nodes.
From the point of view of the logic of the application, in serious QA offices they write test cases that fix the requirements. This is useful to refresh your memory. (test cases do not become obsolete, because each release runs a full regression cycle)

Answer 4

The correct architecture, it documents itself, as it reflects the ongoing processes. Documentation is built into the project from the very beginning. Each language has its own tool for automatic doc generation. Although it’s right to immediately make a guideline + a general model of all business processes, plus cutting into microservices.
In your case, it's too late to drink Borjomi when the liver is dead. Since the project is out of control and situations where there is at least someone who can describe the work of your service. And they wrote you one of two ways out - to rewrite from scratch. The second way out is to fork, plant five people and let them understand the code and how it works, at the same time document it. There are simply no other means.
Although I'm not lying, I'm lying. there is. Write a neuron, parse the code, make an AST, feed it to the neuron and let it document it. I think it will cost more than your entire project in principle.