Модуль 40

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

Ось готовий урок, створений за твоїм майстер-промптом. Це кульмінація навчання, де ми переходимо від вирішення задач до інженерії.

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

Привіт, друзі! Це CS50 (умовно 😉).

Ми пройшли довгий шлях. Ви вивчили змінні, цикли, масиви, пам’ять, структури даних, SQL і навіть трохи веб-розробки. Ви навчилися вирішувати складні головоломки.

Але сьогодні ми поговоримо про дещо інше. Сьогодні ми переходимо від вирішення задач до створення продуктів.

1. 🔥 Вступ: Проблема «Чистого аркуша»

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

А тепер уявіть, що ви відкриваєте ресторан. Чи можете ви готувати так само? Чи можете ви просто кидати продукти де завгодно, не підписувати контейнери в холодильнику і не мати меню? Ні. Через годину настане хаос, клієнти підуть, а кухня згорить.

Ось проблема: Коли ви починаєте фінальний проєкт (або будь-який реальний стартап), ви стикаєтесь із «синдромом чистого аркуша». Ви відкриваєте редактор коду, курсор блимає, і виникає паніка. * З чого почати? * Як назвати файли? * Що робити, якщо код стане занадто великим?

Чому без цього не обійтись? У реальному світі програмісти 80% часу читають код і лише 20% — пишуть. Якщо ви напишете «геніальний», але неструктурований код (спагеті-код), через два тижні навіть ви самі не зрозумієте, як він працює.

Ми тут, щоб навчитися будувати «хмарочоси», а не «карткові будиночки».

2. 🧠 Теоретична база: Анатомія проєкту

Давайте заглянемо «під капот» успішного проєкту. Це не просто один файл main.py на 2000 рядків. Це структура.

1. Модульність (Separation of Concerns)

Інтуїтивно зрозуміло: у квартирі є кухня для їжі, спальня для сну і ванна для гігієни. Ви не ставите унітаз посеред кухні, правда? У коді так само: * Логіка (Backend/Model): Де відбуваються обчислення та робота з даними. * Вигляд (Frontend/View): Те, що бачить користувач (HTML/CSS). * Управління (Controller): Те, що з’єднує перше і друге.

Запам’ятати: Ніколи не змішуйте в одній функції запит до бази даних і малювання кнопки на екрані. Розділяйте обов'язки.

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

Уявіть, що ви пишете курсову роботу. Ви зберігаєте файли: kursova_final.doc, kursova_final_v2.doc, kursova_точно_фінал.doc. Це жах. Git — це машина часу. Вона дозволяє створювати "точки збереження" (commits). Якщо ви зламали код, ви просто повертаєтесь назад. * Під капотом: Git зберігає лише різницю (delta) між змінами, а не копіює всі файли щоразу.

3. README та Документація

Це інструкція до вашого виробу. * Що це? * Як це запустити? * Які бібліотеки потрібні? Без файлу README.md ваш проєкт — це як меблі IKEA без інструкції. Зібрати можна, але зайвих деталей залишиться багато.

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

Давайте подивимось, як еволюціонує проєкт.

Приклад 1: "Студентський кошмар"

Уявіть папку з таким вмістом:

/my_project
    code.py
    data.txt
    image.png
    test.py
    temp.py
    new_code.py

Питання до вас: Якщо я захочу запустити цей проєкт на своєму комп’ютері, який файл мені відкривати? code.py чи new_code.py? Відповідь: Неможливо вгадати. Це хаос.

Приклад 2: "Best Practices" (Структура Flask/Python проєкту)

А тепер погляньте на це:

/finance_app
    /static          # Тут картинки, CSS, JS (все статичне)
        styles.css
        logo.png
    /templates       # Тут HTML файли
        index.html
        layout.html
    app.py           # Головна точка входу (запуск сервера)
    helpers.py       # Допоміжні функції (чистий код)
    requirements.txt # Список бібліотек, які треба встановити
    README.md        # Опис проєкту
    .gitignore       # Список того, що НЕ треба зберігати (паролі!)

