Skip to main content

Quiz Calibration

Attempt the quiz before reading this page. Preserve the original answer, correction and help received. These explanations calibrate retrieval; successful recall alone does not complete the module or its practical evidence gates. For context such as shared schemas, use the question page.

Question 1: Pattern Justification​

A PR introduces a Strategy pattern for a single algorithm that has no planned second implementation. Is this correct?

Calibration: Ask for the pressure. With no variation, boundary or testability need, the abstraction likely adds unjustified indirection. One implementation alone is not proof of misuse: a useful boundary may justify it. Compare with a plain function and state the cost.

Question 2: Pattern Combinations​

When is it legitimate to use Strategy, Decorator, and Factory together in one feature?

Calibration: When each absorbs a distinct, current pressure: Strategy swaps the algorithm, Decorator layers orthogonal concerns (logging, caching, retry), and Factory centralizes construction when assembly varies with context. If any one of the three has no pressure behind it, drop it.

Question 3: Simple Design Rules​

What is the priority order of Kent Beck's four rules of simple design, and why does the order matter?

Calibration: (1) passes tests, (2) reveals intent, (3) no duplication, (4) fewest elements. Order matters because earlier rules win ties. In particular, intent beats minimalism -- a named helper that reveals intent should survive even if a slightly shorter inline version would also work.

Question 4: Evaluate a Review Comment​

A reviewer wrote: "This is messy." Why is this a bad comment, and rewrite it into a good one (invent plausible context)?

Calibration: It is not specific, not constructive, not evidence-based, and not labeled. Better:

[clarity, nit] The triple-nested ternary on line 57 is hard to read; an early-return guard would be clearer (see example below). Not blocking.

Question 5: Receiving Feedback​

A reviewer says "Why didn't you use the existing UserRepository?" and you did have a reason. Outline a response that is neither defensive nor reflexive agreement.

Calibration: Explain the required behavior and evidence. If a cross-tenant operation is proposed, first establish its authorization boundary; a convenience query is not permission to bypass tenant isolation. Compare a deliberately authorized administrative operation with keeping the tenant-scoped path, record the tradeoff and resolve the question from requirements rather than reviewer preference alone.

Question 6: ADR Format​

Name the four required sections of a classical ADR and the one optional section this module recommends adding.

Calibration: Context, Decision, Status, Consequences. The recommended optional section is Alternatives Considered, because it forces the author to name what was rejected and why.

Question 7: Evaluate a Design Decision​

You are asked to review an ADR whose "Alternatives Considered" section reads: "None -- this is clearly the best approach." Is this acceptable?

Calibration: No. Almost every architecturally-significant decision has alternatives. "None" usually means the author did not think hard enough, or is using the ADR as advocacy rather than documentation. Request that at least one alternative be analyzed with a reason for rejection.

Question 8: When a Diagram Is Warranted​

Give one scenario where a sequence diagram is the right choice and one where it is not.

Calibration: Right: explaining how three services interact during a checkout redemption, including failure paths. Wrong: documenting a 6-line pure function whose behavior is already obvious from its name and signature -- a diagram adds overhead and dates badly.

Question 9: Over- vs. Under-Engineering​

An internal reporting tool used by three engineers adds a ReportRendererStrategy interface with two subclasses, one of which is unused. Is this over- or under-engineered?

Calibration: Over-engineered. Context: tiny audience, short lifetime, no current variation pressure (one real subclass). The interface adds indirection for no relieved pressure. The right design is probably a single function.

Question 10: Testability without Damage​

Why is adding a setClockForTests() method on a production class a design smell?

Calibration: Because it leaks test scaffolding into production code. The fix is to inject a Clock dependency as a constructor parameter (a legitimate seam, useful even without tests), not to pierce encapsulation for tests alone.

Question 11: Reversibility​

Label each decision as one-way or two-way, and justify briefly: (a) internal helper function name (b) choice of database engine (c) public API response shape (d) which file a private class lives in

Calibration: - (a) two-way: trivial rename PR.

  • (b) costly to reverse: data migration, operational retraining, query rewrites; reversibility depends on the migration plan.
  • (c) costly to reverse: integrated clients may need coordination and a deprecation window; versioning can preserve compatibility.
  • (d) two-way: a move, unobservable externally.

Question 12: PR Shape​

What review risks arise in a 1200-line single-commit PR titled "stuff", and what context matters?

Calibration: The title hides purpose and mixed intentions can make diagnosis difficult. Size alone is not a verdict: generated files or a coherent mechanical change differ from mixed behavior changes. Split distinct intentions, summarize the risk and retain reproducible checks. A large commit reduces bisect precision; it does not make bisect universally useless.

Question 13: Evaluate a Review Workflow​

A team spends 60% of review time on naming and formatting. What concrete change would you propose?

Calibration: Move style and formatting to an automated formatter + linter in CI (and pre-commit). Freeing reviewers from whitespace/style means design, correctness, and tests get the attention instead.

Question 14: Broken Windows​

Why is tolerating a commented-out function and a perpetually skipped test in the codebase a design-level problem?

Calibration: Each tolerated defect signals to the next engineer that sloppiness is acceptable, lowering the bar for future changes. Stewardship is social: the visible quality of existing code trains new contributors.

Question 15: Narrative History​

Give two reasons commit messages matter even if "nobody reads them today."

Calibration: (1) They are read during git bisect, incident debugging, and git blame months or years later. (2) They encode why a change was made, which is the most expensive piece of information to reconstruct after the fact.

Prior Module Question 1 (from S3M4: Structural & Creational Patterns)​

What pressure does the Decorator pattern specifically relieve that subclassing cannot?

Calibration: Composition-time addition of orthogonal responsibilities. Decorator lets you stack behaviors (logging, caching, retry) at runtime without exploding a class hierarchy for every combination.

Prior Module Question 2 (from S3M3: Behavioral Patterns)​

Does adding a third branch automatically justify replacing a switch with Strategy?

Calibration: A third branch is not a threshold. Compare a clear centralized switch or table with Strategy when behavior varies independently or conditionals are duplicated. Strategy may use functions rather than classes; justify added indirection from actual change pressure.

Prior Module Question 3 (from S3M2: Refactoring Techniques)​

What is a characterization test and why must it exist before any non-trivial refactor of legacy code?

Calibration: A test that pins down the current observable behavior, correct or not. It must exist first so that the refactor does not silently change behavior while "just cleaning up."

Prior Module Question 4 (from S3M1: OOD Foundations & Code Smells)​

Name one smell that typically signals low cohesion and one that signals high coupling.

Calibration: Low cohesion: "Divergent change" -- one class edited for many unrelated reasons. High coupling: "Shotgun surgery" -- one logical change forces edits in many classes.

Prior Module Question 5 (from S2)​

Why is writing tests before a refactor typically cheaper than writing them after?

Calibration: Because the refactor changes the surface that tests are written against. Tests written first pin down the intended contract and catch regressions; tests written after may bake in the post-refactor behavior, including unnoticed regressions.