Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Python мануфактура · Програма курсу · 0:00–3:00

Принципи модуля й перевірка стартового стану

Модуль починається з чотирьох орієнтирів: KISS — тримати рішення простим; DRY — не дублювати знання; YAGNI — не будувати те, що ще не потрібне; DAMP — формулювати тест через описові й змістовні фрази. Вони не застосовуються механічно: спочатку потрібен робочий тест, а вже потім видно, що справді варто винести або перейменувати. Перед новою роботою запускаються вже наявні тести. Це швидка перевірка, що вчорашні зміни або залежності не зламали базовий сценарій. Версії бібліотек у `requirements.txt` радять фіксувати, щоб оновлення залежності не змінило поведінку тестів безконтрольно.

1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI →

Python мануфактура · Програма курсу · 6:00–9:00

Один домен чи готові URL

Розглядаються два підходи: зберегти базовий домен і збирати адреси через f-string або одразу зберігати готові `BASE_URL` та `BASE_APP_URL`. Другий варіант обрано як простіший для поточної потреби: немає зайвої конкатенації та прихованих правил побудови адрес. Приклад f-string — `f"https://app.{domain}"`. Він корисний, коли частини адреси справді комбінуються у багатьох конфігураціях; створювати такий механізм лише «на майбутнє» суперечило б YAGNI.

2.1. відео, енв файл →

Python мануфактура · Сесії: AMA та PMP · 12:30–16:30

Standard library, flaky tests і прості принципи дизайну

Middle має орієнтуватися у standard library та основних конструкціях мови: collections, functions, reserved words/operators, способи створення й перетворення даних. Це дає змогу використовувати вбудовані можливості замість зайвих dependencies і custom wrappers. Окремий практичний блок — діагностика flaky tests: відрізнити проблему очікування, нестабільні дані, shared state, зовнішню залежність або справжню race condition. `retry` не є виправленням першопричини. Для дизайну automation code достатньо впевнено застосовувати KISS, DRY, YAGNI та DAMP. SOLID і design patterns корисні як словник для конкретних проблем, але не як вимога створювати багатошарову архітектуру. Також потрібно вміти запускати suite у CI та читати test report.

Що має вміти та знати мідл автоматизатор →

Python мануфактура · Програма курсу · 0:00–1:23

Навіщо майструвати IDE під себе

Можливості IDE варто сприймати як частину інженерної практики, а не як набір необов’язкових трюків. Скорочення й шаблони допомагають стандартизувати повторювані дії так само, як KISS, DRY, YAGNI, патерни та SOLID стандартизують роботу з кодом. На відміну від генерації коду за допомогою ШІ, налаштована команда IDE виконує наперед визначене перетворення. Вона не вигадує API й щоразу дає той самий результат. Перш ніж додавати автоматизацію, корисно певний час писати конструкції вручну: це формує розуміння функцій, викликів, контексту й оператора `.`.

Майструємо IDE під себе →

Python мануфактура · Програма курсу · 11:50–18:40

Технічний prompt і ревізія запропонованого плану

Prompt має описувати конкретні ознаки, які треба знайти: змішані absolute/relative imports, відсутні type hints, невикористаний код, naming conventions, кеші Python. Рольова фраза на кшталт «працюй як інженер із десятьма роками досвіду» не замінює технічних критеріїв. Згенерований план обов’язково перечитується. У прикладі корисними знахідками є відсутній тип `Page`, зайві імпорти, непослідовні приватні поля та незаігнорований `__pycache__`, але частина запропонованих змін є спірною або зайвою. Спочатку важливо отримати корисний робочий тест; узгодженість структури виправляється окремим контрольованим рефакторингом.

1. Фіксаємо назви файлів, рефакторинг та оптимізація під Python, підключаємо Ruff та uv →

Python мануфактура · Програма курсу · 12:00–16:00

Константи й помірний DRY

Повторювані звернення до environment variables піднімаються у зрозумілі константи на рівні файлу: `LOGIN_URL`, `EMAIL`, `PASSWORD`. IDE Replace використовується для послідовної заміни старих виразів. Автор свідомо не додає YAML, кілька конфігураційних класів чи систему environment-профілів. Поточна потреба — один передпродакшн стенд, тому достатньо `.env`. Розширення потрібне лише тоді, коли реально з’являться різні середовища з відмінними наборами параметрів.

2.1. відео, енв файл →

Python мануфактура · Сесії: AMA та PMP · 25:36–26:20

Як вивчати ООП послідовно

Абстрактні принципи стають зрозумілішими після практики: спочатку помітити code smells, потім розібрати базові механізми ООП, далі — patterns і SOLID. KISS, DRY та YAGNI варто застосовувати паралельно як питання до конкретного коду, а не як привід будувати структуру наперед. Найкраща перевірка розуміння — пояснити, який публічний контракт має клас, який стан йому справді потрібен і яку поточну проблему вирішує кожен виділений метод.

__init__, self, page та принципи ООП →

Python мануфактура · Сесії: AMA та PMP · 33:00–39:10

Структура automation-проєкту росте ітеративно

Початкова структура може бути простою: спільний config, `web` із pages/components, `api` із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію. Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.

Неймінг та структура automation-проєкту →
Запитати в чаті про «yagni» →