Problem Statement
Because of the unwieldy size and low maintenance of edx-platform, we see:
- code complexity
- code coupling
- circular dependencies amongst modules
- unclear interfaces and boundaries
- lack of code organization
- code located in surprising places
- tests duplicated and in multiple places
- lack of documentation
- lack of testing standards
As a result of the above, we see:
- high developer cognitive load
- slow tests
- escaped bugs
- low team velocity
- high tech debt
Plan of Attack
We are attacking this issue from various directions, including:
- Creating Component Architecture documents in the Architecture space with
- Sequence Diagrams
- Component Diagrams
- Developing an agreed upon Testing Best Practices with Testing tools for interface testing with realistic data.
- Developing a hierarchical system-level architecture diagram with clear roles and responsibilities
- Phase 0 (CURRENT): Create spreadsheet enumerating all folders within LMS, CMS, and openedx/common.
- Include sub-folders that have large enough sub-features/responsibilities.
- Fill out the following columns: path, name, role & responsibility, known violations.
- Phase 1 (DESIRED): Group folders from Phase 0 into logical containers, each with their own role and responsibility.
- Create a dependency hierarchy for a desired layered architecture.
- Denote points of desired decoupling by both space (independent deployment units) and time (async connections)
- Phase 2 (ASSESS): When working in an area, a team can take the desired behavior from Phase 1 and assess the subsystem.
- Define synchronous and asynchronous interfaces.
- Document violations of abstractions and layering.
- Phase 3 (MODIFY): When working in an area, a team can refer to the assessment in Phase 2 and update the subsystem as desired.
- Phase 0 (CURRENT): Create spreadsheet enumerating all folders within LMS, CMS, and openedx/common.
Phase 0 Notes:
- Create plan for automating metadata extraction from code to output the equivalent of the spreadsheet.
- Create "Draft Best Practices" page.
- Creation of new things. Where does it go?
- Cleaning up old things. Common libs pip installed should no longer be pip installed.
Phase 1 Notes:
- Next Steps:
- Validate seams
- Review by stakeholders: Learner, Educator, Business, Analytics, TestEng, Platform, Eng Management
- Run-through a few use-cases
- Move to logical components within edx-platform
- Dependency analysis to find low-level, high-level, etc components
- Move low-level components to their own repos
- If modified a lot
- if not modified a lot
- Best practices (OEP)
- clear interfaces
- folder structure
- etc
- Move current pip-installable apps in edx-platform into their own repo (common/lib/*)
- Reduce # of acceptance tests
- Validate seams
- Folder example:
- openedx/
- capa/
- discussions/
- grades
- course-blocks/
- courses
- certificates
- middleware
- core
- cms?
- openedx/
Agents
Robert Raposa, Andy Armstrong (Deactivated), Scott Dunn (Deactivated), Nimisha Asthagiri (Deactivated)