The metrics list has been broken into individual categories. 4 of them to be exact: Complexity, Keywords, Coupling, and Size. For the sake of evolvability and development, it'd be nice to have a class design for this. This would likely include an abstract class/interface and plans for each of the 4 classes. OOP principles should be followed, function names and documentation would also be nice, UML required. Skeleton file wouldn't be a bad idea (NO ACTUAL CODING).
If skeleton files are added, we should see what the commit history looks like to know how big our commits should be. Wouldn't hurt to know this in general tbh.
Related Epic:
Metrics Backend
Number Of Story Points: 2
Acceptance Criteria:
[x] Done when UML is finished for the metrics categories code
[x] Done when a list of functions and their purposes is written out.
[x] Done when this documentation is provided in the Drive
[x] If Skeleton files deemed necessary, done when a PR is made with those skeleton files in the repository.
Description:
The metrics list has been broken into individual categories. 4 of them to be exact: Complexity, Keywords, Coupling, and Size. For the sake of evolvability and development, it'd be nice to have a class design for this. This would likely include an abstract class/interface and plans for each of the 4 classes. OOP principles should be followed, function names and documentation would also be nice, UML required. Skeleton file wouldn't be a bad idea (NO ACTUAL CODING).
If skeleton files are added, we should see what the commit history looks like to know how big our commits should be. Wouldn't hurt to know this in general tbh.
Related Epic:
Metrics Backend
Number Of Story Points: 2
Acceptance Criteria:
Comments