My progress
Menu

Software Architect / Tech Lead · Focus area 3: Engineering leadership

AR8: Engineering standards and code review

Goal: write a small set of coding standards with reasons, automate the ones a tool can check, run code reviews that find what matters, give feedback that is kind and specific, and keep standards owned by the team as they change.

You'll need: AR3 Lesson 4, AR4, Module 26 (Debugging and Testing), Module 46 (Backend Testing), Module 71 (CI/CD), Module 77 (Encryption and Secrets), Module 78 (Secure Development), and the RasoiRoute practice kit (standards.config.json, tools/lint.js, reviews/).

Where this is used: every team that shares code. Standards and reviews are how a team keeps a codebase that any of its members can change safely, and how new engineers learn the team's habits.

How it differs: earlier modules shaped systems. This module shapes habits: the everyday rules and conversations that decide whether a good architecture stays good.

Time: reading about 3 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1Standards worth havingReading 15–25 minutes, plus practice✓
  2. 2Automating standardsReading 15–25 minutes, plus practice✓
  3. 3Code reviewReading 15–25 minutes, plus practice✓
  4. 4Feedback that helpsReading 15–25 minutes, plus practice✓
  5. 5Templates, ownership and changing the standardsReading 15–25 minutes, plus practice✓

🛠️Assignment: Standards and a review for RasoiRoute

  1. Rewrite docs/standards.md with at least eight rules, each with Why, Checked by and an example, plus Version, Last reviewed and a change process.
  2. Switch on the matching rules in standards.config.json and fix the code until npm run lint reports 0 errors.
  3. Add unit tests for every module in app/tests (at least two each).
  4. Write docs/review-checklist.md and .github/pull_request_template.md.
  5. Review PR 41 in reviews/pr-41.md, with findings, a praise and a decision.
  6. Run npm run test:standards.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you set up standards and reviews that keep a codebase safe without slowing the team down?

Show a good answer

A good answer mentions: few rules that prevent real harm, each with a reason from evidence, an example and how it's checked, versioned and dated; style settled by a formatter; automated checks in the build, kept in step with the document, switched on gradually in old code; reviews for harm, knowledge and consistency, with a checklist and small pull requests, looking at harm first; feedback on the code, specific, with severity, a suggestion, praise and a decision; a pull request template; and a team-owned process for changing the standards.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. Which is the best-written standard?

Why each option is right or wrong

  • “"Write clean, professional code at all times."” (Incorrect): Too vague to follow or check.
  • “"R4: Use four spaces for indentation in every file."” (Incorrect): A formatter settles this; it isn't worth a rule.
  • “"R9: Follow whatever the senior engineer prefers."” (Incorrect): A preference isn't a standard anyone can check.
  • “"R3: Errors are handled, not hidden. Why: … Checked by: lint."” is correct.

    A specific rule with a reason and a check.

    • Plus: an example.

📖 Revise: Lesson 1: Standards worth having

Question ID sp-architect-08-q1 · Report a mistake in this question
2. A team's 40-page style guide covers brace positions but not secrets, and a key is committed. What's the lesson?

Why each option is right or wrong

  • “The guide needed more pages about brace positions” (Incorrect): Length wasn't the problem.
  • “Style guides are useless and should be removed” (Incorrect): A short guide with the right rules is useful.
  • “The engineer who committed the key should write the guide” (Incorrect): Blame doesn't produce better standards.
  • “Few rules that prevent real harm matter more than style” is correct.

    Secrets and error handling belong first; a formatter can handle braces.

    • Fix: a one-page set of rules.

📖 Revise: Lesson 1: Standards worth having

Question ID sp-architect-08-q2 · Report a mistake in this question
3. A team switches on "no empty catch" and finds 212 problems. Fixing all at once would block releases for weeks. What's sensible?

Why each option is right or wrong

  • “Switch the rule off again, since the code clearly works” (Incorrect): Hidden errors still cause harm.
  • “Block releases until every one of the 212 is fixed” (Incorrect): That stops value for weeks.
  • “Delete the catch blocks so the rule has nothing to find” (Incorrect): That changes behaviour without understanding it.
  • “Fail only new problems; fix old ones module by module” is correct.

    New harm stops now; old harm shrinks steadily.

    • Then: make the rule strict.

📖 Revise: Lesson 2: Automating standards

Question ID sp-architect-08-q3 · Report a mistake in this question
4. standards.config.json has max-params switched on, but docs/standards.md doesn't mention it. What's the problem?

