← Python Coding Track

Module 12AdvancedWeeks 8–9

Code Optimization & Design Patterns

01

Learning outcomes

  • Write efficient, maintainable, professional-quality code
02

Core concepts

Code readability standards (PEP 8)Basic optimizationIntroduction to common design patterns
03

Lessons

Module goal

Shift from "does it work?" to "is it written well?" — writing efficient, readable, professional-quality code and preparing for the Advanced Capstone.

Lesson 1 of 5 · lecture

Why "it works" isn't the finish line

Step 1 of 2

Every capstone so far has been judged on one thing: does it run correctly? That's the right first bar to clear — but professional code is judged on more. Two programs can produce identical output while one is clean, readable and easy to extend, and the other is a tangle only its original author can safely touch.

Teaching point

Most professional coding work isn't writing brand-new programs — it's reading, maintaining and extending code that already exists, often written by someone else, or by yourself months earlier. Code that works but isn't readable becomes a liability the moment anyone needs to change it.

04

Guided labs

Lab — refactor an earlier capstone

  1. 1.Choose either the Contact Manager (Module 7/11) or the Weather Dashboard (Module 10 capstone)
  2. 2.Review the code against the PEP 8 conventions above and fix inconsistent naming or spacing
  3. 3.Identify at least one place where work is repeated unnecessarily and fix it — e.g. centralise repeated connection-opening into a helper function
  4. 4.Add a short comment at the top of each file describing its responsibility
# database.py
# Handles all direct database operations for the Contact Manager (the "Model" layer)
import sqlite3

def get_connection():
    return sqlite3.connect("contacts.db")

def setup_database():
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute("""
        CREATE TABLE IF NOT EXISTS contacts (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            name TEXT NOT NULL,
            phone TEXT,
            email TEXT
        )
    """)
    connection.commit()
    connection.close()

def add_contact(name, phone, email):
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute(
        "INSERT INTO contacts (name, phone, email) VALUES (?, ?, ?)",
        (name, phone, email)
    )
    connection.commit()
    connection.close()

Teaching point

get_connection() doesn't eliminate the repeated open/close pattern entirely, but it centralises the connection details — if the database filename changes, it updates in one place instead of four. An appropriately-scoped refactor for this stage.

Advanced Capstone — database-backed repair tracker app

  1. 1.Use SQLite to store repair jobs with device name, issue description, status (Pending / In Progress / Completed) and cost
  2. 2.Support full CRUD: add a job, view all jobs, update a job's status, delete a completed job
  3. 3.Follow PEP 8 naming and formatting throughout
  4. 4.Organise across multiple files following MVC separation — a database/model file and a main/controller file
  5. 5.Use a single shared connection helper rather than repeating connection code in every function
# database.py
# Handles all database operations for repair jobs (Model layer)
import sqlite3

def get_connection():
    return sqlite3.connect("repairs.db")

def setup_database():
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute("""
        CREATE TABLE IF NOT EXISTS repairs (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            device TEXT NOT NULL,
            issue TEXT NOT NULL,
            status TEXT NOT NULL,
            cost REAL
        )
    """)
    connection.commit()
    connection.close()

def add_repair(device, issue, cost):
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute(
        "INSERT INTO repairs (device, issue, status, cost) VALUES (?, ?, ?, ?)",
        (device, issue, "Pending", cost)
    )
    connection.commit()
    connection.close()

def get_all_repairs():
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute("SELECT id, device, issue, status, cost FROM repairs")
    rows = cursor.fetchall()
    connection.close()
    return rows

def update_status(repair_id, new_status):
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute(
        "UPDATE repairs SET status = ? WHERE id = ?",
        (new_status, repair_id)
    )
    connection.commit()
    connection.close()

def delete_repair(repair_id):
    connection = get_connection()
    cursor = connection.cursor()
    cursor.execute("DELETE FROM repairs WHERE id = ?", (repair_id,))
    connection.commit()
    connection.close()


# main.py
# Handles user interaction and program flow (Controller/View layer)
from database import setup_database, add_repair, get_all_repairs, update_status, delete_repair

setup_database()

while True:
    print("\n1. Add repair  2. View repairs  3. Update status  4. Delete repair  5. Exit")
    choice = input("Choose an option: ")

    if choice == "1":
        device = input("Device: ")
        issue = input("Issue: ")
        cost = float(input("Estimated cost: "))
        add_repair(device, issue, cost)

    elif choice == "2":
        for repair_id, device, issue, status, cost in get_all_repairs():
            print(f"[{repair_id}] {device} — {issue} — {status} — {cost}")

    elif choice == "3":
        repair_id = int(input("Repair ID to update: "))
        new_status = input("New status (Pending/In Progress/Completed): ")
        update_status(repair_id, new_status)

    elif choice == "4":
        repair_id = int(input("Repair ID to delete: "))
        delete_repair(repair_id)

    elif choice == "5":
        break

    else:
        print("Invalid option, try again.")

Teaching point

Directly portfolio-ready and tied to Next Door Tech's own repair business use case — database logic cleanly separated from user-interaction logic across two files.

Success criteria

The refactored project runs identically from the user's perspective, but you can point to specific PEP 8 fixes and explain the efficiency improvement in your own words; the capstone tracker persists repair jobs in repairs.db, supports status updates and deletion, and cleanly separates database logic from user interaction.

05

Knowledge Check

Question 1 of 6

What is PEP 8, and is it enforced by the Python language itself?

06

What you read

  • Python style conventions
  • Identifying inefficient code
  • When/why patterns like MVC are used
07

What you understand

Key takeaways

  • Professional code is judged on clarity and maintainability, not just whether it runs
08

Hands-on lab

Lab tasks

  1. 1.Refactor an earlier capstone project for readability and efficiency
09

Knowledge check

  • Spot PEP 8 violations
  • Identify inefficient code patterns

Write your answers in your own notes before moving on — explaining a concept in your own words is the fastest way to find the gaps.

10

Advanced capstone

Inventory / Repair Tracker (DB-backed)

Build a Database-Backed Inventory/Repair Tracker App: stores structured records in SQLite, supports full CRUD operations, and follows clean code standards — directly relevant to Next Door Tech's repair business context.

11

Mark progress