Модуль 40

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

Ось готовий урок, створений спеціально для тебе в стилі CS50. Уяви, що ми зараз в аудиторії Sanders Theatre, ти сидиш у першому ряду, а я ходжу сценою і розповідаю тобі це особисто.

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

(Або: Як перетворити хаос у коді на інженерний шедевр)

1. 🔥 Вступ: Від пісочниці до хмарочоса

Уяви, що ти хочеш збудувати собачу будку. Тобі потрібні дошки, цвяхи, молоток і, можливо, година часу. Чи потрібне тобі креслення? Навряд чи. Ти просто береш і збиваєш дошки. Якщо помилився — відірвав і прибив наново.

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

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

  • Риторичне питання: Тобі коли-небудь доводилося відкривати свій код місячної давності й думати: "Хто це написав і що тут, в біса, відбувається?"?
  • Або виправляти одну помилку в коді, щоб одразу ж створити три нові в іншому місці?

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

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

Коли професіонали кажуть про Best Practices (найкращі практики), вони мають на увазі три головні речі. Давай зазирнемо "під капот".

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

Це принцип "розділяй і володарюй". Замість одного гігантського файлу main.py на 2000 рядків, ми розбиваємо код на логічні частини. * Аналогія: Уявіть професійну кухню ресторану. Чи стоїть кухар, який смажить м'ясо, в тій самій точці, де миють посуд і приймають замовлення? Ні. Є "гарячий цех", є "мийка", є "зал". * Як це працює: Один файл відповідає за базу даних. Інший — за малювання графіки. Третій — за логіку гри. Якщо ламається база даних, ти йдеш у файл бази даних, а не перериваєш весь код.

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

Це твоя "машина часу". * Інтуїтивно: Це як точки збереження (save slots) у відеогрі перед складним босом. * Під капотом: Git зберігає не просто копії файлів, а лише зміни (що додалося, що видалилося). Це дозволяє тобі експериментувати без страху все зламати. Якщо щось пішло не так — git reset, і ти в безпеці.

В. Читабельність та DRY (Don't Repeat Yourself)

Код читають частіше, ніж пишуть. * Принцип: Якщо ти скопіював і вставив шматок коду більше двох разів — ти робиш щось неправильно. Винеси це у функцію! * Стиль: Змінна x — це погано. Змінна days_until_deadline — це чудово. Код має читатися як англійська проза.

3. 🧪 Приклади: Від спагеті до лазаньї

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

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

Уяви, що ми робимо телеграм-бота для погоди.

# main.py (все в купу)
import requests
token = "12345:ABCDE..." # Пароль прямо в коді! Жах!

while True:
    msg = get_message()
    if msg == "/start":
        print("Привіт!")
    elif msg == "/weather":
        # Тут 50 рядків коду для запиту до API погоди
        response = requests.get("...")
        data = response.json()
        temp = data["main"]["temp"]
        if temp > 20:
            print("Тепло")
        else:
            print("Холодно")
    # ... ще 1000 рядків коду

Питання до тебе: Що станеться, якщо я захочу змінити сервіс погоди? Мені доведеться шукати потрібні рядки серед тисяч інших. А якщо я випадково видалю кому в token, зламається весь бот.

Приклад 2: Структурований проєкт (Best Practice)

Тепер подивись на це. Це виглядає як папка проєкту профі.

my_weather_bot/
│
├── main.py            # Тільки запуск бота
├── requirements.txt   # Список бібліотек (щоб друг міг запустити проєкт)
├── .gitignore         # Список того, що Git має ігнорувати (паролі!)
├── .env               # Тут сховані секретні токени
│
├── core/              # Папка з логікою
│   ├── weather_api.py # Функції ТІЛЬКИ для погоди
│   └── messages.py    # Тексти повідомлень
│
└── tests/             # Тести, щоб перевіряти код

Чому це краще? 1. У main.py буде лише 10 рядків: "Ініціалізувати бота -> Запустити". 2. Якщо я хочу змінити логіку погоди, я йду в weather_api.py. Я навіть не чіпаю інші файли. 3. Паролі сховані в .env і не потраплять в інтернет.

Це вже не хаос. Це архітектура.

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

Час закачати рукави. Ось твої завдання, щоб відчути різницю.

Завдання 1: "Рефакторинг" (Прибирання) У тебе є шматок коду, який повторюється 3 рази (наприклад, обчислення податку для трьох різних товарів). * Задача: Створи одну універсальну функцію calculate_tax(price, rate) і заміни ті 3 шматки на виклик цієї функції.

Завдання 2: Скелет проєкту Створи на комп'ютері папку Final_Project. Всередині створи таку структуру: * Файл main.py (порожній) * Файл README.md (текстовий опис) * Файл .gitignore * Папку src (source code)

Завдання 3: Git Ignore Відкрий файл .gitignore. Напиши туди:

.env
__pycache__/
*.DS_Store
  • Питання: Чому ми ховаємо .env? (Бо там будуть твої ключі API, і якщо ти заллєш це на GitHub, хакери вкрадуть їх за 2 секунди. Без жартів).

Завдання 4: README.md — обличчя проєкту Напиши в README.md всього три речі (використовуючи Markdown): 1. Назва проєкту (Заголовок). 2. Опис: Що цей проєкт робить (1 речення). 3. Як запустити: python main.py. * Чому це важливо: Ніхто не буде розбиратися у твоєму коді, якщо не зрозуміє за 10 секунд, навіщо він потрібен.

Міні-кейс (Challenge): Твій бот раптом почав падати з помилкою, бо сайт погоди змінив формат відповіді. * Де ти будеш шукати проблему в структурі з Прикладу 2? * Як Git допоможе тобі, якщо ти спробував виправити, але зробив ще гірше?

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

Як думає новачок, а як досвідчений інженер (Senior)?

  • Новачок: "Я напишу весь код одразу, а потім спробую його запустити".
    • Результат: 500 помилок, паніка, бажання кинути все.
  • Senior (Ти зараз): "Я напишу MVP (Minimum Viable Product)".
    • Стратегія: Спочатку зроби, щоб програма просто казала "Привіт". Перевір. Працює? Ок. Тепер додай кнопку. Перевір. Тепер додай базу даних.
    • Ми будуємо не весь хмарочос одразу, ми кладемо по одній цеглині.

Типова помилка: Перфекціонізм. Студенти часто витрачають тиждень на вибір кольору кнопок, але забувають про головну функцію. Порада CS50: "Better done than perfect". Спочатку змусь це працювати ("make it work"), потім зроби це красивим ("make it right"), і тільки в кінці — зроби це швидким ("make it fast").

6. 🧩 Підсумок

Отже, що ми сьогодні зрозуміли? 1. Структура — це все. Не пиши код в одному файлі. Розкладай по поличках. 2. Git — твій найкращий друг. Коміть зміни часто. 3. Читабельність. Пиши так, щоб твій код зрозуміла навіть твоя бабуся (ну, майже).

Тепер ти вмієш не просто кодити, ти вмієш проектувати. Ти готовий до створення свого Фінального Проєкту. Це буде складно, це буде іноді бісити, але коли ти запустиш його і він запрацює... це відчуття магії, яке варте всього.

Наступного разу: Ми поговоримо про те, як витягнути твій код з твого ноутбука і показати його всьому світу. Ми поговоримо про Деплоймент.

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

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