Semester 3 Project: Refactor, Patterns, and Design Review
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Runnable project implementation and repository structure | Portfolio candidate | Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout. |
| README with setup, inspection, verification instructions, and known limitations | Portfolio candidate | Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder. |
| Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief | Checkpoint evidence | Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful. |
| ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups | Portfolio candidate | These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence. |
| Final reflection, retrospective, or carry-forward notes | Checkpoint evidence | Keep candid self-assessment private unless rewritten as a concise public learning note. |
The semester project should prove that you can reshape a real codebase, not just solve isolated exercises. Build one project with three connected strands:
- refactor an existing codebase in safe steps
- introduce patterns only where design pressure justifies them
- document and review the design as if another engineer must maintain it next
You may use a personal project, a small internal codebase, or a contained learning repo. Do not choose a toy so small that no design pressure exists.
Project Outcome
By the end of the project, you should have:
- a clearer design than the starting point
- evidence that behavior stayed safe during refactoring
- at least two justified pattern applications
- a reviewable commit history
- one ADR or design note that records a real decision
The project is successful only if another engineer could inspect the repository history and understand why the design changed.
Required Scope
Your project must include all of the following:
1. Baseline Assessment
- choose a codebase with visible design problems
- write a short starting diagnosis: smells present, likely change pressure, and risks of changing it carelessly
- list what behavior must not change
2. Refactor Track
- create tests or characterization checks before risky edits
- perform at least three meaningful refactor steps across separate commits
- record the purpose of each refactor step in commit messages or project notes
Examples:
- extract a responsibility from a large class
- replace duplicated conditional logic
- improve naming and abstraction boundaries
- remove primitive obsession with a value object
3. Pattern Track
Use at least two patterns from this semester, such as:
- Strategy
- Observer
- Command
- Factory
- Adapter
- Decorator
For each pattern, include a short note:
- what pressure existed before the pattern
- why a simpler approach was insufficient or becoming costly
- what downside the pattern introduces
4. Review and Documentation Track
- write at least one ADR or short design memo
- review your own project as if it were a pull request
- use the Module 5 review lenses: correctness, clarity, design, and tests
Suggested Project Shapes
Choose one if you do not already have a suitable codebase:
- plugin-based CLI tool with multiple commands or output strategies
- notification or messaging service with multiple delivery channels
- reporting or export tool with several formatting or delivery modes
- small workflow engine where actions are queued, composed, or triggered by events
Pick something with enough variation to justify patterns, but small enough to finish in one semester.
Deliverables
- repository or project folder
- short baseline diagnosis
- smell log tied to the chosen codebase
- tests or characterization checks
- at least three refactor commits with clear intent
- at least two justified pattern applications
- one ADR or design memo
- one review memo covering correctness, clarity, design, and tests
- short final summary: what improved, what remains messy, and what you deliberately did not abstract
Rubric
| Criterion | Weight | What strong work looks like |
|---|---|---|
| Refactor safety | 25% | Changes are incremental, behavior is protected, risk is managed deliberately |
| Design judgment | 25% | Patterns respond to real pressure and avoid speculative architecture |
| Code quality | 20% | Naming, boundaries, cohesion, and coupling improved in visible ways |
| Reviewability | 15% | Commits and notes make the design story easy to follow |
| Documentation | 15% | ADR/design memo explains tradeoffs and consequences clearly |
Common Failure Modes
Avoid these:
- rewriting everything at once
- adding interfaces and factories before a second use case exists
- claiming a pattern was used without naming the pressure it solved
- writing tests only after the risky refactor is complete
- shipping one giant commit that hides the learning
- polishing code style while leaving core design pressure untouched
Submission Standard
You have completed the project when:
- the code is better structured than it was at the start
- the improvement is visible in both code and history
- the patterns are justified, not decorative
- the ADR or design memo captures a real decision
- your review memo shows the same rigor you would expect from a teammate
Added Project Requirements
Your final project must now include an OOAD case extension.
Choose one:
- meeting scheduler: availability, invitations, rooms, reminders, and conflict handling
- restaurant-management slice: reservations, tables, orders, menu items, payments, and status changes
Required evidence:
- tests covering at least three business rules and one invalid state transition
- a commit history showing the model evolve in small steps
- one refactor that improves information hiding or reduces coupling
- one ADR explaining a pattern choice and one pattern you rejected
- one review note that names risks, alternatives, consequences, and follow-up work
Production-Style Project Brief
Use this project as a reviewable engineering brief, not only a completion exercise.
Problem statement
Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.
Required evidence
- working artifact or reproducible deliverable
- README with setup, inspection, and verification instructions
- tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
- decision log with at least three meaningful tradeoffs
- known limitations section with explicit scope cuts
Review questions
- What is the smallest vertical slice that proves the project works?
- Which requirement is most likely to be misunderstood by a reviewer?
- What did you deliberately not build, and why?
- What evidence would convince someone else that the result is correct?
Done means
The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.
Weekly Project Milestones
Use these milestones to keep the project from becoming a last-week scramble.
| Milestone | Focus | Evidence |
|---|---|---|
| Start | Scope the smallest useful slice | problem statement, non-goals, first task list |
| Early build | Produce a walking version | runnable skeleton, first test, first committed artifact |
| Middle | Add the hard part | implementation note, trace/proof/benchmark/design decision |
| Review | Stress the weak point | failure case, debugging note, peer/self review, correction commit |
| Finish | Package for inspection | README, verification instructions, known limitations, reflection |
Answer-Quality Examples
| Quality | What it sounds like |
|---|---|
| Weak | "I built it because the module asked for it." |
| Acceptable | "It works for the required examples and I can explain the main idea." |
| Strong | "Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail." |
| Portfolio-ready | "A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals." |
Future Capstone Connection
Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: