Модуль 40

Фінальний проєкт та best practices

Ось твій урок. Вдягай зручне взуття, бери каву — ми починаємо фінальний спринт! 🚀

🎓 Тема уроку: Фінальний проєкт та Best Practices

(Або: Як перетворитися з «кодера» на Інженера)

1. 🔥 Вступ: Хаос проти Структури

Уявіть, що ви вирішили приготувати бутерброд. Вам не потрібен рецепт, план чи список інгредієнтів. Ви просто йдете на кухню, берете хліб, ковбасу — і готово. Це — ваші перші лабораторні роботи.

А тепер уявіть, що вам треба організувати весільний банкет на 200 осіб. Якщо ви почнете готувати «як піде», без плану, без списку закупівель і без допомоги — що станеться? Правильно: хаос, гості голодні, кухня у вогні, а ви плачете в кутку з мішком картоплі.

Питання до вас: Чи доводилося вам відкривати свій код, написаний тиждень тому, і думати: "Хто це писав? І що ця змінна x взагалі робить?"?

Чому це важливо? Фінальний проєкт — це ваш банкет. Це момент, коли ми прибираємо «тренувальні колеса». Досі ви вирішували задачі, які придумав я. Тепер ви створюєте щось з нуля. Без Best Practices (найкращих практик) ваш проєкт перетвориться на «спагеті-код», який неможливо підтримувати, розширювати чи навіть просто читати.

Ми тут не просто щоб навчитися писати код, який працює. Ми вчимося писати код, який живе.

2. 🧠 Теоретична база (під капотом інженерії)

Давайте розберемо три кити, на яких тримається будь-який успішний проєкт.

А. MVP (Minimum Viable Product)

Це не про "зробити аби як". Це про "зробити найважливіше". * Інтуїтивно: Якщо ви робите автомобіль, MVP — це не "колесо", це "скейтборд". Ви вже можете їхати. Потім додасте кермо (самокат), потім мотор (мотоцикл), а потім кузов (авто). * Запам’ятати: Не намагайтеся побудувати Facebook за вихідні. Визначте одну головну функцію і реалізуйте її ідеально.

Б. Модульність та "Clean Code"

Комп’ютеру байдуже, як виглядає ваш код, аби синтаксис був вірним. Але код читають люди (і найчастіше ця людина — це майбутній ви). * Як це працює: Ми розбиваємо велику проблему на малі шматочки. Замість одного файлу на 1000 рядків — 5 файлів по 200, кожен з яких відповідає за своє (один — малює графіку, інший — рахує цифри). Це називається Separation of Concerns (розділення відповідальності).

В. Контроль версій (Git) та README

Це ваша машина часу і ваша інструкція. * Логіка: Git дозволяє вам "зберегтися" перед битвою з босом (складною функцією). Якщо програєте — просто завантажуєте попередній сейв. A README.md — це обличчя проєкту. Це перше, що бачить роботодавець на GitHub.

3. 🧪 Приклади: Від жаху до краси

Давайте подивимось на код.

🔴 Приклад 1: "Спагеті" (Як робити НЕ треба)

Уявіть, що ви пишете програму для обліку витрат.

# bad_project.py
a = input("Скільки? ")
b = input("На що? ")
f = open("data.txt", "a")
f.write(a + "," + b + "\n")
f.close()
print("Ок")

Питання: Що тут не так? Що буде, якщо користувач введе букви замість цифр? А якщо файл не відкриється? А що таке змінна a?

🟢 Приклад 2: Рефакторинг (Як думає інженер)

Давайте застосуємо наші принципи.

# main.py
import csv

def get_positive_float(prompt):
    while True:
        try:
            value = float(input(prompt))
            if value > 0:
                return value
        except ValueError:
            print("❌ Будь ласка, введіть число.")

def save_expense(amount, category, filename="expenses.csv"):
    """Зберігає витрати у CSV файл."""
    with open(filename, "a", newline="") as file:
        writer = csv.writer(file)
        writer.writerow([amount, category])

def main():
    print("💰 Ласкаво просимо до Трекера Витрат")
    amount = get_positive_float("Введіть суму витрат: ")
    category = input("Введіть категорію: ").strip()

    save_expense(amount, category)
    print(f"✅ Записано: {amount} грн на '{category}'")

if __name__ == "__main__":
    main()

Чому результат такий? 1. Функції: Кожна робить щось одне (get_positive_float, save_expense). 2. Обробка помилок: Програма не "падає", якщо ввести текст. 3. Читабельність: Змінні названі зрозуміло (amount замість a). 4. Коментарі: Ми пояснили, що робить функція.

🔵 Приклад 3: Структура проєкту (Level Up)

У реальному проєкті це виглядало б як папка з файлами:

MyFinanceApp/
│
├── data/               # Папка для даних
│   └── expenses.csv
├── src/                # Вихідний код
│   ├── main.py         # Запуск
│   └── utils.py        # Допоміжні функції
├── requirements.txt    # Список бібліотек
└── README.md           # Опис проєкту

Ви бачите? Це вже виглядає як професійний продукт!

4. 🛠 Практична частина

Час закачати рукави. Виконайте ці завдання:

  1. 🔹 Виправлення імен: У вас є код: x = d * 3.14. Перепишіть цей рядок так, щоб було зрозуміло, що ми рахуємо довжину кола за діаметром.
  2. 🔹 Захист від дурня: Напишіть функцію, яка просить користувача ввести вік (ціле число). Якщо він вводить "двадцять", програма має ввічливо попросити ввести цифрами, поки він це не зробить.
  3. 🔹 Міні-кейс (MVP): Уявіть, що ви хочете створити "Tinder для котиків" (соцмережа для пошуку пари домашнім улюбленцям).
    • Напишіть 3 функції, які обов'язково мають бути в MVP.
    • Напишіть 3 функції, які круті, але їх можна відкласти на версію 2.0.
  4. 🔹 А що, якщо... Ви пишете фінальний проєкт. Ви змінили 500 рядків коду, і раптом все перестало працювати. Ви не пам'ятаєте, де помилка. Який інструмент (згаданий у теорії) врятував би вас, якби ви ним користувалися щогодини?

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі?

Помилка новачка: Новачок намагається написати весь код одразу, згори донизу. Він пише 300 рядків, запускає... отримує 50 помилок і впадає у відчай.

Думка професіонала: "Я напишу маленьку функцію, яка робить ось цю дрібницю. Я перевірю її. Працює? Чудово. Тепер наступна. Я буду будувати свій хмарочос по одній цеглині".

Порада №1: "Метод гумової качечки" Якщо ви застрягли — поясніть свій код вголос (можна коту, квітці або гумовій качечці). Поки ви будете формулювати думку, ви, швидше за все, самі знайдете помилку. Це магія, але це працює.

Порада №2: "Feature Creep" (Розповзання фіч) Найбільший ворог завершення проєкту — бажання додати "ще одну маленьку функцію". Скажіть собі "СТОП". Зробіть MVP. Додасте "феєрверки" пізніше.

6. 🧩 Підсумок

Сьогодні ми не вивчали новий синтаксис. Ми вивчали культуру написання коду.

Тепер ви вмієте: 1. Планувати проєкт (MVP). 2. Писати код, який приємно читати. 3. Розумієте важливість структури.

Фінальний проєкт — це не екзамен. Це ваш шанс створити щось своє. Щось, що вирішує вашу проблему. Щось, чим ви будете пишатися.

Вперед творити! Цей курс дав вам інструменти, але майстром станете саме ви.

Наступний крок? Тільки ви, ваш IDE і ваша ідея. This was CS50.

← До списку уроків