Phase 7: Capstone · ~45 minutes · Python · uv
Design Your Tool
The keyboard is the last step, not the first. A written design you can critique before writing a line of code is cheaper to fix than a program you're already halfway through.
Hiring signal: Designs before coding: names the pieces, their responsibilities, and how they'll be verified, in writing, before touching a keyboard
What you will learn
- Choose a real, scoped project and break it into functions and/or classes before writing implementation code
- Write a design that names each piece's single responsibility
- Write a test plan alongside the design, not after the code exists
- Apply every idea from this course (variables through testing) to one real, self-directed project
Introduction
Type: Project Languages: Python Prerequisites: Phases 00-06 (all of Programming & CS Foundations) Time: ~45 minutes
Objective
Learning objectives
- Choose a real, scoped project and break it into functions and/or classes before writing implementation code
- Write a design that names each piece's single responsibility
- Write a test plan alongside the design, not after the code exists
- Apply every idea from this course — variables through testing — to one real, self-directed project
What you're building
This lesson's deliverable is the design — do not write implementation code yet. A written document (design.md, plain text or Markdown) for your chosen project, containing:
- Functions list: every function you expect to need, its parameters, and one sentence stating its single responsibility (per the library example's style)
- Classes: at least one class, with the specific state it bundles together and why that state belongs on one object rather than scattered across separate variables
- Test plan: at least 6 named tests you expect to write in Lesson 07-02, following Phase 06's naming discipline (a name specific enough that a failure alone tells you what broke) — include at least one edge case per major function
- One paragraph on the trickiest part of this design, and how you're planning to handle it
Two proposed designs for the same expense tracker both have a function. Design A: process(data, mode) — handles adding, listing, or totaling expenses depending on the mode argument. Design B: three separate functions — add_expense, list_expenses, total_expenses. Which design will produce a cleaner test plan, and why?
This is Phase 05's readability lesson and Phase 06's testing lesson arriving at the same conclusion from different directions. process(data, mode) bundles three unrelated responsibilities behind one branching interface — testing it properly means constructing a test for every mode value, and it's easy to accidentally test only the modes you thought of, leaving others unverified. Three separate functions each get their own obviously-named test (test_add_expense, test_list_expenses, test_total_expenses), matching this course's entire testing discipline far more directly, and a bug in one is isolated to one clearly-named failure instead of hiding inside a shared, mode-branching function.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy