.gitignore
Version-controlled файл patterns для intentionally untracked files, які мають ігноруватися в певній частині working tree.
Гітігнор та як працювати з гітом та не помилитись →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Subagents
Описує current Codex subagent workflows, trigger rules, agent threads, token cost і безпечніші read-heavy patterns.
Як налаштувати мультиагентне середовище → Першоджерело ↗Cucumber Anti-patterns
Дає first-party warning про feature-coupled step definitions і duplication, центральні для критики уроку.
Чому критикують BDD і Cucumber → Першоджерело ↗Чому досвід поганого коду теж корисний
Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.
Повторити, запустити, зламати й виправити
Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.
Generator повної domain-сутності
Окремий generator може повертати не одне поле, а цілісний `User`, `Company` або `Product` з усіма значеннями, які тест перевірятиме далі. Частина полів випадкова, частина належить до обмеженого набору, частина приймається як parameter. Такий обʼєкт є очікуваною моделлю даних сценарію; окремі actions використовують його для onboarding, create або update через API чи UI.
OOP, патерни й ізоляція browser state
На базовому рівні потрібно розуміти primitives/value types, reference/object types, класи, об'єкти та принципи OOP. Із прикладних патернів найчастіше зустрічається Page Object; корисно впізнавати Singleton, Builder, Facade та інші рішення, але не впроваджувати їх без проблеми, яку вони реально спрощують. Page Factory виник навколо старих Selenium-підходів із lazy initialization елементів. Для сучасного Selenium або Playwright його не варто застосовувати за інерцією. У багатопоточному WebDriver framework кожен тест/worker повинен мати власний browser context або driver; спільний mutable driver спричиняє взаємний вплив тестів.
Старт нового репозиторію без зайвих файлів
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
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.
Доступ до нижчих рівнів визначає якість автоматизації
Навіть сильний кандидат може не мати досвіду з CI або database, якщо попередній проєкт не давав доступу. Це треба відрізняти від нездатності мислити системно. На співбесіді варто зʼясувати, чи команда дозволяє тестувати API та backend logic: десятки складних UI-тестів із patterns не компенсують відсутність покриття на рівні, де живе більшість логіки.
Формат ПМП, записи й період перевірки
[Дивитися з 13:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=810s). ПМП — відкрите часове вікно для запитань про automation, patterns, feedback, AI або власний проєкт; необов’язково бути присутнім від самого початку. Технічні й корисні soft-skill теми записуються окремими fragments, приватні розмови можуть не публікуватися. Homework review діє протягом визначеного періоду, а доступ до матеріалів лишається; об’єктивну довгу паузу варто узгоджувати завчасно.
Як вивчати ООП послідовно
Абстрактні принципи стають зрозумілішими після практики: спочатку помітити code smells, потім розібрати базові механізми ООП, далі — patterns і SOLID. KISS, DRY та YAGNI варто застосовувати паралельно як питання до конкретного коду, а не як привід будувати структуру наперед. Найкраща перевірка розуміння — пояснити, який публічний контракт має клас, який стан йому справді потрібен і яку поточну проблему вирішує кожен виділений метод.