Difference between revisions of "Codebase Refactor"
From OpenEMR Project Wiki
Matthew Vita (talk | contribs) |
Matthew Vita (talk | contribs) |
||
| Line 3: | Line 3: | ||
== Tasks == | == Tasks == | ||
* (UNASSIGNED) This project has gone stale, but it is worthwhile to determine if any code can be used as inspiration: http://www.open-emr.org/wiki/index.php/Medmasterpro_API_Review | |||
* (UNASSIGNED) Determine if we want to go with a 3-tier architecture | * (UNASSIGNED) Determine if we want to go with a 3-tier architecture | ||
* (UNASSIGNED) Demonstrate initial DAO models using Zend ORM | * (UNASSIGNED) Demonstrate initial DAO models using Zend ORM | ||
| Line 12: | Line 13: | ||
* (UNASSIGNED) Decompose major system parts into Zend modules (please break this up into separate tasks per identified module) | * (UNASSIGNED) Decompose major system parts into Zend modules (please break this up into separate tasks per identified module) | ||
* (UNASSIGNED) Integrate standard place for static CSS/JS assets | * (UNASSIGNED) Integrate standard place for static CSS/JS assets | ||
== Notes == | == Notes == | ||
| Line 23: | Line 18: | ||
* In order to verify that the codebase refactor is correct as new modules are introduced, high-quality manual test cases need to be built up and maintained moving forward... reach out to that team throughout the process. | * In order to verify that the codebase refactor is correct as new modules are introduced, high-quality manual test cases need to be built up and maintained moving forward... reach out to that team throughout the process. | ||
* There are some in the community that do not want to go forward with Zend, so keep in mind that we don't need to use everything in Zend. We should only be using the bits that make us productive (i.e.: allow us to not reinvent wheels). | * There are some in the community that do not want to go forward with Zend, so keep in mind that we don't need to use everything in Zend. We should only be using the bits that make us productive (i.e.: allow us to not reinvent wheels). | ||
* The full UI rewrite can happen later... let's just make the current system work as is but with a new backend | |||
* A standard way to document can happen later... let's just document as needed for now | |||
* A standard code style checking mechanism can be integrated later... let's uses 2 spaces and not do anything odd for now | |||
* CI can happen later | |||
Revision as of 20:25, 6 July 2016
Objective
To refactor the codebase to leverage the MVC design pattern, unit tests, and a more maintainable design.
Tasks
- (UNASSIGNED) This project has gone stale, but it is worthwhile to determine if any code can be used as inspiration: http://www.open-emr.org/wiki/index.php/Medmasterpro_API_Review
- (UNASSIGNED) Determine if we want to go with a 3-tier architecture
- (UNASSIGNED) Demonstrate initial DAO models using Zend ORM
- (UNASSIGNED) Setup Composer
- (UNASSIGNED) Integrate models for all major objects (please break this up into separate tasks per object)
- (UNASSIGNED) Normalize directory structure (please break this up into separate tasks per domain)
- (UNASSIGNED) Separate logic into MVC using Zend conventions (please break this up into separate tasks per domain)
- (UNASSIGNED) Unit tests (please break this up into separate tasks per domain)
- (UNASSIGNED) Decompose major system parts into Zend modules (please break this up into separate tasks per identified module)
- (UNASSIGNED) Integrate standard place for static CSS/JS assets
Notes
- The codebase has probably over 500,000 LoC in it. This process must be done in a very piecemealed way.
- In order to verify that the codebase refactor is correct as new modules are introduced, high-quality manual test cases need to be built up and maintained moving forward... reach out to that team throughout the process.
- There are some in the community that do not want to go forward with Zend, so keep in mind that we don't need to use everything in Zend. We should only be using the bits that make us productive (i.e.: allow us to not reinvent wheels).
- The full UI rewrite can happen later... let's just make the current system work as is but with a new backend
- A standard way to document can happen later... let's just document as needed for now
- A standard code style checking mechanism can be integrated later... let's uses 2 spaces and not do anything odd for now
- CI can happen later
