Модуль 40

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

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

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

Привіт, світе! 👋 Радий бачити вас на фінішній прямій.

Сьогодні ми не будемо вчити новий синтаксис, нову мову чи нову базу даних. Сьогодні ми поговоримо про те, що відрізняє кодера від інженера-розробника. Ми поговоримо про Архітектуру, Чистоту та Стратегію.

1. 🔥 Вступ: Хаос проти Порядку

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

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

У програмуванні те саме.

Коли ви пишете код на 50 рядків — ви робите бутерброд. Ви можете назвати змінні a, b, c, і це працюватиме. Але Фінальний Проєкт — це ваше весілля на 200 осіб. Якщо ви почнете писати код без плану і структури, через 3 дні ви опинитеся в ситуації, яку ми називаємо "Spaghetti Code" (код-спагеті). Все заплутано, ви тягнете за одну ниточку, а падає вся тарілка.

Питання до вас: Ви коли-небудь відкривали свій код, який писали місяць тому, і витрачали 15 хвилин просто щоб зрозуміти, що там взагалі відбувається?

Якщо так — цей урок для вас. Без Best Practices (кращих практик) ваш фінальний проєкт перетвориться на монстра, якого неможливо дописати.

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

Щоб ваш проєкт не розвалився, тримайте в голові три концепції.

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

Це найважливіше. У вас є ідея: "Я хочу зробити Facebook, але краще!". Стоп. 🛑 Якщо ви почнете робити все одразу (чати, відеодзвінки, сторіз, маркетплейс), ви не закінчите ніколи.

Що таке MVP? Це версія продукту, яка має тільки одну ключову функцію, але вона працює ідеально. * MVP автомобіля — це не кузов без коліс. Це скейтборд. Він їде? Їде. * MVP Фейсбука — це можливість зареєструватися і запостити текст. Все.

Запам’ятайте: Краще ідеально працююча одна кнопка, ніж напівготовий космічний корабель, який не літає.

2. Структура та "Чистий код" (Clean Code)

Код читають частіше, ніж пишуть. Ваш код має читатися як англійська проза. * DRY (Don't Repeat Yourself): Якщо ви скопіювали шматок коду двічі — ви вже помилилися. Винесіть це у функцію. * Розділення відповідальності: Файл database.py займається базою даних. Файл app.py — запускає сервер. Файл styles.css — фарбує кнопки. Не змішуйте все в одну купу!

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

Уявіть, що ви купили нову складну пральну машину, а в коробці немає інструкції. Ви будете злитися? Так. Ваш проєкт на GitHub без файлу README.md — це та сама пральна машина без інструкції. Це обличчя вашого проєкту. Там має бути написано: Що це? Як це запустити? Які технології використані?

3. 🧪 Приклади (від жаху до краси)

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

Рівень 1: Як робити НЕ треба ❌

# main.py
def c(x, y):
    return x * y

a = 10
b = 20
print(c(a, b))
# Тут ще 500 рядків коду, який підключається до бази даних, 
# малює HTML і відправляє email. Все в одному файлі.

Що тут не так? 1. Що таке c? Що таке a? 2. Функція називається однією буквою. 3. Все в одному файлі.

Рівень 2: Рефакторинг (Виправлення) ✅

Давайте застосуємо Best Practices.

# utils.py (Окремий файл для утиліт)
def calculate_area(width, height):
    """Обчислює площу прямокутника."""
    return width * height

# main.py
from utils import calculate_area

ROOM_WIDTH = 10
ROOM_LENGTH = 20

area = calculate_area(ROOM_WIDTH, ROOM_LENGTH)
print(f"Площа кімнати: {area} кв.м.")

Чому це краще? * Змінні мають семантичні (змістовні) назви. * Логіка винесена в окремий файл. * Є коментар (docstring), що пояснює функцію.

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

Коли ви почнете фінальний проєкт, ваша папка має виглядати приблизно так:

my_final_project/
├── app.py           # Головний файл запуску
├── requirements.txt # Список бібліотек (Flask, Pandas...)
├── README.md        # Інструкція
├── .gitignore       # Що не треба тягнути в Git (паролі!)
├── static/          # Картинки, CSS, JS
│   ├── style.css
│   └── logo.png
├── templates/       # HTML файли
│   ├── index.html
│   └── layout.html
└── helpers.py       # Допоміжні функції

Бачите? У кожної речі своє місце. Як на професійній кухні.

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

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

Завдання 1: "Перекладач з поганого на хороше" 🔹

У вас є код: d = 86400. Перепишіть цей рядок так, щоб будь-який програміст зрозумів, що це кількість секунд у добі, не використовуючи коментарі. (Підказка: використовуйте UPPER_CASE для констант).

Завдання 2: "Архітектор" 🔹

Ви робите сайт "Прогноз погоди". У вас будуть: картинки хмар, Python-код для запиту до API погоди, HTML сторінки. Напишіть на листку (або в текстовому файлі) дерево папок і файлів для цього проєкту. Куди ви покладете cloud.png? Куди get_weather()?

Завдання 3: "Визначення MVP" 🔹

Ви хочете створити аналог Uber. Напишіть список з 3-х функцій, які обов'язково мають бути в MVP, і 3-х функцій, які ви викинете на першому етапі, щоб встигнути в дедлайн.

Завдання 4: "Bug Hunter" 🔹

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

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

Як думає досвідчений інженер, коли починає проєкт?

  1. Він лінивий (у хорошому сенсі). Він не пише код з нуля, якщо є бібліотека. Навіщо писати свою функцію сортування, якщо є вбудована sort()? Шукайте існуючі рішення!
  2. Він боїться втратити код. Тому він робить git commit після кожної маленької перемоги. Зробив кнопку? Коміт. Виправив баг? Коміт. Не робіть один коміт "Final version" в кінці місяця.
  3. Він знає, що помилиться. Тому він пише код так, щоб його було легко виправити (модульність).
  4. Коментарі — це "Чому", а не "Що".
    • Погано: # Збільшуємо i на 1 (Я і так це бачу).
    • Добре: # Збільшуємо лічильник, щоб уникнути нескінченного циклу при помилці мережі.

6. 🧩 Підсумок

Отже, друзі, що ми маємо?

Фінальний проєкт — це не просто тест на знання Python чи SQL. Це тест на вашу здатність керувати складністю.

  1. Починайте з MVP (скейтборд, а не Феррарі).
  2. Тримайте код чистим і структурованим (як шеф-кухар).
  3. Пишіть README, щоб іншим (і вам самим) було зрозуміло, що ви створили.

Тепер ви не просто "кодери". Ви починаєте мислити як Software Architects.

На наступному етапі ми дізнаємось, як взяти ваш локальний проєкт і випустити його в глобальну мережу Інтернет, щоб ним могла скористатися ваша бабуся або потенційний роботодавець. Готуйтеся до Deployment!

А поки що — це був CS50. Щасти вам з кодом! 💻❤️

(Як тобі цей урок? Готовий переходити до створення структури свого власного проєкту?)

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