Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Pattern Justification​

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

Answer: No. Strategy should absorb current variation pressure. With only one implementation and no credible second one, introducing Strategy is speculative generalization -- extra indirection, extra files, no pressure relieved.

Question 2: Pattern Combinations​

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

Answer: 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?

Answer: (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)?

Answer: 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.

Answer: Acknowledge the reviewer's point, give the concrete reason ("I needed a cross-tenant query; UserRepository scopes to one tenant"), offer two options (add a cross-tenant method to UserRepository, or keep the one-off query), ask for the reviewer's preference, and move the thread toward a decision.

Question 6: ADR Format​

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

Answer: 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?

Answer: 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.

Answer: 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?

Answer: 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?

Answer: 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

Answer:

  • (a) two-way: trivial rename PR.
  • (b) one-way: data migration, operational retraining, query rewrites.
  • (c) one-way: integrated customers must be coordinated; needs deprecation window.
  • (d) two-way: a move, unobservable externally.

Question 12: PR Shape​

Why is a 1200-line single-commit PR titled "stuff" a professional failure, even if the code is correct?

Answer: It shifts reviewer workload to its maximum, makes git bisect useless, hides mixed intents, and invites a shallow review that misses design issues. Correctness of the code does not make up for unreviewable shape.

Question 13: Evaluate a Review Workflow​

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

Answer: 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?

Answer: 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."

Answer: (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.

Interleaved Review Questions​

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

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

Answer: 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)​

Why is Strategy usually preferred over a long switch statement once a third branch appears?

Answer: The switch becomes a shotgun-surgery magnet -- every new branch edits the same function, raising risk to the others. Strategy isolates each algorithm in its own class, making addition open-closed and testing simpler.

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?

Answer: 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.

Answer: 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?

Answer: 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.

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready to advance. Apply the module habits to the semester project and the Semester 3 exam.

Proficient Level (75-89% correct):

  • Review only the concept pages tied to missed questions. Redo one practice kata from the area of weakness.

Developing Level (60-74% correct):

  • Rework Practice 2 (Code Review Workshop) and Practice 3 (Design Documentation Clinic) in full. These two deliver the bulk of the module's judgment skills.

Insufficient Level (<60% correct):

  • Return to the concept sequence, starting with Cluster 1 (pattern pressure) and Cluster 2 (review rubric). These are prerequisites for the remaining clusters. Do not advance.