Priority: P2: Important
Affects Version/s: None
Fix Version/s: None
Component/s: Build tools: qdoc
Sprint:Da Vinci sprint 49, Da Vinci sprint 50
QDoc, as a software with many years on its shoulder, has a series of architectural defect that are inhibiting our ability to test it correctly and our speed of development.
Ranging from an extreme coupling between parts, the implicit use of mutable-state global dependencies, an unclear separation of concerns for parts of the code and micro-level issues such as unneeded work being performed, leftover code that is dead, unclear boundaries that disallow understanding guarantees on the data flow and other such issues.
To improve our ability to develop new feature, move to a more modern architecture that can bring new capabilities to QDoc, such a plugin based architecture focused on extensibility, and provide a valuable testing suite that codifies our understanding of QDoc's behavior, design and implement an intermediate architecture that splits QDoc into two parts:
- A QDoc library that codifies the logic required by QDoc to currently work
- A QDoc drive that uses the QDoc library to implement the current QDoc
To do this, a series of systems should be extracted from the current codebase, modified slightly to ensure that they do not depend on other parts of QDoc and tested.
The constrain for each subsystem will be to have as much independence as possible, to break the coupling that is present in the current codebase, albeit this will increase code duplication in the short-term.
No generalization should be applied where possible, aiming only to preserve the ability to keep the current code working while in this intermediate step.
The result of this process is an intermediate form of QDoc that must respect as much of the currently existing semantic as possible, even where we would otherwise see room for improvements, and that is thoroughly tested.
This process should be performed on its own branch, parallel to the normal development of QDoc.
Outside the scope of this task is developing new features or improving the currently existing one, instead focusing on infrastructural work that can be used as a base to actually move towards a cleaner architecture and the development of new systems.