Модуль 40

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

Ось готовий урок, створений за твоїм майстер-промптом.

🎓 Урок: Фінальний проєкт та Best Practices

Привіт, світе! 👋 Радий бачити вас знову.

Сьогодні ми підійшли до найважливішого етапу вашого навчання. Ви вже знаєте змінні, цикли, функції, бази даних, можливо, навіть трохи фронтенду. Але знати, як працює цегла, і вміти збудувати будинок — це різні речі.

Тема сьогоднішнього уроку — Ваш Фінальний Проєкт. І не просто "як щось написати, щоб воно працювало", а як це зробити професійно. Як писати код, за який вам не буде соромно перед майбутнім роботодавцем (і перед самим собою через два тижні).

Поїхали! 🚀

1. 🔥 Вступ: Хаос на кухні

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

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

У програмуванні так само. Коли ви пишете маленьку лабораторну роботу на 50 рядків — ви можете називати змінні a, b, temp, і писати все в одному файлі. Але Фінальний Проєкт — це ваш ресторан.

Риторичне питання: Ви коли-небудь відкривали свій старий код і думали: "Хто це написав? Я нічого не розумію!"?

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

Best practices (найкращі практики) — це правила гігієни вашого коду.

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

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

1. Модульність (Розділяй і володарюй)

Пам'ятаєте, як ми розбивали складні задачі на менші? * Інтуїтивно: Не кладіть виделки, шкарпетки та книги в одну шухляду. * Під капотом: Один файл — одна відповідальність. * logic.py — тут обчислення. * database.py — тут робота з даними. * ui.js — тут інтерфейс. Якщо файл має більше 300-400 рядків коду — це сигнал тривоги! 🚨

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

Це ваша "машина часу". * Що треба запам'ятати: Ніколи не називайте папки project_final, project_final_v2, project_really_final. * Логіка: Git дозволяє зберігати "знімки" (commits) вашого проєкту. Зламали все? Просто відкотіться назад.

3. Readability (Читабельність)

Код пишеться для людей, а не для машин. Машині байдуже, чи є відступи й коментарі. Людині — ні. * Best Practice: Називайте змінні так, щоб їх зрозуміла ваша бабуся. Замість t = 3600 пишіть seconds_in_hour = 3600.

3. 🧪 Приклади (від простого до реального)

Приклад 1: Жах новачка 😱

Подивіться на цей шматок Python-коду. Питання до вас: Що робить цей код? Скільки часу вам знадобилося, щоб зрозуміти?

def c(x, y):
    z = x * y
    if z > 100:
        return True
    return False

Відповідь: Він множить два числа і перевіряє, чи результат більший за 100. Але назва функції c нічого нам не каже.

Приклад 2: Рефакторинг (Як треба) ✅

А тепер той самий код, але з використанням Best Practices.

def is_area_too_large(width, length):
    """
    Перевіряє, чи площа перевищує допустимий ліміт (100 кв. од).
    """
    MAX_AREA = 100
    area = width * length
    return area > MAX_AREA

Чому це краще? 1. Назва функції is_area_too_large — це дієслово + іменник. Ми одразу розуміємо, що вона повертає (Так/Ні). 2. MAX_AREA — це "магічне число", винесене в константу. Якщо ліміт зміниться на 150, ми поміняємо його в одному місці. 3. Є Docstring (коментар), що пояснює суть.

Приклад 3: Структура папок (Реальний проєкт) 📂

Питання: Якщо ви робите веб-сайт (наприклад, на Flask або Django), куди покласти картинки, а куди HTML-файли?

Погана структура:

my_project/
  app.py
  logo.png
  index.html
  style.css
  db.sqlite3
  utils.py

Чому погано: Все в купі. Важко знайти потрібне.

Гарна структура:

my_project/
  ├── static/          # Все, що не змінюється (CSS, картинки, JS)
  │   ├── css/
  │   └── images/
  ├── templates/       # HTML файли
  ├── src/             # Основний код (Python/JS)
  │   ├── app.py
  │   └── helpers.py
  ├── README.md        # Інструкція до проєкту
  └── requirements.txt # Список бібліотек

Чому добре: Ви знаєте, де шукати картинки (static/images), а де логіку (src). Це стандарт індустрії.

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

Час закачати рукави! Виконайте ці завдання, щоб закріпити матеріал.

  1. 🔹 Виправити імена: У вас є змінна d = 86400. Перейменуйте її так, щоб було зрозуміло, що це кількість секунд у добі.
  2. 🔹 Структурування: Створіть на своєму комп'ютері папку Final_Project. Всередині створіть правильну структуру папок (як у прикладі вище) для вашої ідеї (магазин, блог, гра). Створіть пустий файл README.md.
  3. 🔹 README Challenge: Відкрийте README.md і напишіть для свого майбутнього проєкту:
    • Заголовок проєкту.
    • Одне речення: "Що це таке?"
    • Одне речення: "Як це запустити?" (Уявіть, що ви пояснюєте це незнайомцю).
  4. 🔹 Пошук "хардкоду": Знайдіть помилку в цьому шляху до файлу: file = open("C:/Users/David/Desktop/project/data.txt") Питання: Чи спрацює цей код на моєму комп'ютері? Як це виправити? (Підказка: відносні шляхи).
  5. 🔹 Міні-кейс: Ви хочете додати нову фічу в проєкт, але боїтеся зламати те, що вже працює. Яка послідовність дій у Git? (Правильна відповідь: git branch feature-name -> код -> git commit -> git merge).

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

Ось секрет, який знають сеньйори: Найкращий код — це код, який не довелося писати.

Типові помилки новачків:

  • "Scope Creep" (Розповзання меж): Ви хочете зробити клон Instagram, а потім вирішуєте додати туди ще й Uber, і ще й погоду.
    • Як думає профі: MVP (Minimum Viable Product). Зробіть спочатку одну функцію, але ідеально.
  • "Я запам'ятаю, що робить ця функція": Ні, не запам'ятаєте.
    • Як думає профі: Я пишу коментарі не для себе, а для "мене майбутнього", який буде втомлений і злий.
  • Винахід колеса: Писати своє сортування або шифрування.
    • Як думає профі: Чи є готова бібліотека для цього?

Порада Девіда: Почніть з кінця. Спочатку напишіть README.md (опис того, що має вийти), а потім пишіть код, щоб виконати цю обіцянку.

6. 🧩 Підсумок

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

  1. Фінальний проєкт — це не просто код, це архітектура.
  2. Чистота коду важливіша за хитрі алгоритми.
  3. Git — ваш найкращий друг і страховка.
  4. Ви тепер вмієте організовувати файли так, як це роблять у Google чи Facebook.

Тепер ви готові не просто вирішувати задачки, а творити. У вас є ідея, є інструменти й є розуміння процесу.

У наступних лекціях ми поговоримо про те, як взяти ваш локальний проєкт і задеплоїти (розмістити) його в Інтернеті, щоб ви могли надіслати посилання мамі, друзям або рекрутеру.

А поки що... це був CS50! 🏛️

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