Чому результат саме такий? 1. Будь-який розробник світу знає: якщо це веб-проєкт на Python, старт — у app.py. 2. Файл requirements.txt дозволяє однією командою встановити все необхідне (pip install -r requirements.txt). 3. Папки розділяють логіку (Python) від візуалу (Templates/Static).

Це називається конвенція (домовленість). Дотримуйтесь стандартів, і ваш код говоритиме сам за себе.

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

Час закатати рукави. Ви маєте підготувати фундамент для вашого фінального проєкту.

Завдання 1: Скелет (Scaffolding) Створіть папку для вашого проєкту. Всередині створіть структуру, яку ми розібрали вище (навіть якщо файли поки що порожні): * README.md * app.py (або main.py) * requirements.txt * Папка src або templates.

Завдання 2: Елеватор Пітч (README) Відкрийте README.md. У вас є 3 речення, щоб продати мені вашу ідею. Напишіть: 1. Назва проєкту. 2. Яку проблему він вирішує? 3. Чому це круто?

Завдання 3: Безпека (.gitignore) Створіть файл .gitignore. Додайте туди назву файлу (наприклад, .env або secrets.py), де ви будете зберігати паролі від бази даних. * Чому це важливо: Якщо ви завантажите паролі на GitHub, їх вкрадуть боти через 3 секунди. Я серйозно.

Завдання 4: Міні-кейс "Рефакторинг" У вас є такий код у app.py:

def index():
    # 50 рядків коду, що перевіряють, чи залогінений користувач
    # 20 рядків, що дістають дані з БД
    # 10 рядків, що форматують дату
    return render_template("index.html")
  • Завдання: Як це змінити згідно з Best Practices?
  • Рішення: Винести перевірку логіна та форматування дати у файл helpers.py. app.py має залишатися чистим "диригентом".

Завдання 5: А що, якщо... А що, якщо ви вирішили змінити базу даних з SQLite на PostgreSQL? Якщо ваш код модульний (функції роботи з БД відокремлені), ви зміните код лише в одному місці. Якщо ні — вам доведеться переписувати весь проєкт. Подумайте, де у вашій ідеї «вузьке місце»?

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

Як думає новачок?

"Я хочу створити клон Facebook, Uber і Instagram в одному додатку за 2 тижні!"

Як думає досвідчений сеньйор?

"Я створю MVP (Minimum Viable Product — мінімально життєздатний продукт). Спочатку зробимо так, щоб користувач міг просто зареєструватися і написати 'Привіт'. Все інше — потім."

⚠️ Типові помилки:

  1. Scope Creep (Розповзання меж): Ви починаєте додавати нові функції, не закінчивши основні. В результаті — куча недоробок і нічого не працює.
  2. Відсутність коментарів: "Я запам'ятаю, що робить ця змінна x". Спойлер: ні, не запам'ятаєте. Називайте змінні нормально (user_id, а не x).
  3. Страх помилок: Помилки — це нормально. Червоний текст у терміналі — це не вирок, це підказка. Читайте її!

Порада від Девіда:

Краще ідеально працюючий тетріс, ніж зламаний клон Google. Робіть менше, але якісніше.

6. 🧩 Підсумок

Отже, що ми маємо сьогодні?

  1. Ви зрозуміли, що структура проєкту важливіша за кількість рядків коду.
  2. Ви знаєте, що таке Git (ваша страховка) і README (обличчя проєкту).
  3. Ви навчилися мислити як інженер: розділяти, спрощувати, планувати.

Що ви тепер вмієте? Ви готові розпочати свій Final Project. Не просто написати скрипт, а створити програмне забезпечення.

Тизер: Наступного разу ми поговоримо про те, як показати ваш проєкт світові. Як перенести його з вашого ноутбука ("localhost") у хмару, щоб ним могла користуватися ваша бабуся в Австралії. Це називається Deployment.

А поки що... це був CS50. Успіхів з проєктом!

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