Модуль 40

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

Ось готовий урок, створений спеціально для того, щоб надихнути студента перед фінальним ривком, зберігаючи енергію та стиль курсу CS50.

🎓 Урок: Фінальний проєкт та Best Practices (Мистецтво завершувати почате)

Привіт, друзі! Це CS50 (умовно 😉), і сьогодні ми переходимо рубікон.

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

Сьогодні ми говоримо про Фінальний Проєкт. Це момент, коли ви знімаєте тренувальні колеса.

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

Уявіть ситуацію. У вас є геніальна ідея: "Я напишу застосунок, який підбирає музику під мій настрій, аналізуючи вираз мого обличчя через веб-камеру!". Звучить круто, правда?

Ви відкриваєте редактор коду. Створюєте main.py (або index.html). Курсор блимає. І... ви впадаєте в ступор. Або, що ще гірше, ви починаєте писати все підряд в один файл, і через три дні ваш код виглядає як тарілка зі спагеті, яку впустили на підлогу. Ви змінюєте одну стрічку — ламається десять інших.

Чому так стається?

  1. Масштаб задачі лякає (це не домашка на 20 рядків).
  2. Відсутність структури вбиває мотивацію.

Згадаймо кухню. Коли ви робите бутерброд, вам не потрібен план. Але якби ви готували бенкет на 200 персон у ресторані? Чи почали б ви просто "смажити все, що бачите"? Ні. Вам потрібне Mise en place (все на своїх місцях): інгредієнти нарізані, станції готові, рецепт перед очима.

Без Best Practices (найкращих практик) ваш фінальний проєкт перетвориться на хаос, який ви захочете видалити та забути. Сьогодні ми навчимося бути "шеф-кухарями" свого коду.

2. 🧠 Теоретична база: Три кити успішного проєкту

Ось три концепції, які відрізняють новачка від профі. Це не про синтаксис, це про культуру мислення.

А. MVP (Minimum Viable Product) — Мінімально життєздатний продукт

Що це: Це версія вашого проєкту, яка робить лише одну, найголовнішу річ, але робить її добре. Аналогія: Якщо ви хочете побудувати автомобіль, не починайте зі збирання коліс та шкіряного салону. Почніть зі скейтборда. Він їде? Чудово. Додайте кермо (самокат). Потім мотор (мопед). І лише в кінці — кондиціонер. Що запам'ятати: Краще працюючий калькулятор, ніж недороблена соціальна мережа.

Б. Модульність та Separation of Concerns (Розділення відповідальності)

Що це: Не пишіть весь код в одному файлі. Розбивайте його. Як працює "під капотом": Уявіть свій проєкт як офіс. * logic.py (Бекенд) — це бухгалтери в закритій кімнаті. Вони рахують цифри. * interface.py (Фронтенд) — це рецепція. Вони усміхаються і говорять з клієнтами. * Рецепція не повинна рахувати податки, а бухгалтери не повинні вітати гостей. Інтуїтивно: Якщо функція займає більше одного екрану — розбийте її.

В. Readability (Читабельність) та Документація

Що це: Код читають частіше, ніж пишуть. Суть: Називайте змінні так, щоб через місяць ви зрозуміли, що таке x. Якщо це ціна, назвіть price. Якщо це список користувачів, назвіть users_list. Коментарі: Коментар має відповідати на питання "ЧОМУ?", а не "ЩО?". * Погано: i += 1 # Збільшити i на 1 (Я і так це бачу!) * Добре: i += 1 # Переходимо до наступного студента в базі

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

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

Уявімо, ми пишемо простого бота, який вітається.

# bad_project.py
import datetime
n = input("Name: ")
h = datetime.datetime.now().hour
if h < 12:
    print(f"Good morning, {n}")
elif h < 18:
    print(f"Good day, {n}")
else:
    print(f"Good evening, {n}")
# Тут ще 500 рядків коду для іншого функціоналу...

