Feat/create application review

[JamieXiao]

Tickets:

• HAC-

List of changes:

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

• Added reviewer status (hacker/reviewerStatus, hacker/reviewerStatus2), name (hacker/reviewerName, hacker/reviewerName2), and comments (hacker/reviewerComments, hacker/reviewerComments2)
• Currently hardcoded 2

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How has this been tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A
• Test B

Test Configuration:

Firmware version:
Hardware:
Toolchain:
SDK:

Questions for code reviewers?

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Listed change(s) in the Changelog
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules

[tektaxi]

Looks good!! This is super detailed, thorough, and works perfectly. Thank you so much. See my comment on one of the files about the modularity and duplicate logic, I think that is true throughout many of these files here. If we can reduce duplicate functions for each individual field and make the logic for app review more modular overall that would be great.

[tektaxi]

non-blocking:
instead of doing this as a list of variables, couldn't lines 28-44 be wrapped into one {} object?
ie. HACKER_REVIEW_STATUSES = {NONE : 'None', POOR : 'Poor', etc.}

[tektaxi]

We have actions and functions for each individual field that we've added to the hacker's profile in the db. Because the fields for reviewers 1 and 2 are exactly the same, why are we defining all these variables and functions separately for reviewername and reviewername2, reviewercomments and reviewercomments2, etc... ? It seems like the logic for both reviewers could be made more modular, and that would also make it much easier to extend to more reviewers in the future if needed. We have a lot of duplicate code/logic now, which will be hard to maintain. Is this assessment correct? lmk if I'm missing anything there