Guideline 👌

---

Plan 📒:

• Multi-branching strategy is used alongside Git over Github

• Configure the SCM server as Github to make a mandatory pre-check to stop the merge to the master-branch until the approval ✅ of the pull request

• New copy is made of source code using a new branch forked from master-branch named feature-branch_ticket-number

• A pull request SHOULD BE MADE upon completion from juniors or seniors, and point this PR to master-branch for merging later upon full approval ✅

  • The ticket state shall be changed according to this flow upon being ready for review
  • The 1st reviewer (approver) shall review 👀 and approve ✅ the pull request which is done via a Senior (Java | JavaScript) Developer [backend | web-frontend | mobile-frontend]
  • The 2nd approver shall approve ✅ the pull request which is done via a Java Architect and merge it to the master-branch
    • Codebase auditing.

---

Guide for day to day work as a REVIEWER [over production code only, AKA money 🤑]:

• Under this directory src/main/** 🤑, but note that Test-code (unit and integration tests) will be in the future 😂 🤣 😉 🤖 💩 ☠ when a stable trusted verified complete software is made, also note that current stuff in our world are running via the mercy of Allah (Our GOD, the ONLY creator of this universe) and will always. Just good intention mate 😇

• Validating the feature-branch correctness as a black box, using ticket as a reference.

  • Have a local copy on your machine as a reviewer for full control

• Check the written code to see:

  • Is it well formatted via the IDE's formatter for the future readability purposes?
  • Is it well structured as the [Java Architect] planned or not, to eliminate the code pattern anomalies to deliver a live documentation at the end without the need to waste time on handover sessions 🤮 because it's non-sense bull shit?
  • Is it a better way of something can be used or not?
    • Use a polite way to give a reasonable amount of time to your teammates to think/reasoning about what you have found so far, and your findings from the original references [docs] to prove it before declaring it to them

• When you identifies an issue, then you have to do it and take your time ⌛ to understand its POV. Beside that it's better to have a look at CODE-REFACTORING.