Питання до вас: Якщо я захочу змінити мову привітання на українську, мені доведеться лізти всередину логіки. А якщо я захочу використати цю логіку на веб-сайті, а не в консолі? Цей код неможливо перевикористати.

Приклад 2: Структурований підхід (Як треба)

Ми розділимо це на "Логіку" і "Інтерфейс".

# 1. logic.py - Чиста логіка, ніяких print() чи input()
import datetime

def get_greeting(hour):
    if hour < 12:
        return "Good morning"
    elif hour < 18:
        return "Good day"
    else:
        return "Good evening"

# 2. main.py - Точка входу, робота з користувачем
from logic import get_greeting
import datetime

def main():
    name = input("Enter your name: ")
    current_hour = datetime.datetime.now().hour

    greeting = get_greeting(current_hour) # Викликаємо логіку

    print(f"{greeting}, {name}!") # Виводимо результат

if __name__ == "__main__":
    main()

Чому так краще? 1. Я можу протестувати get_greeting окремо (автотести!). 2. Якщо я захочу зробити Telegram-бота, я просто імпортую get_greeting і заміню print на bot.send_message. Логіка не зміниться!

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

Прийшов час засукати рукави. Ваш фінальний проєкт починається не з коду, а з плану.

Завдання 1: "Лікування" коду У вас є функція, яка містить "магічні числа": price = amount * 1.2. Що таке 1.2? Ніхто не знає. * Завдання: Винесіть 1.2 у константу з зрозумілою назвою (наприклад, TAX_RATE) і перепишіть рядок.

Завдання 2: README.md — обличчя проєкту Напишіть README.md файл для уявного проєкту "Калькулятор калорій". Він має містити: * Назву. * Опис (що це і для кого). * Інструкцію "Як запустити".

Завдання 3: MVP-планування Ви хочете створити сайт для пошуку загублених тварин. У вас є ідеї: мапа, чат з власниками, розпізнавання породи по фото, система винагород, інтеграція з Facebook. * Завдання: Викресліть все зайве. Залиште тільки дві функції, без яких сервіс втрачає сенс. Це і буде ваш MVP.

Завдання 4: Міні-кейс "А що, якщо..." Уявіть, що ви пишете гру. Ви зберігаєте рахунок гравця у змінній score. * Питання: А що, якщо гравець закриє гру і відкриє її завтра? Рахунок зникне. * Рішення: Як ви це виправите? (Підказка: файли, бази даних). Опишіть логіку словами.

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

Як думає профі, коли починає фінальний проєкт?

  1. "Я не знаю, як це зробити... поки що." Новачок панікує. Досвідчений розробник знає: гуглити — це частина роботи. Не знати бібліотеку — нормально. Головне — вміти читати документацію.

  2. Make it work, make it right, make it fast. (Зроби щоб працювало, зроби це правильно, зроби це швидко).

    • Помилка: Намагатися одразу написати ідеальний, оптимізований код.
    • Правильно: Спочатку брудний прототип, який працює. Потім рефакторинг (покращення стилю). І лише якщо треба — оптимізація швидкості.

  3. Git is your safety net. Робіть коміти (збереження версій) часто.

    • "Додав кнопку" — коміт.
    • "Виправив баг" — коміт. Якщо ви зламаєте все о 3-й ночі, Git дозволить повернутися у час, коли все працювало, однією командою.

6. 🧩 Підсумок

Отже, друзі, ми на фінішній прямій.

Що ви тепер знаєте? * MVP: Не намагайтеся з'їсти слона цілком, їжте частинами. * Структура: Розділяйте логіку та інтерфейс. * Чистота: Пишіть код для людей, а не тільки для машин.

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

Не бійтеся помилок. Синтаксична помилка — це не провал, це просто запит комп'ютера на уточнення.

Успіхів з кодом! Побачимось на презентації проєктів! 🚀

(Наступний крок: Якщо хочете, я можу допомогти вам розробити чек-лист для перевірки вашого конкретного фінального проєкту або показати, як оформити його на GitHub)

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