Difference between revisions of "Codebase Refactor"

From OpenEMR Project Wiki
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Objective ==
Codebase refactor to leverage the MVC design pattern and be more organized.
To refactor the codebase to leverage the MVC design pattern, unit tests, and a more maintainable design.


== Tasks ==
* task board: https://github.com/openemr/openemr/projects/2
* (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
* slack channel: https://openemr.slack.com/messages/modernization/
* (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 here: http://open-emr.org/wiki/index.php?title=Manual_Tests
* 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

Latest revision as of 03:34, 3 November 2016

Codebase refactor to leverage the MVC design pattern and be more organized.