Why each option is right or wrong

  • “None, as the checker is the real standard and the document is optional” (Incorrect): People need the reason to accept the rule.
  • “The rule should be switched off until someone complains about it” (Incorrect): Switching off a useful rule isn't the fix.
  • “The document should be deleted so there's nothing to disagree” (Incorrect): The document explains why rules exist.
  • “Paper and tool disagree, so people meet a rule nobody explained” is correct.

    Every rule the tool checks belongs in the document, with its reason.

    • Kit: Project 3, test 2.

📖 Revise: Lesson 2: Automating standards

Question ID sp-architect-08-q4 · Report a mistake in this question
5. A team approves 2,000-line pull requests with "looks good", and an invoice rounding bug slips through. What would most help?

Why each option is right or wrong

  • “Faster approvals, so changes reach customers sooner” (Incorrect): Faster rubber-stamping lets more bugs through.
  • “Two reviewers for each 2,000-line pull request” (Incorrect): Two people skimming still skim.
  • “Reviewing only the tests, not the code that changed” (Incorrect): The bug was in the code.
  • “Small, focused pull requests reviewed with a checklist” is correct.

    Reviewers can read small changes carefully, and the checklist points to what matters.

    • First: money, data, security.

📖 Revise: Lesson 3: Code review

Question ID sp-architect-08-q5 · Report a mistake in this question
6. In PR 41, which finding should a reviewer look for first?

Why each option is right or wrong

  • “That console.log is used instead of the team's logger” (Incorrect): A real point, but minor.
  • “That the file name could be a little more descriptive” (Incorrect): A small preference.
  • “That the comment at the top could be one line shorter” (Incorrect): A nit at most.
  • “That a token is written in the code on line 5” is correct.

    Security and money come first.

    • Then: the missing await and the hidden failure.

📖 Revise: Lesson 3: Code review

Question ID sp-architect-08-q6 · Report a mistake in this question
7. Which review comment is best for line 10 of refunds.js, where the refund isn't awaited?

Why each option is right or wrong

  • “"Obviously wrong. You just forgot the await again."” (Incorrect): It talks down to the person and doesn't explain.
  • “"Wrong." with no further detail” (Incorrect): The author can't tell what or why.
  • “"I would have written this whole file differently."” (Incorrect): That's about the reviewer's taste, not this problem.
  • “"Blocker: not awaited, so failures go unseen. Add await."” is correct.

    Specific, explains why, and suggests a fix.

    • Tone: about the code.

📖 Revise: Lesson 4: Feedback that helps

Question ID sp-architect-08-q7 · Report a mistake in this question
8. A review has four blockers, two minor points and one praise. What should the decision be?

Why each option is right or wrong

  • “Approve, as the praise shows the change is mostly good” (Incorrect): Blockers must change before merging.
  • “Comment, leaving the author to decide whether to merge” (Incorrect): With blockers, the decision should be clear.
  • “No decision, as the comments speak for themselves” (Incorrect): Authors need a clear decision.
  • “Request changes, as the blockers must be fixed first” is correct.

    The decision tells the author what has to happen next.

    • Offer: to pair on the fixes.

📖 Revise: Lesson 4: Feedback that helps

Question ID sp-architect-08-q8 · Report a mistake in this question
9. A tech lead writes standards alone over a weekend, and teams quietly switch rules off. What would have worked better?

Why each option is right or wrong

  • “Stricter rules that can't be switched off by anyone” (Incorrect): People work around rules they don't accept.
  • “Waiting another year before introducing any standards” (Incorrect): The harm continues meanwhile.
  • “Announcing the standards again more loudly on Monday” (Incorrect): Volume isn't ownership.
  • “Drafting with each team, plus a way to change rules” is correct.

    Rules people helped shape are rules they follow.

    • Plus: versions and a review date.

📖 Revise: Lesson 5: Templates, ownership and changing the standards

Question ID sp-architect-08-q9 · Report a mistake in this question
10. What does a pull request template most help with?

Why each option is right or wrong

  • “Making every pull request look the same on screen” (Incorrect): Looks aren't the point.
  • “Replacing the need for anyone to review the code” (Incorrect): It helps review; it doesn't replace it.
  • “Slowing authors down so they make fewer changes” (Incorrect): It should speed review, not slow work.
  • “Getting summary, tests and rollback up front” is correct.

    Reviewers start with the answers to their first questions.

    • Kit: Project 3, test 10.

📖 Revise: Lesson 5: Templates, ownership and changing the standards

Question ID sp-architect-08-q10 · Report a mistake in this question

ProLearners Assist