Дорогие друзья! Мы поздравляем вас с приходом долгожданной весны! Пусть ваша жизнь наполнится радостью, пусть весна дарит вам вдохновение и силы. Для тех, кто решительно настроен изучать программирование, мы дарим неделю больших скидок на подписку ITVDN сроком 6 и 12 месяцев. Приятный бонус ждет тех, кто приобретает подписку на год – вы получите Проверку домашних заданий в подарок! На ITVDN вы можете изучать программирование на Javа, С#, JavaScript, Python, PHP, С++, самые современные технологии и фреймворки, тратя на это всего $8.5 в месяц. Долгосрочные подписки – это самый лучший выбор для тех, кто хочет пройти полное обучение по специальности и в итоге подтвердить свой уровень Дипломом специалиста. В пакете подписки для Вас будут доступны более 130 курсов по программированию, с которыми вы можете ознакомиться в нашем каталоге. Если Вы хотите пройти обучение по специальности Java Developer, Frontend Developer, Python Developer, PHP, Unity Game Dev, мы рекомендуем приобрести подписку на полгода. Если же Ваша цель  - стать С#/.NET или Full Stack разработчиком, Вам больше подойдет подписка на год. Вы сможете неоднократно возвращаться к пройденным курсам и сложным темам в течение года, консультироваться с тренером и формировать практические навыки, используя тренажер. Приобретая долгосрочную подписку, вы получаете еще одно важное преимущество – все новые курсы будут доступны для вас сразу после их появления на ITVDN. Обратите внимание – скидки тают! Используйте промо-коды для приобретения подписки по супeрцене: 15, 16, 17 марта 2018 года подписка на год за $102 + Проверка ДЗ в подарок (промо-код MARCH01) подписка на 6 мес за $58,5 (промо-код MARCH02) 18, 19, 20 марта 2018 года подписка на год за $110,5 + Проверка ДЗ в подарок (промо-код MARCH03) подписка на 6 мес за $63 (промо-код MARCH04) 21, 22 марта 2018 года подписка на год за $119 + Проверка ДЗ в подарок (промо-код MARCH05) подписка на 6 мес за $67,5 (промо-код MARCH06) Приобрести подписку по акционной цене

Встречайте предновогодний сюрприз от ITVDN – в течение одной недели,  с 5 по 12 декабря 2017 года, вас ждут большие скидки на подписку 6 и 12 месяцев. Вы можете изучать программирование на Javа, С#, JavaScript, Python, PHP, самые современные технологии и фреймворки, тратя на это всего $8.5 в месяц. Долгосрочные подписки – это самый лучший выбор для тех, кто хочет пройти полное обучение по специальности и в итоге подтвердить свой уровень Дипломом специалиста. В пакете подписки для Вас будут доступны более 130 курсов по программированию, с которыми вы можете ознакомиться в нашем каталоге. Если Вы хотите пройти обучение по специальности Java Developer, Frontend Developer, Unity Game Dev, Вам лучше выбрать план подписки на полгода. Если же Ваша цель  - стать С#/.NET или Full Stack разработчиком, Вам больше подойдет подписка на год. Вы сможете неоднократно возвращаться к пройденным курсам и сложным темам в течение года, консультироваться с тренером и формировать практические навыки, используя тренажер. Выбирая подписку на 6 или 12 месяцев, вы получаете еще одно важное преимущество – все новые курсы будут доступны для вас сразу после их появления на ITVDN. Используйте промо-коды для приобретения подписки по супeрцене: 5, 6, 7 декабря 2017 года - подписка на год за $102 (промо-код 2017A40) подписка на 6 мес за $54 (промо-код 2017B40) 8, 9, 10 декабря 2017 года - подписка на год за $110,5 (промо-код 2017A35) подписка на 6 мес за $58,5 (промо-код 2017B35) 11, 12 декабря 2017 года - подписка на год за $119 (промо-код 2017A30) подписка на 6 мес за $63 (промо-код 2017B30) Приобрести подписку по акционной цене

<p>FrontEnd разработка &mdash; очень популярное направление в IT, специалисты которого имеют возможность совмещать программирование с творчеством, создавая клиентскую сторону веб-приложений. Таким образом, практически всё, что вы видите и с чем можете взаимодействовать на любом веб-сайте &mdash; творение FrontEnd разработчика.</p> <p>Специализированные ресурсы по поиску работы в IT буквально пестрят вакансиями по фронтенду &mdash; компании открыты для квалифицированных специалистов и готовы хорошо платить за качественную работу. Если вам интересно направление, в котором кодинг образует мощный тандем с творческими способностями, и вы хотите сделать профессиональный старт в данной сфере, эта встреча будет для вас как нельзя кстати!</p> <p>Цель мероприятия &mdash; помочь вам разобраться с главными аспектами данной специальности, опираясь на тенденции развития IT-рынка, правильно расставить приоритеты и помочь спланировать ваше обучение и карьеру по направлению FrontEnd.</p> <p><strong>Программа встречи</strong>:</p> <ol> <li>Предварительные требования: образование, опыт, знания, возраст.</li> <li>Что популярно в 2021 году во FrontEnd разработке. Спрос и ЗП.</li> <li>Роадмап (путеводитель по специальности). Что и в какой последовательности лучше учить, за что браться в первую очередь.</li> <li>Английский язык, Scrum, Git и работа в команде.</li> <li>Чтобы найти работу, нужен опыт; чтобы получить опыт, нужно найти работу. Как быть?</li> <li>Книги и ресурсы для обучения.</li> <li>Вопросы и ответы.</li> </ol> <p><strong>Целевая аудитория</strong>: начинающие разработчики, студенты ВУЗов, а также все, кто интересуется FrontEnd направлением и хочет профессионально развиваться в нём.</p> <p><strong>Условия участия</strong>: бесплатно. Для получения приглашения на онлайн-трансляцию заполните регистрационную форму.</p>

План: 1. Різниця між синхронним та асинхронним кодом 2. Багатозадачність процеси й потоки, у чому різниця 3. Особливості багатозадачності в JavaScript 4. Асинхронні операції на практиці HTTP-запит як найпоширеніший кейс 5. Підходи до написання асинхронного коду: Promise    Async/Await Observable 6. Практичні поради Різниця між синхронним та асинхронним кодом Для початку давайте визначимо ці два терміни: Синхронний код - це код, який виконується послідовно, функція за функцією. Асинхронний код - код, який може виконуватися паралельно: наступна функція запускається, не чекаючи завершення попередньої. Щоб провести аналогію з реального життя, уявімо кухаря. Якщо кухар працює синхронно, то поки він не завершить приготування однієї страви, не переходить до наступної. Але це неефективно й призводить до втрати часу. Якщо ж кухар діє асинхронно, то поки м’ясо запікається в духовці, а на плиті закипає вода, він нарізає овочі. Тобто він один, але не стоїть без діла - виконує інші задачі, поки щось готується саме. Уявімо, що кухар - це процесор. А запікання м’яса в духовці - це завантаження файлу з мережі. Кухар може просто стояти й дивитись, як м’ясо готується. А може нарізати овочі, перевіряти, чи не з’явились нові замовлення, або скролити стрічку в соцмережі. Так само і з програмами: поки мережева карта завантажує файл, процесор не мусить чекати - він може малювати інтерфейс, оновлювати прогрес-бар чи виконувати обчислення у фоні. Але для цього потрібно правильно написати код - так, щоб він міг працювати асинхронно. Код який виконується синхронно ```js console.log("Початок"); console.log("Дія"); сonsole.log("Кінець"); ``` Результат: Початок Дія Кінець   Код який виконується асинхронно. і ``js console.log("Початок"); setTimeout(() => { // за допомогою setTimeout ми відкладаємо запуск коду на певний час   console.log("Дія через 2 секунди"); }, 2000); сonsole.log("Кінець"); ``` Результат: Початок Кінець Дія через 2 секунди Це не та багатозадачність, як у деяких інших мовах програмування. Тут не використовуються додаткові потоки, а все працює завдяки механізму подій. Але про це детальніше дал Багатозадачність: процеси й потоки, у чому різниця Багатозадачність в операційній системі - це можливість запускати та керувати кількома задачами одночасно. Наприклад, працювати в браузері, слухати музику, завантажувати файл і паралельно редагувати код у Visual Studio. На практиці процесор дуже швидко перемикається між усіма цими задачами, створюючи ілюзію одночасного виконання. Якщо процесор багатоядерний - деякі задачі справді можуть виконуватись паралельно. Багатозадачність тісно пов'язана з двома важливими поняттями - процесами та потоками. Процес (process) - це окремий екземпляр програми у пам'яті, який має власні ресурси: виділену область оперативної пам'яті, дескриптори файлів, змінні оточення тощо.  Потік (thread) - це одиниця виконання всередині процесу. Потоки одного процесу працюють незалежно, але мають спільний доступ до пам'яті та ресурсів процесу. Процеси дозволяють запускати різні програми одночасно - наприклад, Google Chrome, Visual Studio Code і т.д.  Потоки дають змогу виконувати кілька задач усередині однієї програми. Наприклад, у Visual Studio Code один потік відповідає за оновлення інтерфейсу, інший перевіряє помилки в коді, ще один формує підказки під час написання. Це, звісно, спрощений приклад - у реальності VS Code використовує ще й окремі процеси для розширень і мовних серверів. Операційна система керує як процесами, так і потоками. Вона розподіляє процесорний час між ними, ставить у чергу, може призупиняти виконання або відновлювати його за потреби. Давайте трохи адаптуємо наш приклад з кухарем із попереднього посту. Уявімо, що процес - це ресторан, а потік - це кухар. Ресторан має все необхідне для приготування їжі: кухонне приладдя, продукти, рецепти (це можна розглядати як пам’ять і доступ до інших ресурсів). Кухар читає рецепт і, використовуючи ресурси ресторану, готує страву - так само, як потік виконує інструкції нашої програми, використовуючи ресурси процесу. Якщо ресторан хоче готувати кілька страв одночасно, йому потрібно більше кухарів, які працюють паралельно на одній кухні. Аналогічно, якщо програма повинна виконувати кілька задач одночасно - завантажувати файли, обробляти введення, оновлювати інтерфейс - вона може використовувати кілька потоків. Коли ми створюємо програму і хочемо зробити її зручною для користувача, а також ефективною з точки зору використання ресурсів, які виділяє операційна система на процес, ми іноді починаємо використовувати потоки та прийоми багатопотокового програмування. Це велика окрема тема, і ми її зараз чіпати не будемо. Одна з причин - у JavaScript немає прямого доступу до потоків. Уточнення. Якщо ви хочете використовувати JavaScript і все ж таки працювати з потоками - у вас є Web Workers:  https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers  А якщо JavaScript виконується не в браузері (наприклад, у Node.js), тоді можна використовувати модуль `worker_threads`. Але варто розуміти, що це не частина стандарту мови, а можливість середовища виконання. Додаткові корисні ресурси по цій темі: https://www.youtube.com/@CoreDumpped - канал з короткими відео про те як працює комп'ютер. Modern Operating System by Andrew Tanenbaum - принцип побудови та роботи операційних систем (може бути викликом для новачка, але нормально як для технічної книжки) Особливості багатозадачності в JavaScript JavaScript працює в одному потоці - це означає, що в будь-який момент часу виконується лише один фрагмент коду. Увесь код, який ми пишемо, виконується у call stack: це структура, в яку потрапляють усі функції, що викликаються. Якщо одна з функцій виконується довго (наприклад, важке обчислення), усі інші задачі - включно з обробкою кліків, рендерингом чи відповідями від сервера - будуть чекати, поки call stack не звільниться. Щоб не блокувати цей єдиний потік, браузер надає асинхронні API (setTimeout, fetch, Web API). Коли ми викликаємо, скажімо, fetch(), у стек додається лише короткий виклик цієї функції. Власне мережевий запит виконується в окремому потоці, який створює браузер. Тобто, один потік виконує задачі які є у call stack, а інший потік чекає поки відповідь поверне сервер. Але асинхронна операція колись завершиться і треба механізм який віддасть нашому головному потоку результат роботи іншого потоку. Коли це стається колбек або проміс‑резолвер не додається одразу у call stack. Спершу він потрапляє до черги подій (task queue). За роботою черги стежить event loop. Його правило просте - поки стек порожній дістати першу задачу із черги і покласти у стек. Так ми досягаємо псевдобагатозадачності: основний потік виконує короткі шматки коду послідовно, а довгі операції «живуть» поза стеком. Коли довгі операції завершуються вони формують чергу задач, які треба виконати а event loop ці задачі закидає до стеку, коли call stack стає порожнім. Це максимально спрощене пояснення, і без візуалізації може здатися складним. Якщо хочете краще зрозуміти, дуже раджу подивитись відео Jake Archibald — "In The Loop" на YouTube (англійською).  https://www.youtube.com/watch?v=8aGhZQkoFbQ Або приходьте на мій курс JavaScript Поглиблений, де ми розбираємо це на практиці.  Також корисна стаття на MDN, де ці процеси описані докладніше. Асинхронні операції на практиці: HTTP-запит як найпоширеніший кейс Один з прикладів асинхронної операції - це запит на сервер через HTTP-протокол. Якщо організовувати запит через JavaScript у браузері без використання React, Angular або Vue.js, то це можна зробити за допомогою: fetch XMLHttpRequest Спеціалізована бібліотека, наприклад, Axios Ось так буде виглядати простий код написаний на fetch ```js fetch('https://jsonplaceholder.typicode.com/users')   .then(res => res.json())   .then(data => console.log(data)); ``` А так на axios (axios одразу повертає розпарсений JSON як response.data, на відміну від fetch, де потрібно викликати .json() вручну) ```js axios.get('https://jsonplaceholder.typicode.com/users')   .then(response => console.log(response.data)); ``` Якщо розглянути саме fetch то ось що відбулося під капотом: fetch створює HTTP запит вказавши HTTP метод, заголовки, тіло тощо Цей запит передається у вбудовану систему Web API - окрему від JavaScript середу, яка працює в іншому потоці. JavaScript не чекає відповіді - основний потік продовжує виконувати інший код fetch повертає Promise - об'єкт, що представляє асинхронну операцію, результат якої з’явиться пізніше Коли відповідь від сервера приходить, Web API кладе callback в чергу. Event Loop перевіряє, чи call stack порожній, і виконує цю мікрозадачу. Така поведінка дозволяє браузеру одночасно виконувати інші задачі, не чекаючи завершення запиту. Про використання асинхронного коду в JavaScript є [безкоштовний урок на YouTube](https://www.youtube.com/watch?v=cvR1EQ1R0EQ) Також більше про синтаксис Promise можна дізнатися в уроці [Асинхронний код. Promise](https://itvdn.com/ua/video/javascript-essential-ua/js-promise-ua) на ITVDN, а детальніше про варіанти організації такого коду буде написано далі. Підходи до написання асинхронного коду Складність роботи з асинхронним кодом полягає в тому, що обробка результату операції відбувається не відразу, а через певний час після її запуску. Ми ініціюємо асинхронну операцію й можемо виконувати інші завдання, але все одно маємо якось дізнатися про її завершення та обробити результат. Проблема в тому, що в цей момент програма вже виконує інші дії. Тому для обробки асинхронних операцій використовується push-модель взаємодії: отримувача даних (наш код) викликає провайдер даних - окремий механізм, який керує асинхронною операцією. По суті, розробнику потрібно відреагувати на подію завершення асинхронної операції. Для цього існує кілька підходів: callback-функція Promise async/await (синтаксичний цукор над Promise) Observables Використання функцій зворотнього виклику (callback) Почнемо з callback-функцій. Це найпростіший підхід, але він може призвести до заплутаного коду, особливо коли одна асинхронна операція запускає іншу, і так утворюється ланцюг. Уявімо, що маємо функцію downloadImage(url, callback), яка завантажує зображення асинхронно, не блокуючи основний потік. Перший параметр - це адреса зображення, яке потрібно завантажити, а другий - функція, яку буде викликано після завершення завантаження. При цьому саме зображення буде передане як параметр у callback. Приклад використання: ```js downloadImage(url1, image => document.body.append(image)) ``` На перший погляд усе просто. Але якщо потрібно завантажити кілька зображень послідовно, код стає менш зрозумілим: ```js downloadImage(url1, image => {             document.body.append(image);             downloadImage(url2, image => {                         document.body.append(image);                         downloadImage(url3, image => {                                     document.body.append(image);                         })             }) }); ``` Така вкладена структура швидко ускладнюється, особливо якщо замість одного рядка з DOM-змінами з’являється додаткова логіка. Подібний стиль називають "Pyramid of Doom", і його краще уникати. Один зі способів спростити обробку асинхронних викликів - це використання Promise. Використання Promise Promise - це об’єкт, який представляє асинхронну операцію. У перекладі з англійської promise означає «обіцянка». Можна уявити, що це обіцянка від браузера надати в майбутньому або результат операції, або помилку, пов’язану з її виконанням. Приклад використання: перепишемо попередню функцію downloadImage, щоб вона повертала Promise. ```js let promise = downloadImage(url1); promise.then(image => document.body.append(image)); ``` Тут ми все одно використовуємо callback-функцію, але передаємо її вже в метод .then() об’єкта promise. Це важливий момент: тепер асинхронна операція має об’єктне представлення, яке можна передавати як параметр у різні частини коду; можна будувати ланцюжки промісів, позбуваючись вкладеності, яка виникала з callback. Приклад: ```js downloadImage(url1)                          // отримуємо проміс .then(image => {                             // вказуємо що робити коли promise перейде в стан resolved             document.body.append(image);             return downloadImage(url2);                // виконуємо метод, який повертає promise }) .then(image => {                             // результат роботи попереднього промісу передається як значення             document.body.append(image);             return downloadImage(url3); }) .then(image => {             document.body.append(image); }); ``` Тепер код виглядає лінійним і набагато зручнішим для супроводу. У прикладах вище ми не розглядали, як саме створюється Promise, адже важливо зрозуміти мотивацію використання цих об’єктів. Тим більше, що більшість API браузера вже повертають готові проміси. Наприклад: ```js fetch('<https://jsonplaceholder.typicode.com/users>')   .then(res => res.json()); ``` Якщо хочете детальніше розібратися зі створенням Promise вручну - перегляньте документацію на MDN або мій відео урок на ITVDN. Async/await Супроводжувати синхронний код завжди простіше, ніж асинхронний. У 2012 році в мові C# з’явився синтаксичний цукор, який значно спростив роботу з асинхронними операціями: замість вкладених callback можна було використовувати послідовний синтаксис з новими ключовими словами async та await. Згодом цю концепцію перейняли й інші мови програмування, зокрема Python та JavaScript. В JavaScript підтримку async/await додали у 2017 році. Призначення ключових слів async - додається до функції та вказує, що вона завжди повертає Promise. await - використовується перед об’єктом-промісом, щоб "дочекатися" результату перед виконанням наступних рядків коду. Перепишемо попередній приклад із завантаженням зображень, використовуючи async/await: ```js let image = null;   image = await downloadImage(url1); document.body.append(image);   image = await downloadImage(url2); document.body.append(image);   image = await downloadImage(url3); document.body.append(image); ``` Тепер код виглядає як звичайний синхронний: немає вкладених callback, усе читається рядок за рядком. Можна подумати, що await "зупиняє" виконання, очікуючи на результат промісу. Насправді ж код не блокує основний потік - під капотом він перетворюється на машину станів, де кожен стан описує дію до або після await. Ще одна перевага async/await - знайомий синтаксис для обробки помилок: ```js try {             let image = null;               image = await downloadImage(url1);             document.body.append(image);               image = await downloadImage(url2);             document.body.append(image);               image = await downloadImage(url3);             document.body.append(image); } catch (ex) { // обробка помилки } ``` У результаті асинхронний код виглядає так само зрозуміло, як і синхронний, що значно спрощує його супровід. Observable Observable - це ще один підхід до організації асинхронного коду. Назва походить від однойменного патерна проєктування (Observer pattern), який описує створення об’єктів, за якими можна «спостерігати», отримуючи від них сповіщення. Тобто це реалізація подієвої моделі за допомогою ООП. У сучасному JavaScript ця ідея пішла далі й стала основою реактивного програмування та бібліотеки RxJS. Якщо Promise представляє одне майбутнє значення (успішне або помилкове), то Observable - це потік значень, які можуть з’являтися з часом. Можна уявити: Promise - це одна посилка, яку ви отримаєте в майбутньому; Observable - це підписка на журнал, нові випуски якого надходитимуть регулярно. Щоб створити Observable, використовують конструктор або готові оператори RxJS. Наприклад, функція downloadImages(urls) може завантажувати кілька картинок і відправляти їх «у потік» по мірі завантаження: ```js import { Observable } from 'rxjs';   function downloadImages(urls) {   return new Observable(subscriber => {     urls.forEach(url => {       downloadImage(url, image => {         subscriber.next(image); // надсилаємо картинку у потік       });     });     subscriber.complete(); // повідомляємо, що потік завершено   }); } ``` Щоб використати Observable, на нього треба підписатися за допомогою subscribe: ```js downloadImages([url1, url2, url3])   .subscribe({     next: image => document.body.append(image), // що робити з новим значенням     error: err => console.error(err),           // обробка помилок   }); ``` Переваги Observable працюють із потоком даних, а не з одним результатом; підтримують підключення операторів трансформації (фільтрація, мапінг, комбінування потоків); можна легко скасувати виконання (відписатися від потоку). Нижче приклад обробки даних через оператори. В RxJS оператори підключаються через метод pipe: ```js import { filter, map } from 'rxjs/operators'; downloadImages([url1, url2, url3])   .pipe(     filter(image => image.width > 100), // пропускаємо лише великі картинки     map(image => {       image.classList.add('highlight');       return image;     })   )   .subscribe({     next: image => document.body.append(image),     error: err => console.error(err),     complete: () => console.log('Готово')   }); ``` Таким чином, як і у випадку з Promise, можна будувати ланцюжки обробки. Але Observable значно гнучкіші: вони дозволяють працювати не лише з одним значенням, а з динамічною послідовністю даних у часі. Для глибшого занурення рекомендую офіційний гайд Observable на RxJS.dev. та відео уроки Observables. Частина 1, та Observables. Частина 2[1]  Практичні поради по работі за асинхроним кодом Не змішуйте підходи без потреби Якщо почали писати з async/await, не вставляйте всередину .then() без особливої причини. Це ускладнює читання. Обробляйте помилки Використовуйте try/catch для async/await або .catch() для Promise. У випадку Observable завжди додавайте обробку error у subscribe(). Скасовуйте непотрібні операції Для Observable використовуйте unsubscribe(), коли потік більше не потрібен. Для fetch можна застосувати AbortController, щоб зменшити навантаження й уникнути витоків пам’яті. Уникайте "Pyramid of Doom" Замість вкладених callback застосовуйте Promise, async/await або Observable. Використовуйте паралельне виконання Якщо операції незалежні, запускайте їх одночасно через Promise.all(). Ізолюйте логіку обробки Розділяйте завантаження даних та маніпуляції з DOM. Це спростить тестування й повторне використання коду. Логуйте стан і помилки Під час розробки виводьте у консоль ключові події асинхронних операцій, щоб відстежувати їх послідовність. Пам’ятайте про event loop Розуміння різниці між мікрозадачами й макрозадачами допоможе прогнозувати порядок виконання коду. Перевіряйте сумісність середовища Деякі API можуть бути відсутні у певних середовищах (наприклад, fetch у Node.js доступний лише починаючи з версії 18).

Що таке патерн (шаблон) проєктування. Коли використовують шаблони. Якими бувають патерни проєктування. Породжуючі. Структурні. Патерни поведінки. Як обрати шаблон? Висновки. Програмісти-початківці завжди приходять до точки, коли їхній код перетворюється на “спагеті”. Його важко читати, він містить масу самоповторень, зайвих функцій, а додавання нового функціоналу перетворюється на десяте коло пекла. Один із найкращих засобів запобігання цьому – використовувати патерни проєктування (Design Patterns). Чи є це срібною кулею, які переваги та недоліки патернів існують, і які з них необхідно знати розробникам? Відповіді розбираємо нижче. Що таке патерн (шаблон) проєктування? Патерни – це типові архітектурні рішення проблем, котрі часто зустрічаються під час розроблення ПЗ. Їхня інша назва – шаблони, і що цікаво – людство дуже часто оточує себе шаблонами у повсякденному житті: однакові гнізда розетки та форми вилок у приміщеннях – універсальне рішення для електроживлення; виделки та ложки – інструменти споживання майже будь-якої їжі; чашки – ємності для розміщення будь-якої рідини і так далі. Людина завжди прагне спростити традиційну діяльність, і це не могло обійти стороною програмування. Ідеї створення універсальних правил для якісної розробки існували ще до 90-х років минулого століття, але дійсно проривною стала праця "Design Patterns: Elements of Reusable Object-Oriented Software" (1994) авторства Еріха Ґамма, Річарда Гелма, Ральфа Джонсона та Джона Вліссідеса, які іменують себе як "Банда чотирьох" (Gang of Four, GoF). У книзі описано 23 патерна та їхнє застосування в об'єктно-орієнтованому дизайні. Ця праця стала фундаментальною і тепер патерни gof складають кістяк багатьох обговорень якісного коду. Коли використовують патерни В розробці шаблони використовують при необхідності приведення коду до наступних критеріїв: Читабельність – інші розробники мають без складнощів розуміти написане. Масштабованість – легкість у створенні нового функціоналу. Підтримуваність – оновлення кодової бази має проходити якомога плавніше. Також вони здатні підвищити швидкість і продуктивність розробника – патерни це дійсно дозволяють. Вони гарно справляються і з наступними задачами: зменшення кількості потенційних помилок та вузьких місць; спрощення рефакторингу; зменшення технічного боргу; покращення комунікації девелоперів з іншими програмістами, проєктними менеджерами, власниками тощо. Необхідність використати шаблони проектування зростає разом зі збільшенням кодової бази, особливо при комерційному розробленні – коли створюване ПЗ має приносити прибуток. Важливо пам’ятати, що використання патернів інколи є геть недоречним. Подекуди воно може значно ускладнити читабельність, громіздкість і масштабованість коду. Наприклад, нескладний функціонал, який нечасто використовується і займає мало місця в коді, не потребує pattern-втручання. А от репетативний код, що вирішує класичні задачі (сортування, перебір даних тощо) – ідеальний претендент на застосування шаблону. Аби не помилитися спершу з’ясуйте контекст вашої проблеми, а вже потім обирайте патерни програмування, які найкраще задовольняють вимогам. Якими бувають патерни проєктування У своїй книзі GoF виділяють три великі сімейства: Сімейство Короткий опис Породжуючі патерни або Creational Patterns Надають найкращі способи створення об'єктів. Вони абстрагуються від процесу конкретизації і роблять вашу систему незалежною від створення, компонування та представлення її об'єктів. Популярні приклади: “Абстрактна фабрика” (Abstract Factory), “Одинак” / “Одиночка” (Singleton), “Прототип” (Prototype), “Фабричний метод” (Factory Method). Структурні патерни або Structural Patterns Фокусуються на композиції об’єкту. Допомагають переконатися в тому, що зміна частини системи не потягне за собою необхідність змін в інших її складових. Популярні приклади: “Проксі” (Proxy), “Адаптер” (Adapter), “Компонувальник” (Composite), “Фасад” (Facade). Патерни поведінки або Behavioral Patterns Зона відповідальності – алгоритми та обмін інформацією між об’єктами. Популярні приклади: “Відвідувач” (Visitor), “Ітератор” (Iterator), “Ланцюжок обов’язків” (Chain of Responsibility), “Стратегія” (Strategy). Розглянемо більш детально деякі з них. Породжуючі Породжуючі патерни – це надійні помічники у створенні об’єктів таким чином, аби в майбутньому з ними було максимально легко працювати. Дамо короткий опис деяких шаблонів: Патерн Одинак / Сінглтон забезпечує наявність лише одного екземпляру класу з глобальною точкою доступу. Singleton поширений в задачах конфігурацій або логування в застосунках, де потрібен єдиний контрольований доступ. Шаблон Прототип дозволяє створювати нові об'єкти шляхом копіювання існуючих екземплярів. Використовується Prototype в ситуаціях, коли створення об'єкта надто дороге, наприклад, при клонуванні складних або ресурсоємних об'єктів. Фабричний метод визначає інтерфейс для створення об'єктів, але дозволяє підкласам самостійно визначати тип створюваних об'єктів. Fabric Method корисний у багатофункціональних застосунках, де класи повинні мати можливість вибирати тип об'єктів, наприклад, при роботі з різними форматами документів, системами онлайн платежів тощо. Абстрактна фабрика визначає інтерфейс для створення сімейств пов'язаних об'єктів без вказівки їх конкретних класів. Використовують Abstract Factory для створення різних компонентів інтерфейсу користувача, які повинні працювати разом і забезпечувати єдиний стиль (світла / темна тема вебсайту тощо). Розглянемо приклад на патерні Singleton. Уявіть собі просту програму – музичний плеєр. Він дозволяє користувачам відтворювати музичні файли. Однак водночас має працювати лише один екземпляр плеєра – можливість відкриття декількох одночасно повинна бути недоступна. Цього можна досягти за допомогою шаблону Singleton. Простий приклад коду мовою C#: public class MusicPlayer {             private static MusicPlayer _instance;             private MusicPlayer()             {              // Ініціалізуємо музичний плеєр (наприклад, завантажуємо плейлисти)             }             public static MusicPlayer Instance             {             get             {             if (_instance == null)             {                        _instance = new MusicPlayer();             }             return _instance;             }             }             public void PlaySong(string songPath)             {             // Запустити пісню             }             public void PauseSong()             {             // Поставити на паузу             }             public void StopSong()             {             // Зупинити відтворення пісні             } } // Отримуємо екземпляр MusicPlayer MusicPlayer player = MusicPlayer.Instance; // Використовуємо функціонал MusicPlayer player.PlaySong("C:\\Users\\yourUsername\\Music\\mySong.mp3"); player.PauseSong(); player.StopSong(); Щоразу як в різних ділянках проєкту вам треба буде створювати екземпляр плеєру для відповідної взаємодії, ви завжди працюватимете лише з одним і тим самим екземпляром, уникаючи дублікації. Якщо ви програмуєте мовою сі шарп, детально розібрати популярні патерни проєктування C# з прикладами ви можете за посиланням. Структурні З короткого опису в таблиці легко дійти висновку, що структурні патерни дозволяють сформувати надійну, масштабовану та підтримувану архітектуру проєкту. Коротке знайомство: Проксі забезпечує об'єкт-посередник для контролю доступу до іншого об'єкта. Зазвичай шаблон Proxy використовують для реалізації “лінивого” завантаження, коли об'єкт створюється або ініціалізується лише при зверненні до нього (наприклад, завантаження картинок з високою роздільною здатністю). Адаптер дозволяє об'єктам з несумісними інтерфейсами працювати разом. Застосовується патерн Adapter для інтеграції нових компонентів в існуючу систему без зміни її коду. Підходить для використання нової бібліотеки у старому застосунку. Компонувальник використовується для ієрархічного компонування об'єктів для подальшої роботи з ними як з єдиним об'єктом. Використовується для створення деревоподібних структур, як-от файлові системи або GUI, де кожен вузол може бути як простим, так і Composite об'єктом. Фасад (Facade) надає спрощений інтерфейс для взаємодії зі складною системою або набором класів. Він зменшує складність роботи з підсистемами і надає користувачам єдиний вхідний інтерфейс для виконання рутинних операцій. Вивчити саме структурні патерни проєктування C# (з прикладами) ви можете за посиланням. Поведінкові Патерни поведінки в першу чергу визначають зв’язки між об’єктами і те, як вони здійснюють обмін інформацією. Наприклад: Патерн Відвідувач (Visitor) дозволяє додавати нові операції до об'єктів без зміни їхніх оригінальних класів. Використовується для взаємодії з об’єктами зі складною структурою, коли внесення додаткової логіки в оригінальні класи невиправдано ускладнює код. Ітератор / Iterator надає зручний механізм послідовного та простого доступу до елементів колекції, незважаючи на складність її побудови. Даний патерн поведінки популярний при обході елементів контейнерів, як-от списки або масиви – він надає універсальний інтерфейс для різних типів колекцій. Ланцюжок обов’язків або ж патерн Chain of Responsibility дозволяє передавати запит ланцюжком обробників, поки один з них не обробить запит. Незамінний при обробці запитів на сервері, де кожен обробник може передати запит наступному обробнику в ланцюжку: перевірка при авторизації на сайті, оброблення подій у GUI тощо. Для входу в патерни проєктування книга від Gang of Four буде гарною точкою відліку. Ви познайомитеся з класикою та академічним розкриттям теми, використовуючи патерни gof. Якщо ж ви хочете збагатити свої знання шаблонів, але віддаєте перевагу мові Java, рекомендуємо відео курс “Патерни проектування Java”. Як обрати патерн? Спочатку ви маєте проаналізувати задачу – для більшої зрозумілості виконайте її декомпозицію, розбивши на декілька складових. При цьому використовуйте системний підхід: прорахуйте, як ваше рішення вплине на весь проєкт, які елементи воно зачепить зараз, і який вплив воно матиме на додавання нового коду. Якщо ви вже працюєте в ІТ-компанії, ваші колеги, тімлід або архітектор можуть підказати вам доцільність використання того чи іншого патерну, розкрити нюанси вже існуючої архітектури, кодового стилю та багато іншого. Лише після ретельного аналізу можна переходити до підбору шаблону, зважаючи на усі переваги та недоліки. До речі, в цих задачах гарними помічниками будуть безкоштовні AI-асистенти на кшталт ChatGPT, Gemini та ін. Також не забувайте про використання інших методик покращення кодової читабельності, масштабування й чистоти: SOLID принципи – вони регламентують 5 основних засад створення структурованого, якісного коду. Нещодавно ми проводили вебінар, на якому розбирали кожен принцип в деталях, запрошуємо до перегляду! А якщо вас цікавить прикладний характер SOLID принципів на Java, можете пройти даний відео курс. GRASP (General Responsibility Assignment Software Patterns) – патерни для об’єктно-орієнтованого проєктування. Вони не мають вираженої структури і носять більш абстрактний характер, аніж патерни gof. DRY (Don’t Repeat Yourself) – головна ідея даного принципу полягає у створенні коду, який не матиме дублікацій в проєкті. KISS (Keep It Simple, Stupid) – регламентує написання якомога простішого коду, аби його можна було легко читати і розуміти. Рефакторинг – повернення до вже написаного коду з метою його покращення без зміни функціональності. Інші техніки, що залежать від проєктів. Висновки Патерни грають ключову роль в сучасному розробленні. Вони акумулюють в собі найкращі практики створення кодової бази таким чином, аби досягнути максимальної легкості та ефективності розроблення, особливо на великих проєктах. Звісно, не завжди їхнє використання є доречним – потрібно аналізувати задачі і продумувати наслідки застосування того чи іншого шаблону, аби не отримати величезну валізу без ручки. Розвивайте вашу експертизу в області патернів – це win-win стратегія. З одного боку перед працедавцями ви постанете як досвідчений та висококваліфікований спеціаліст, а з іншого – ваші програмні рішення матимуть елегантний характер і відзначатимуться легкістю в читанні, підтримці та масштабуванні. Чи використовуєте ви патерни в своїй розробницькій діяльності? Можливо, тільки вивчаєте? Залишайте в коментарях ваші відповіді!

Тренди. Найвищі зарплати Junior, Middle, Senior інженерів. Найвищі зарплати керівної інженерної ланки. Зарплати інших ІТ-фахівців. Найвищі зарплати в США, Європі та решті світу. Дані для рейтингу. Levels.fyi – компанія, що базується в США – нещодавно опублікувала річний звіт за 2023 рік з переліком компаній, міст, тайтлів та різних трендів, які мають найбільші грошові винагороди. Відповідно до інформації на сайті компанії, аналітичні матеріали Levels.fyi дозволяють людям будувати кращі кар’єри в ІТ, відштовхуючись від чесних та прозорих зарплат. Давайте разом подивимось, які ІТ-спеціалісти в яких куточках світу отримують найбільше?   Тренди Спочатку дізнаємось, як змінилися зарплати ІТ-спеціалістів порівняно з 2022 роком. На картинці нижче – медіанні ЗП в доларах США (сумарно за рік) для кожного сімейства спеціальностей. Найвідчутніший приріст мають технічні менеджерські напрямки, повний штиль у Data Scientists, а невеликий від’ємний приріст – у розробників програмного забезпечення та дизайнерів продукту.   Найвищі зарплати Junior, Middle, Senior інженерів Розглянемо річні компенсаційні медіани інженерів, які мають досвід від 0 до 15+ років в розробці. В кожному розділі буде ТОП-7 компаній, які найбільш щедро винагороджують своїх працівників в залежності від їхнього досвіду. Укладачі рейтингу зазначають, що в поняття компенсації входять зарплата, акції та бонуси, отримані за минулий рік, але для простоти ми ототожнюємо “компенсацію” та “зарплату” в даній статті. Інженер початкового рівня (від 0 до 2 років досвіду) Рейтинг включає інженерів рівня Intern/Trainee/Junior. Зазвичай це випускники з невеликим або взагалі нульовим досвідом в галузі. Вони розвивають та підтримують компоненти низької та помірної складності, використовуючи настанови та підтримку членів команди з більшим досвідом. Тут вам можуть бути знайомі Figma та LinkedIn. Перша компанія – всесвітньо відомий розробник онлайн-інструменту для дизайнерів, а друга – соціальна мережа для встановлення ділових зв’язків.  Engineer (від 2 до 5+ років досвіду) Даний тайтл можна прирівняти до Middle. Сюди відносяться спеціалісти, які працюють над компонентами середньої та високої складності, і навіть здатні керувати невеликою командою або проєктом. Можуть менторити та консультувати менш досвідчених інженерів, проводити код-рев’ю, працювати над невеликими проєктами від початку до кінця. Межі відповідальності такого фахівця різняться від команди до команди. В багатьох компаніях спеціалісти можуть працювати постійно на цьому рівні, не боячись, що їх звільнять за те, що вони не просуваються кар’єрною драбиною далі. Senior Engineer (понад 5 років досвіду) Сеньйори – від них очікується керування іншими та просування власних комплексних технічних ініціатив. Можуть виконувати візіонерські функції, визначаючи подальший вектор руху команди. Також здатні впливати на інші команди в межах компанії. Їхня роль більше охоплює дизайнерські задачі, ніж реалізацію – залежно від розміру та очікувань компанії. Зазвичай таких спеціалістів в компанії не більше 30%.   У кого в ІТ найбільші ЗП? Рейтинг світу. Найвищі зарплати керівної інженерної ланки Staff Engineer – інженер управлінського апарату Ця посада передбачає 10+ років досвіду, і є досить бажаною порівняно з Junior, Middle та Senior. Менше 10% персоналу займають цю позицію, при цьому їхній вплив досить масштабний і простягається на різні організації. Інженерам даної ланки довіряють важливі бізнес-проєкти та встановлення технічного бачення для однієї або декількох організацій. Найбільшу винагороду отримують саме staff-інженери з OpenAI – компанії, що наприкінці 2021 року випустила в світ славнозвісний ChatGPT і нещодавно мала бурхливий скандал навколо звільнення гендиректора OpenAI Сема Альтмана. Principal Engineer – головний інженер Посада передбачає 15+ років досвіду, причому менше 3% персоналу сягають цього рівня. Головний інженер характерний для компаній середнього та великого розміру, а в маленьких зазвичай відсутній. Вплив Principal Engineer може поширюватися як на всю компанію, так і на індустрію. Від цих спеціалістів очікують повну автономію в роботі. Аналітики рейтингу зазначають: даний тайтл властивий малому відсотку людей в компанії, а тому деякі компанії не мають інформації в достатній кількості, аби бути включеними в цей список.   Зарплати інших ІТ-фахівців. ІТ-компанії з найбільшими ЗП Аналітики даного звіту розробили стандарт рівнів для менеджерських ролей та ролей індивідуального спеціаліста (individual contributor) в цьому році. Оскільки на початку 2023 у них не була встановлена система рівнів, вони вказують ТОП-5 компаній з найвищим рівнем компенсації, використовуючи медіанне значення в межах компанії для наведених нижче професійних категорій незалежно від рівня. Варто враховувати, що це найвищі медіани, і вони можуть не відображати весь ринок. Software Engineering Manager SE Manager може керувати однією або кількома командами інженерів, які створюють програмне забезпечення (ПЗ). Він комбінує технічні обов’язки з управлінськими і відповідає за: створення сприятливого середовища для ефективної роботи Engineering-команди; визначення структури та навантаження, яке покладається на кожного в команді; трансляцію команді загального руху та цілей компанії; контроль та підготовку технічного роадмапу разом з Tech Lead та інженерами для визначення інструментів, ресурсів та пріоритетів у роботі; надання технічної експертизи; вимірювання показників якості та ефективності команди; тощо. Product Manager Product Manager орієнтований на стратегічне управління продуктом в цілому, включаючи стратегію продажів, ринковий аналіз і взаємодію з клієнтами. На відміну від SE Manager, даний фахівець досить далекий від технічної складової і натомість сконцентрований на досягненні бізнес-цілей. Він фокусується на визначенні функціональності та властивостей продукту, які задовольняють потреби клієнтів, взаємодіє з усіма рівнями команди, включаючи розробників, маркетологів, дизайнерів і т. д. Product Designer Це НЕ UX/UI дизайнер. У Product Designer`а зміщено фокус з UX/UI на досягнення цілей бізнесу, продукту. Якщо “юікс-юай” займається безпосередньо створенням інтерфейсу (роль виконавця), то PD аналізує ринок користувачів, досліджує та визначає їхні потреби, на основі чого можна спроєктувати якісний інтерфейс, який приноситиме користувачеві максимально комфортний досвід, а власнику – аудиторію і прибутки (роль мудрого архітектора, дослідника). Hardware Engineer Важка артилерія від світу розробки. Ці спеціалісти займаються не програмним, а апаратним забезпеченням – “залізом”. Серед їхніх обов’язків: дизайн, розробка, тестування комп’ютерних систем та пристроїв, розробка схемотехнічних рішень та друкованих плат, покращення існуючих пристроїв (заміна компонентів, тестування тощо). Data Scientist Data Scientists працюють з великими обсягами даних і виконують збір, аналіз, структурування і подальшу візуалізацію інформації. Спочатку йде збір великої кількості невпорядкованих даних, а потім – їхнє перетворення у зручний формат, з яким далі працюють аналітики.   Найвищі зарплати в США, Європі та решті світу В яких містах світу топові ЗП у галузі Software Engineering? Американські аналітики дають відповідь і на це питання. Ситуація в США, Європі та світі загалом, відповідно: До останньої картинки автори додають примітку: цей список включає лише одне місто з найвищою оплатою праці в кожній країні. Інші міста в межах країни також можуть мати високу зарплату, яка не відображена в цьому списку.   Дані для рейтингу Головне джерело даних для аналітики – анонімні відгуки, які можна залишити у відповідній формі на сайті. Для цього треба надати наступну інформацію: Розмір компенсації. Інформація про рівні у компанії. Бонуси від компанії. У 2023 році компанія Levels.fyi отримала понад 200 000 заявок від тисяч компаній з усього світу. Нещодавно ми досліджували рівень ЗП та кар’єрний шлях українських DevOps-спеціалістів та Embedded-розробників – переходьте за посиланнями, щоб дізнатись, наскільки цінується їхня праця.

Привіт, друзі! Бурхливий та насичений подіями 2023 рік вже позаду. Багато українськомовних курсів, статей та інших активностей на ITVDN вже у фазі активного створення, а поки можна поглянути на все найкраще, що було опубліковано в минулому році! Пропонуємо до вашої уваги ТОП-10 відео курсів ITVDN, вебінарів та статей за 2023 рік. Найкращі курси У 2023 році ми випустили цілих 30 нових відео курсів українською мовою за такими напрямками, як FrontEnd, Python, Java, C#/.NET, PHP, Unity / Game розробка, мобільна розробка на Android тощо.  ТОП-10 найкращих нових відео курсів у 2023 (за кількістю переглядів): Python Базовий. JavaScript Стартовий. HTML5 & CSS3 Стартовий. React Базовий. Python Стартовий. Docker. Основи використання Git. SQL Базовий. TypeScript. Основи адміністрування Windows Server. Найкращі вебінари У 2023 році ми провели 73 вебінари, серед яких були огляди ІТ-спеціальностей, поради з підготовки до співбесіди та отримання першої роботи в ІТ, а також практичні вебінари з різних мов програмування та технологій. ТОП-10 вебінарів 2023 року за кількістю переглядів та вподобайок: Kotlin – мова Full Stack розробника. Автор – Григор Артем, інженер-дослідник. Пишемо веб-сайт на Django за допомогою ChatGPT. Автор – Лазорик Михайло, Software developer. Пишемо гру Танки 2D на Pygame. Автор – Догонов Дмитро, Python Developer. Spring Cloud: інтеграція з зовнішніми веб-сервісами на прикладі Feign Client. Автор – Боговик Максим, консультант з Java стеку технологій. Математика для програміста (Частина 1 та Частина 2). Автор – Ольга Задорожна, Software Engineer у Meta (Facebook). Microsoft Azure – що це? Огляд можливостей і приклади застосування. Автор – Олег Заревич, DevOps інженер. Redux vs React Query. Що краще обрати для проєкту? Автор – Тисячний Влад, Middle React.js / React Native Developer. Розробляємо блог на Django з нуля. Автор –  Окаль Юрій, Senior BackEnd Developer at TanSoft Canada. PyCharm з нуля. Найкраща IDE для Python розробки. Автор – Костянтин Зівенко, BackEnd Developer з Чорногорії (світчер у 35+ років), має 3 вищі освіти та досвід роботи на керівних посадах у великих компаніях (максимальна кількість підлеглих – близько 10 000 осіб). Як стати розробником після 35 років. Автор – Валевський Андрій, Java Software Engineer, ментор з Java. Найкращі статті У 2023 році ми опублікували 8 статей, ось п’ятірка, яка користується найбільшою популярністю серед читачів: Що повинен знати FrontEnd розробник у 2023 році. Яку мову програмування варто вчити першою. Як стати тестувальником, QA, QC у 2023 році? Що варто знати та вміти, аби отримати роботу в ІТ-компанії? ТОП-10 телеграм-каналів для пошуку роботи в IT. Хто такий DevOps інженер? Обов’язки, інструменти та ЗП. Збагачуйте себе знаннями та навичками на ITVDN! Нехай щастя буде вашим вірним супутником у новому році!

Щоб бути в курсі актуальних пропозицій на ринку праці та не пропустити повз себе кар’єрні можливості, скористайтесь добіркою – ТОП 10 актуальних та корисних Telegram-пабліків, які сприятимуть вашому активному пошуку роботи в IT та вашому розвитку. Junior Level: вакансії, івенти, можливості Канал для твого розвитку в Digital та ІТ 🚀 Щодня свіжі вакансії та стажування для джунів, а також багато інформації про цікаві івенти, курси, вебінари тощо. Jobzilla UA Агрегатор вакансій віддаленої роботи від перевірених компаній для кожного: з досвідом чи без, з зарплатою від 300$ до 3000$. Також на каналі можете знайти безліч корисних порад щодо працевлаштування та кар'єрного розвитку. Don't Panic Junior IT Jobs Це канал для пошуку роботи в ІТ та можливостей розвитку для джуніків. Публікують вакансії у вигляді добірок як для технічних спеціалістів, так і для менеджерських спеціальностей. Також канал публікує анонси технічних вебінарів. UNI WORK Допоможе знайти першу роботу навіть в умовах війни. Стажування, вакансії та освітні рішення від більш ніж 150 компаній. В середньому публікують 4 вакансії в тиждень, серед них часто зустрічаються для кандидатів без досвіду. InternsGo! Авторський канал для успішної кар'єри молоді. Створена швидка навігація каналом за допомогою хештегів, тому потрібну інформацію можна знайти легко та швидко, а саме: публікації вакансій та стажування за конкретною сферою, країною, позицією тощо. ITExpert Vacancies Кар'єрні поради та вакансії у сфері IT для українців. Канал ведуть фахівці рекрутингової компанії ITExpert, публікації вакансій для них безкоштовні. Головна мета — допомогти українським айтівцям у складні часи. Junior дайджест dou.ua Актуальна інформація про безкоштовні курси, стажування, інтернатури від українських ІТ-компаній. Також канал генерує новини з сайту DOU, тому ви завжди будете в курсі усіх новітніх подій. JOB for Ukrainians Телеграм-канал, який допомагає українцям знайти роботу у такий складний для всієї України та світу час. На каналі публікуються вакансії як для розробників так і для нетехнічних спеціалістів. Щоб знайти потрібну вакансію, використовуйте хештеги. Вакансії на Джині Телеграм-бот, який генерує вам вакансії за вашим профілем на Джині. Перейдіть у свій профіль в розділ підписки та додайте телеграм, далі за допомогою підказок можете шукати цікаві вам вакансії вже в самому боті. Дуже зручно та швидко. INCO кандидати Абсолютно безкоштовна платформа для пошуку роботи в IT. На сайті INCO ви можете анонімно розмістити своє резюме, яке буде також опубліковане в телеграм-каналі, щоб зацікавлений роботодавець зв'язався з вами. А також корисні поради пошуку роботи в IT від HR-менеджера Пошук роботи – цікавий та складний процес, який вимагає щодених зусиль. Якщо ви прагнете отримати роботу в компанії, в якій зможете реалізовувати свої здібності, отримувати конкурентну оплату праці та виходити на новий рівень як розробник, будьте готові багато часу приділяти якісній підготовці. Практикуйтесь щодня, покращуйте свої навички, готуйтесь до інтерв’ю; прокачувати soft skills також необхідно. Не забувайте і про вивчення англійської мови.  Існує декілька методів пошуку роботи: “Пасивний пошук” та “Активний пошук”.   Перший варіант рекомендую використовувати, якщо ви маєте основну зайнятість та потреба в зміні роботи не є терміновою, або ж ви досвідчений розробник, який працює над власним брендом, і ваші навички затребувані на ринку праці – тоді зацікавлені в вашому досвіді рекрутери самостійно будуть вам писати та хантити у свою компанію. Що ж необхідно зробити щоб розпочати пасивний пошук роботи? Створення та розміщення CV на Job-сайтах. Актуалізація інформації на ваших сторінках в соціальних мережах. Підписка на розсилання про нові кар’єрні можливості. Якщо ви новачок або маєте мінімальний досвід роботи, варто звернути увагу на другий варіант та займатися активним пошуком роботи.  Що включає в себе такий метод? Аналіз ринку праці. Визначення цільових вакансій. Оцінка власних практичних та теоретичних навичок відносно сучасних вимог. Формування списку потенційних ресурсів для пошуку роботи. Визначте, скільки часу на день/тиждень ви готові приділяти для досягнення результату. Підготовка якісного CV, яке розкриває ваші сильні сторони. Написання Cover Letter – в ньому ви можете включити інформацію, яку не зазначили в CV, але яка може бути важливою та цікавою для майбутніх роботодавців. Створення якісного та інформативного LinkedIn. Це одна з основних професійних соцмереж для побудови ділових стосунків, пошуку роботи тощо. Опрацювання та аналіз зворотного зв’язку, після тестових завдань та співбесід. Це допоможе вам зрозуміти ваші сильні та слабкі сторони. Постійний саморозвиток та вдосконалення практичних навичок. В сучасних реаліях, коли ринок перенасичений кандидатами, варто надавати перевагу саме активному пошуку роботи. Тоді ваші шанси отримати бажану посаду будуть значно вищі. І не забувайте: пошук роботи – це також робота. Успіхів! Якщо ви вважаєте за потрібне додати інші корисні ресурси для пошуку роботи в IT-галузі, пишіть у коментарях.

Фрілансери не завжди укладають договір на розробку сайту із замовниками, покладаючись на домовленості, озвучені усно чи сформульовані в переписці. Адже сам процес узгодження і підписання документів займає певний час і потребує зусиль. Втім, співпраця на довірі доволі ризикована для обох сторін. Крім того, що один із учасників може безкарно відмовитися від виконання своїх обов’язків, є чимало ньюансів, які ускладнюють співпрацю в разі відсутності документально завірених алгоритмів роботи. Навіть коли обидві сторони мають намір добросовісно виконати всі домовленості, їх може підвести банальне непорозуміння. Договір не лише гарантує захист як виконавця, так і замовника. Він є певною дорожньою картою, яка описує кожен етап робіт, кожну можливу ситуацію, дії партнерів у разі форсмажорів та алгоритм врегулювання спірних питань. Навіть підписання типового договору частково зменшує ризики, але ми все ж радимо створювати окремий контракт для кожного замовника. Хостинг-провайдер та реєстратор доменних імен Cityhost.ua пропонує читачам нашого блогу матеріал, створений спільно з IT-юристами, щоб розібратися в усіх аспектах створення договору на розробку сайту. Етапи узгодження та укладання договору Укладання договору починається в той момент, коли замовник та виконавець обговорюють та узгоджують всі деталі проєкту. Тому цей етап також має бути задокументований у вигляді брифу. Крім того, потрібно скласти детальне ТЗ та сформувати сам договір. Давайте розглянемо кожен крок на цьому шляху. Заповнення брифу Замовники дуже не люблять заповнювати бриф і намагаються пропустити цей етап, обговоривши всі деталі по телефону або в чаті. Часто відбуваються ситуації, коли замовник каже «Ви професіонал, подивіться самі, що там потрібно зробити і викладіть свої пропозиції». Така позиція нерідко виливається у результат: «Ні, це не те, що потрібно, запропонуйте щось інше».  Насправді ж бриф дуже потрібен для співпраці, бо в ньому містяться відповіді на важливі для виконавця запитання. Кожен розробник укладає свій бриф, який може виглядати подібним чином: Назва та галузь роботи компанії. Цільова аудиторія. Локація (місцева, всеукраїнська, міжнародна). Цінності, місія. Корпоративний стиль — слоган, корпоративні кольори, стиль промо-матеріалів (бажано надіслати ці матеріали на пошту). Тип сайту, який бажаєте замовити (візитка, інтернет-магазин, корпоративний сайт, наявність/відсутність блогу тощо). Орієнтовна структура сайту, назви розділів. Побажання щодо оформлення сайту. Приклади сайтів, на які ви б хотіли орієнтуватися. Можна розробити типовий бриф, але все ж варто вносити в нього додаткові запитання, призначені для конкретного замовника. Складання технічного завдання Після заповнення брифу замовник уточнює питання та вносить пропозиції, яким він бачить майбутній сайт — основну концепцію, кількість розділів, візуальний стиль. На основі цих перемовин складається технічне завдання і одночасно з тим починається розробка договору.  У техзавданні прописується конкретний результат і всі послуги, які надає розробник. Це дуже важливо, оскільки «зробити сайт» — доволі розмите поняття. Може трапитися, що власники фірми звернулися до фрілансера, який тільки пише код, і не займається дизайном і контентом. Тож він буде чекати від замовника макет, тексти та фото. Інші ж фрілансери можуть зробити сайт «під ключ» і мають розгалужену мережу субпідрядників — дизайнерів, копірайтерів, фотографів тощо. Техзавдання прописується максимально детально і включає в себе вимірювані параметри, на кшталт: «Сайт має складатися з 5 розділів: головна сторінка, сторінка «Про нас», сторінка контактів, сторінка для представлення товару, розділ для блогу». Якщо у сайту є блог або розділ новин, у ТЗ також пишеться, чи має виконавець заповнити цей розділ 2-3 новинами, чи робить тільки структуру блогу. Чим докладніше буде описано кожен нюанс розробки сайту, тим менше залишиться простору для непорозумінь. Обговорення та узгодження тексту договору Для початку потрібно визначитися з типом договору. Існують два типи — договір на надання послуги та договір підряду. Вони відрізняються тим, що у першому випадку ключовим є сам процес роботи, а у другому — результат. Наприклад, SEO-просування не має кінцевого результату і триває завжди, доки існує сайт — тоді заключається договір на співпрацю. Для розробки сайту більше підходить договір підряду, оскільки замовнику потрібен сайт, його цікавить завершена робота та її плоди. Далі потрібно прописати почергово всі головні етапи співпраці: Надання замовником матеріалів розробнику. Це можуть бути тексти, фото, відео, логотип тощо. Створення та затвердження макету. Розробка сайту. Внесення правок. Перевірка та прийом роботи. Підписання актів про виконання робіт. Оплата виконаної роботи. Це орієнтовний перелік, бо у кожного сайту можуть бути свої етапи. Наприклад, виконавець не лише розробляє сайт, а й проводить маркетингові дослідження, вивчає ринок, аналізує конкурентів та на основі отриманої інформації дає рекомендації замовнику щодо концепції сайту — це окремий етап, який також потребує зусиль та впливає на формування вартості замовлення.  Основні правила складання договору Є елементи договору, без яких він не зможе стати чітким документом, що дисциплінує сторони в процесі роботи. Терміни Обов’язково потрібно прописати терміни виконання кожного етапу. Якщо уважно придивитися до порядку дій, ви побачите, що частина роботи залежить від виконавця (створення сайту, внесення правок), а друга частина — від замовника (надання матеріалів, перевірка, прийом роботи). Якщо в договорі прописана тільки фінальна дата, коли розробник повинен здати сайт, він може потрапити у часову пастку — строки затягнуті, але не з його вини. Також потрібно прописати дії сторін в разі, якщо хтось із партнерів виконує свої обов’язки неналежним чином. Наприклад, якщо замовник не здійснив прийом роботи протягом семи днів, вона автоматично вважається прийнятою. Прописуйте не конкретні дати, а час між етапами, наприклад: «Розробник зобов’язується надати початковий макет сайту протягом 4 днів з моменту отримання матеріалів». Вимірюваність Всі пункти в договорі мають бути описані таким чином, щоб їх можна було виміряти якимось конкретним параметором — часом, дією, результатом. Наприклад, обговорення та внесення правок відбувається протягом тижня після того, як розробник надішле електронною поштою посилання на готовий сайт на таку-то адресу (конкретну). Таким чином знижується вірогідність плутанини, коли одна сторона чекає результат у Вайбері, інша пише повідомлення у Фейсбуці, а час спливає. Конкретика Дуже важливо прописувати чіткі формулювання. До прикладу, «надати макет сайту» — це нечітке формулювання. А ось «надати макет сайту у вигляді проекту в Figma з доступом редактора» — це вже щось конкретне. Так само потрібно прописувати, на які матеріали очікує розробник — фотографії у форматі .png з розширенням не менше 600 пікселів по ширині, тексти у форматі Google Docs з відкритим коментуванням. Далеко не всі замовники орієнтуються в комп’ютерних технологіях. Якщо ваш клієнт — невелике будівельне підприємство чи ФОП, який ремонтує велосипеди, для нього не існує ніяких опцій за замовчанням. Тому конкретний і детальний опис всіх вимог та етапів — це скоріше необхідність, інакше на клієнта і розробника може чекати багато сюрпризів. Збалансованість У договорі мають бути рівномірно дотримані права та обов’язки обох сторін. Не має бути такого, що в усьому винен замовник або вся відповідальність лежить на виконавцеві. Якщо якийсь етап роботи залежить від дій певної сторони — вона несе відповідальність за його реалізацію або сплачує неустойку (чи підпадає під інші санкції) в разі невиконання обов’язків з власної вини. Пункти договору, які потребують уваги У цей розділ винесемо ті аспекти співпраці, про які фрілансери-початківці можуть не знати чи не вміти правильно їх врегулювати. 1) Кількість та порядок поправок, внесення змін у ТЗ Важливим є питання кількості можливих правок та внесення змін у технічне завдання. Найкращий і перевірений метод — коли замовник надсилає всі правки в одному документі, а виконавець вносить їх всі одразу. Оптимально робити три кола правок; якщо у клієнта з’являються додаткові правки, це має оплачуватися. Така політика в першу чергу захищає виконавця від десятків переробок і дисциплінує замовника, який з більшою уважністю вирішує, чи потрібна ця правка. Правки мають бути конкретними та аргументованими, без формулювань на кшталт «зробіть якось інакше, але не так, як є». Щодо ТЗ — всі зміни, які замовник хоче внести в нього вже під час роботи, мають також додатково оплачуватися. В разі потреби можна прописати, які зміни та якого масштабу можна вносити, скільки коштує кожна з них. Одна справа поміняти фотографію, і зовсім інша, коли замовник на фінальній стадії вирішує замінити CMS (по факту це означає робити все наново). 2) Авторські та майнові права Питання авторських прав стосується як матеріалів, які використовуються на сайті під час розробки, так і використання матеріалів сайту після завершення робіт. Важливо відстежувати, чи є унікальним контент, який надає замовник або пропонує виконавець. Для убезпечення обох сторін потрібно прописати порядок дій для запобігання ситуаціям, коли можуть бути порушені авторські права третіх оосіб або одного з учасників проєкту. Наприклад, сторона, яка надає матеріали, має долучити документи, які підтверджують право власності на них — квитанції на придбання фото- та відео-матеріалів чи інший контент. Або для спрощення процедури можна просто зазначити, що відповідальність за порушення авторського права несе сторона, яка надала матеріали. До об’єктів авторського права відносяться назва сайту, тексти, фото, відео, дизайн та код. У договорі має бути вказано, кому належать майнові та авторські права на всі елементи проєкту після його завершення та чи може розробник використовувати якісь із матеріалів для подальшої роботи. Для орієнтиру використовуйте Закон про авторське право і суміжні права. 3) Співпраця з іншими підрядниками Сайт складається з багатьох компонентів, і не всі роботи підрядник може виконати самостійно. Якщо він звертається до субпідрядників для створення дизайну чи текстів, це також має бути зафіксовано у договорі. Але в будь-якому разі за якість кінцевого результату відповідає виконавець. 4) Відповідальні особи за комунікацію з виконавцем Цей момент особливо вартий уваги, якщо компанія-замовник велика, в ній є багато різних відділів та працівників. Скоріш за все, виконавець не працюватиме напряму з директором, а спілкуватиметься з кимось із менеджерів. В такому разі договір має містити ПІБ, посаду та контакти особи, відповідальної за комунікацію. Не завадить також вказати, які канали спілкування вважаються офіційними — ними можуть бути не лише пошта, а й акаунт у Телеграмі чи сторінка у Фейсбуці. В разі, якщо різні аспекти будуть узгоджуватися з різними людьми, це також має бути вказано. Наприклад, за фінансові питання відповідає бухгалтер, за узгодження макету — дизайнер компанії, всі інші питання — до менеджера. Але все ж краще, коли проект курує одна конкретна людина і несе відповідальність за своєчасну та ефективну комунікацію. 5) Форсмажорні обставини Бувають ситуації, коли хтось не може виконати свої обов’язки з причин, які не залежать від нього. На цей випадок потрібно винести окремим пунктом подолання форсмажорних обставин: що можна вважати такими обставинами та порядок дій в разі їхнього виникнення (наприклад, відстрочка для виконавця для завершення робіт або відстрочка оплати для замовника). Зазвичай в цей перелік входять пожежі, стихійні лиха, бойові дії, страйки, введення карантину та інші обставини, які не можна передбачити та підготуватися до них. 6) Фінансові питання В цю категорію входить не лише порядок оплати за виконану роботу (аванс, гонорар) а й супутні витрати. Сюди можна віднести оплату домена та хостинга, замовлення текстів, дизайну, фотозйомки тощо. Виконавець може ці витрати включити в суму гонорару, але можна і покласти їх на замовника. Це все обговорюється і прописується. Також у договорі мають бути зафіксовані такі моменти як порядок оподаткування, розрахункова валюта, рахунки для отримання коштів, порядок перерахунку та спосіб підтвердження отримання коштів виконавцем. 7) Прийом роботи або відмова від нього На перевірку та прийом роботи виділяється певний термін, протягом якого замовник може висунути обгрунтовані зауваження та вимоги щодо доопрацювання сайту або відмовитися прийняти роботу, надавши чіткі аргументи. Відмовитися від прийому роботи можна тільки в разі, якщо сайт не відповідає технічному завданню, виконаний з порушенням законів або має інші об’єктивні недоліки, які унеможливлюють його використання і які можна довести. Не можуть бути враховані суб’єктивні аргументи, коли сайт виконаний за всіма домовленостями, але розробник уявляв собі його якось інакше. Якщо розробник виконав всі пункти ТЗ і договору, клієнт не може відмовитися від підписання акту. В разі, якщо йдеться про масштабні проєкти з великою сумою оплати, радимо звернутися за консультацією до юриста, який допоможе прописати договір максимально чітко та уникнути «шпарин» для подвійного трактування.

Junior 1.1 Теория тестирования. 1.2 AQA      1.2.1 Программирование и Selenium      1.2.2 TestNG/JUnit, Git, CI              1.3 Web              1.4 Mobile              1.5 Практические задания   Middle 2.1 Теория 2.2 AQA      2.2.1 Selenium      2.2.2 Тестовая инфраструктура 2.3 Web 2.4 Mobile 2.5 Практические задания   Senior 3.1 Теория 3.2 Практические задания     Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 12 января 2022 года. Оригинальная версия на украинском языке доступна по ссылке. Эту подборку вопросов, которые ставят кандидатам разных уровней на технических собеседованиях на позицию QA, составили совместными усилиями практики. Список – лишь ориентир. Кандидатам советуем пробежаться по вопросам и отметить неизвестные слова, погуглить и заодно повысить шансы пройти собеседование. Интервьюерам – пополнить свой запас интересных вопросов. Но не переборщите :) Если вы не претендуете на позицию QA, просмотрите переводы подборок вопросов по другим популярным IT-специальностям.   Junior   Теория тестирования 1. Что такое тестирование? 2. Зачем тестировать ПО? 3. Какие существуют этапы тестирования? 4. Какие типы тестирования можете назвать? 5. Какие уровни тестирования знаете? 6. Какие техники тест-дизайна знаете? 7. Что такое техника анализа классов эквивалентности? 8. Что такое техника анализа предельных значений? В чем ценность этой техники? 9. Что такое Regression и Confirmation тестирование, какая между ними разница? 10. Как часто следует проводить регрессионное тестирование продукта? 11. Какие бывают виды интеграционного тестирования? 12. Что такое Configuration Testing? 13. Что такое Exploratory Testing? 14. Какие существуют UI-стандарты? 15. Что такое Black/Grey/White Box Testing? 16. Что такое Performance Testing? 17. Что такое Smoke и Sanity тестирование и какая между ними разница? 18. Что такое Traceability Matrix? 19. Что такое Sanity Testing? 20. Что такое End-to-End тест? 21. Что такое тестирование безопасности? 22. Что такое испытание на основе рисков? 23. Что такое динамическое тестирование? 24. Что такое «парадокс пестицида»? 25. Опишите основные фазы STLC? Дайте определение Entry и Exit Criteria. 26. Что такое Bug, Error, Failure, Fault? 27. Какие есть атрибуты баг-репорта? Какие основные поля для заполнения? 28. Какова разница между приоритетом и серьезностью? 29. Приведите примеры серьезного, но не приоритетного бага. 30. В чем разница между валидацией и верификацией? 31. Зачем нужна тестовая документация? Какие её виды? 32. Что такое тест-план? Какие элементы у него есть? 33. Какую обязательную информацию должен содержать тест-план? Как правильно его использовать, поддерживать и нужен ли он вообще для большинства проектов? 34. Какая разница между чеклистом и тест-кейсами? 35. Приведите пример хорошего тест-кейса.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе QA Стартовый (урок 1, урок 3, урок 4, урок 5), Основы тестирования (урок 6), Основы тестирования ПО (урок 1-5), а также в вебинаре “QA практикум. Техники тест дизайна” (часть 1 и часть 2).   AQA (Automation QA)   Программирование 36. Что такое ООП? Назовите его принципы с примерами? 37. Что такое интерфейс? Что такое абстрактный класс? Чем они отличаются? 38. Что такое SOLID? Приведите примеры. 39. Что такое DRY, KISS, YAGNI? 40. Какие паттерны GOF вам известны? Приведите примеры их использования. 41. Что такое PageObject и PageFactory? 42. Какая иерархия Collections? 43. Какая разница между Thread class и Runnable interface? 44. Какая разница между String, Stringbuffer и Stringbuilder? 45. Разница между final, finally и finalize?   Selenium 46. ​​Что такое Selenium и зачем его используют? 47. Что такое драйвер браузера? 48. Какие виды локаторов страницы существуют? Каковы их преимущества и недостатки? 49. Что такое Selenium Waits? Какие есть и чем отличаются? 50. Какие exceptions может бросить Selenium? Что они означают и как их обрабатывать? 51. Для чего используют JavaScriptExecutor? Приведите примеры. 52. Что такое Selenium Grid? 53. Какие способы click и send keys Selenium? 54. Как вы запускаете параллельное выполнение тестов? Что такое ThreadLocal? 55. Какая разница между Action и Actions? 56. Как написать метод isElementPresent? 57. Как вычитать данные из динамической веб-таблицы? 58. Можете ли вы назвать 10 интерфейсов в Selenium? 59. Назовите два способа, позволяющих автоматизировать капчу. 60. Вспомните типы навигационных команд Selenium. 61. Как найти поврежденные ссылки в Selenium WebDriver? 62. Какую технику следует рассмотреть, используя весь сценарий, если «нет ни frame id, ни frame name»?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java (урок 1), Автоматизация тестирования мобильных приложений (урок 5), а также в вебинаре “Selenoid или Selenium Grid — что лучше?”.   TestNG/JUnit 63. Для чего нужны TestNG/JUnit? 64. Какие инструкции используются в TestNG/JUnit? 65. Какие assertions есть в TestNG/JUnit? 66. Как выполнять тесты параллельно TestNG/JUnit?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 4).   Git 67. Для чего используют системы контроля версий? 68. Что такое Git? Каков принцип его работы? 69. Что такое commits, branches в Git? 70. Для чего нужны GitHub, GitLab и другие, базирующиеся на Git, вебхостинги проектов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Основы работы с Git.   CI 71. Что такое CI? 72. Как автоматическое тестирование интегрируется в CI? 73. Как настроить Job или Pipeline на знакомом вам CI-инструменте? 74. Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете? 75. Какую информацию должен содержать отчет о выполнении автоматических тестов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing (урок 4).   Web 76. Что такое клиент-серверная архитектура? 77. Что может выступать в роли клиента? 78. Что такое REST API, SOAP? В чем разница? 79. Какие протоколы передачи данных знаете? 80. Какие способы взаимодействия с API существуют? В чем разница между ними? 81. Как можно протестировать API, что там нужно проверять? 82. Как расшифровывается CRUD? 83. Чем отличается GET от POST? 84. Какие отличия между XML и JSON? 85. Какие знаете форматы передачи данных? 86. Как происходит шифрование? 87. Какие бывают виды баз данных? 88. Охарактеризуйте каждый класс status code (1хх; 2xx; 3xx; 4xx; 5xx). 89. Какие есть HTTP-методы? 90. Какие знаете Web elements? 91. Какие браузеры знаете? В чем их отличие? 92. Для чего необходимы инструменты разработчика в браузере (Chrome DevTools) и как они помогают в тестировании. 93. Что такое кэш? 94. Что такое сессия? 95. Зачем нужны cookies? 96. Что такое фрейм? 97. Что такое HTML/CSS/JavaScript? 98. Какую структуру имеет веб-страница? 99. Зачем чистить кэш? 100. Какие виды тестирования можно применить только к Web? 101. Для чего в веб-страницах используют JavaScript? 102. Что такое REST? 103. Что такое AJAX?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах QA Стартовый (урок 6), Web Testing, SQL Базовый.   Mobile 104. Какие мобильные платформы существуют? 105. Какие версии Android и iOS используются на рынке (минимальные и максимальные)? 106. Какие версии Android нужно тестировать, если заказчик сказал поддерживать с версии 5.0? 107. Назовите типы мобильных приложений. 108. Каков формат файлов сборок приложений для Android и iOS? 109. Что такое ADB? 110. Как снять логи с AOS/IOS? 111. Что нужно проверять при использовании сканера отпечатка/Face ID? 112. Как я могу запускать тесты Android без Appium? 113. Объясните концепцию дизайна Appium.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 114. Написать чеклист для функционала корзины в интернет-магазине. 115. Написать тестовые наборы данных для поля ввода даты, которое отсеивает пользователей в возрасте до 18 лет. 116. Написать чеклист тестирования формы ввода данных платежной карты. 117. Протестовать «предмет» относительно различных видов тестирования. (Предмет - лифт, карандаш, калькулятор и т. д.) 118. Есть Input поле, принимающее целые значения от 18 до 99 включительно. Надо протестировать с помощью техники тест-дизайна Boundary Values ​​Analysis и Equivalence Partitioning. 119. Есть веб-страница с полями: e-mail, password и кнопкой submit. Необходимо привести примеры отрицательных тест-кейсов, которыми можно проверить эту страницу. 120. Привести примеры тест-кейсов для функционала, находящегося на нескольких страницах проекта (например, поле поиска). 121. Как протестировать процесс оплаты в интернет-магазине? 122. Как протестировать сломанный тостер? 123. Объясните для 7-летнего ребенка, что такое база данных. 124. Определите необходимое количество функциональных тест-кейсов, чтобы проверить Log in форму. 125. Есть форма регистрации в веб-приложении с полями (first name, last name, username, password, repeat password) и кнопкой Register. Какие проверки нужно провести? 126. Поле username должно быть обязательным, но оно не является обязательным. Приведите пример баг-репорта, созданного для этой ошибки. 127. Как бы вы провели smoke-testing для приложения типа Telegram? 133. Как будет выглядеть баг-репорт, если, к примеру, не работает электрический чайник? 128. Есть таблица books с полями: name, price, page_count. Следует выбрать все имена книг, в которых price более 10 единиц и количество страниц от 20 до 100. 129. У вас есть функционал калькулятора, который доступен через веб-браузер по ссылке. Он имеет только функцию делить, так сказать, MVP-версию. Диапазоны для вписывания в числитель и делитель от 0,1 до 99,9. Вывод значения происходит автоматически, потому что front-end реализован на React JS. Как вы будете тестировать этот функционал? Какие виды тестирования примените? Какие техники тест-дизайна используете?     130. Задание на работу с SQL.   извлечь номер телефона и адрес пользователя Muzik. Извлечь данные о пользователях, имеющих сумму заказа более 2000 грн. Подсчитать количество заказов в таблице и общую сумму сделанных заказов.     131. Ваша компания разрабатывает программное обеспечение для медицинских систем, и вы тестируете компонент, управляющий дефибриллятором сердца. Вы заметили, что одно решение в тестовом модуле состоит из 34 независимых атомарных условий. Какой метод тестирования белого ящика следует выбрать для этого и почему? 132. Оздоровительная программа для сотрудников совмещена с оплатой медицинского страхования и имеет следующие правила:   сотрудники, потребляющие 17 единиц или менее алкоголя в неделю, получают $28 скидки на оплату. Для сотрудников, которые заполнят «Оценку риска для здоровья», оплата уменьшается на $23. Сотрудники, участвующие в ежегодном контроле за состоянием здоровья в компании: получат скидку на $50 за то, что имеют индекс массы тела (ИМТ) 25,5 или менее, и $19 скидки при ИМТ ниже 30. Некурящие получают дополнительную скидку на $46. Курильщики, присоединившиеся к курсу отказа от курения, получают скидку в $24. Курильщики, не присоединившиеся к курсу отказа от курения, оплачивают дополнительно $75.   133. Используя технику классов эквивалентности, сколько тестов нужно написать, чтобы покрыть вышеупомянутые условия на 100%? 134. Какое минимальное количество тестов необходимо для покрытия следующих условий автогражданки:   лица до 18 лет не застраховываются. Для мужчин на красном авто прибавляется +15% к стоимости полиса. Для женщин от 18 до 64 лет страховая премия 1000 грн. Для мужчин от 18 до 64 лет страховая премия 1200 грн. Для лиц старше 64 лет страховая премия 1800 грн.   135. Напишите сценарии автоматического тестирования для сортировки по цене и добавлению товара в корзину на сайте. К вашим тестам добавьте документацию с настройками и разместите ваше решение на GitHub.   Middle   Теория 1. Назовите обязанности QA? 2. Что знаете о тестировании нагрузки? В каком случае следует проводить такое тестирование? На каком этапе готовности продукта? 3. Что такое таблица решений/decision table и как её можно использовать? 4. Что может быть критериями запуска и завершения тестирования? 5. Расскажите о вариантах интегрирования тестовой документации в проект, инструментах для работы с ней. 6. Как организовать сквозное тестирование (e2e)? 7. Какие тест-кейсы можно сдать для тестирования баз данных? 8. Приведите примеры подходов для тестирования локализации. 9. Что такое A/B тестирование? 10. Что такое mock/stub? Какие знаете инструменты для работы с ними? 11. Когда нужно использовать технику Pairwise? 12. Что такое fuzz-тестирование и где его используют? 13. Что такое REgexp? 14. Как меняется стоимость дефекта при тестировании программного обеспечения? 15. Каковы пути анализа бизнеса клиента? Как определить целесообразность того или иного функционала? 16. Назовите последовательность выполнения CI/CD процесса на проекте. 17. Какое должно быть процентное соотношение между положительным и отрицательным тестированием на проекте? 18. Какой вид тестирования целесообразнее проводить до релиза? 19. Есть ли разница между bug leakage и bug release? 20. Может ли быть ситуация, когда критерии завершения (exit criteria) не выполнены? Что должно происходить в этом случае? 21. Что мы действительно должны покрывать тест-кейсами, а что считается избыточным расходом времени и денег? Когда нецелесообразно писать тест-кейсы? 22. Для какого функционала труднее всего написать тест-кейсы? 23. Как посчитать Cyclomatic complexity? 24. В чем основная разница между defect detection percentage и defect removal efficiency? 25. Какие модели risk-based testing вы знаете? 26. Что такое тестирование API? Какими инструментами пользуются для его выполнения? 27. Что такое performance testing? Какими инструментами пользуются для его выполнения? 28. Что такое load и stress testing? Какими инструментами пользуются для их выполнения? 29. Что такое contract testing? 30. Какая разница между Scrum и Kanban? 31. Расскажите о ритуалах, ценностях и ролях в Scrum. 32. Как выбор методологии может повлиять на качество разработки? 33. Нулевой спринт в Scrum. Для тестирования есть задание под названием «Настройка среды». Что здесь нужно выполнять?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing, QA Стартовый, “Методология управления проектами. Вступление в SCRUM”.   AQA   Selenium 34. Расскажите, как вы будете строить и внедрять стратегию по автоматизации тестирования. 35. Как взаимодействуют клиентская библиотека Selenium, драйвер браузера и сам браузер? 36. Для чего используют browser capabilities, arguments и options? 37. Что такое iframe и как с ним работать в Selenium? 38. Как обрабатывать браузерные сообщения (alerts)? 39. Что такое Appium? 40. Что такое Electron-based applications? Как использовать Selenium и Appium для их тестирования? 41. Как взаимодействовать с запросами, отправляемыми из браузера? 42. Как взаимодействовать с cookies, LocalStorage и SessionStorage?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 1) и Автоматизация тестирования мобильных приложений.   Тестовая инфраструктура 43. Что такое и чем отличаются виртуальная машина, симулятор и эмулятор? 44. Что такое контейнер и чем он отличается от виртуальной машины? 45. Как используют виртуальные машины и контейнеры в автоматизации? 46. ​​Что такое IaaS и PaaS? Приведите примеры. 47. Что такое Configuration Management? 48. Что такое Provisioning? 49. Какие команды Linux Shell вам известны? Как с помощью команд Linux Shell найти лог-файл и строчку с ошибкой в ​​файле? 50. Какие команды Windows CMD вам известны? Как с помощью команд Windows CMD найти IP-адрес машины? 51. Что такое SSH и как им пользоваться? 52. Что такое bash и batch скрипты? Зачем их используют?   Web 53. Какая разница между авторизацией и аутентификацией? 54. Как происходит авторизация на сервере? 55. Какие статус-коды ошибок бывают? Может ли сервер отправить код 400, если проблема на его стороне? 56. Как выполнить Debug страницы в браузере? 57. Как протестировать адаптивную верстку? 58. Что такое WebSocket и как проверить обрыв соединения? 59. Каковы есть основные виды уязвимости веб-приложений? 60. Какие инструменты для тестирования Web performance client-side знаете? 61. Какова разница между методами GET и POST? 62. Какая разница между методами PUT и PATCH? 63. Какие знаете сниферы? 64. Какова разница между DROP и TRUNCATE? 65. Что такое case function? 66. Что такое collation? 67. Что такое схема GraphQL? 68. Объясните разницу между OLTP и OLAP. 69. Вспомните разные типы репликации в SQL Server? 70. Что вы понимаете под Self Join? Приведите примеры. 71. Что такое cursor и как им пользоваться?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java, SQL Базовый.   Mobile 72. Что основное нужно проверить при тестировании мобильного приложения? 73. Что такое Manifest.xml в .apk файле и какие данные там указывают? 74. Что такое режим разработчика Do not keep activities? 75. Как происходит перехват трафика http/https для мобильных устройств? 76. В каком виде хранятся данные в мобильных приложениях локально? 77. Как тестировать миграцию локальных данных? 78. Каковы основные компоненты Android-приложений (активити / фрагмент / сервис / интент-фильтр)? 79. Опишите жизненный цикл активити. 80. Что такое утечки памяти? Как найти? 81. Как протестировать билд на Android? 82. Что такое Testflight? Как тестировать с его помощью? 83. Как работает Android? Какая у него архитектура? 84. Как происходит деплой программ IOS/AOS?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 85. Что делать, если разработчик не соглашается, что указанный баг действительно является багом? А если в требованиях использована неоднозначная формулировка? Если бизнес-аналитик, PM и представитель клиента сейчас недоступны, чтобы подсказать? Как можно предотвратить такую ​​ситуацию? 86. Сложилась ситуация, когда команда тестирования не успевает закончить свою работу в дедлайн. Как правильно действовать в этом случае? А если релиз передвинуть нельзя? А если никакие фичи из релиза забрать нельзя? 87. Что делать, если проект уже начался, а QA-инженер там начал работать только когда начали разрабатываться бизнес-фичи? Какие этапы тестирования теперь нужно наверстать и нужно ли это? Как это сделать максимально грамотно без ущерба для загрузки по тестированию новых фич? Какие риски имеет позднее вовлечение QA-инженера в разработку? 88. Веб-страница с полями e-mail, password и кнопкой submit. Назовите отрицательные тест-кейсы, по которым можно проверить эту страницу. 89. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что информация отправлена ​​в базу данных? 90. Как проверить, что данные отправились на сервер, если у нас нет доступа к бэкенду? 91. Приведите примеры улучшений для приведенной веб-страницы (любая на выбор). 92. Составить Smoke Test Suite для DOU.ua. 93. Протестовать функционал банкомата с помощью техники State Transition Diagram. 95. Написать предельные значения для ввода в форму оплаты товара на сайте. 96. Есть метод POST, который регистрирует нового пользователя на сайте, есть тело запроса, содержащее данные о почте, телефоне, имени пользователя и адресе проживания. Какие кейсы для проверки можете привести? 97. На что следует акцентировать внимание при автоматизации методов API? Что следует проверять? 98. Вы тестируете логин-форму, вводите логин и пароль, нажимаете кнопку логин и ничего не происходит. Ваши действия? 99. В течение 5 минут найдите и опишите дефекты, которые вы видите:     100. Вам нужно сделать Regression Testing за два дня. Как вы это сделаете, если Regression Run охватывает 1000 тест-кейсов? 101. Вы тестируете интернет-магазин, который продаёт карандаши. В заказе нужно указать количество карандашей (максимум для заказа – 1000 штук). В зависимости от заказанного количества карандашей отличается цена:   1–100 – 10 грн за шт. 101-200 – 9 грн за шт. 201-300 – 8 грн за шт.   С каждой новой сотней цена уменьшается на 1 гривну. Задание: используя тест-дизайн, опишите все необходимые тест-кейсы, которые будут максимально покрывать описанную функциональность.   102. Есть приложение типа мессенджера, пользователь заходит в чат и отсылает файл (видит сообщение Failed to send...) Когда это может быть баг, а когда нет? 103. Есть веб-приложение интернет-магазина (регистрация, логин, поиск товаров, корзина и покупки). Программу поддерживают следующие браузеры: Chrome, Safari, Edge. У нас есть ограниченное время на тестирование. Расскажите, как вы будете проверять приложение? 104. Напишите автоматические тестовые сценарии для проверки API операций создания и просмотра GitHub Gists. Интегрируйте ваш проект с известной вам CI-системой.   Senior   Теория 1. Как вы преодолеете трудности из-за отсутствия надлежащей документации для тестирования? 2. Какой подход является наилучшим для старта QA в проекте? 3. Какие препятствия могут возникнуть в обеспечении качества для Agile Tester? 4. Что такое Definition of Done? 5. Когда можно считать, что тестирование окончено? 6. Что такое RCA в тестировании? Нужно ли его проводить? 7. Какой подход вы используете для Test Cases Review? 8. Какие виды рисков существуют? Что такое Mitigation Plan? 9. На основе чего нужно составлять стратегию для проведения тестирования нагрузки? 10. Как часто следует ревьюировать тестовую документацию? 11. Как можно быстро сделать выборку необходимых проверок для смоук-тестирования? 12. Как запланировать загруженность команды тестировщиков? 13. Какую ценность несет анализ результатов тестирования команде и проекту в целом? 14. Как можно подкорректировать флоу разработки, чтобы получать более чистые результаты на выходе и уменьшить количество багов на проде? 15. Расскажите о метриках качества, которые вы применяли. Зачем они нужны? 16. Как провести эстимейт задачи? Каковы техники оценки объема тестирования существуют? 17. Как можно посчитать покрытие тестами функционала? 18. Какое оптимальное количество шагов в тестовом сценарии? 19. Как избежать появления регрессивных дефектов? 20. Что такое тестирование со смещением влево (Shift left testing)? 21. Как будете тестировать программу, если для продукта нет документации? 22. В чем смысл юнит-тестов? 23. Какие минусы полной автоматизации тестирования? 24. Что такое ROI и как его считать? 25. Что такое CI/CD? Какие плюсы и минусы этого подхода? 26. TOP OWASP: какие знаете уязвимости и методы защиты? 27. Что вы думаете по поводу BDD? Когда следует использовать, а когда будет только хуже? Если все же следует использовать, то для UI или API автоматизированного тестирования? 28. Что такое сокеты и как их тестировать, вручную и автоматизировано? Зачем их используют? 29. Когда следует делать стресс-тестирование на проектах? От чего отталкиваться, когда строите сценарий для такого тестирования? Что учесть при выборе инструмента? 30. Расскажите об алгоритмах шифрования трафика. 31. Что такое NIC? 32. Для чего нужен протокол RTP? 33. Что, по вашему мнению, лучше – SIP или PRI? 34. Что такое NAT?     Практические задания 35. Сформулируйте негативные сценарии для POST-запроса, который создаёт нового пользователя. 36. Как вы регулируете конфликтные ситуации между QA и разработчиками? 37. Есть проект, на котором нет тестовой документации, но проекту уже год. Мануальным QA не хватает времени на тестирование, они очень устали, есть желание уволиться. Какое решение по команде можно принять? 38. Продайте мне тестирование как клиенту, не желающему его покупать. Кратко и структурированно опишите вашу работу на каждом из этапов разработки ПО, используя профессиональные термины (не лить воду). 39. У вас есть онлайн-калькулятор. Вы вводите 1+1 и получаете 3. Расскажите, как вы будете искать причину проблемы. 40. Могут ли быть такие виды архитектур? Чего может быть недостаточно для правильной работы архитектур, приведенных ниже?   Пример 1     Пример 2     Пример 3     Пример 4   Вопросы при выполнении этого задания:   какие запросы выполняются по форме авторизации? Какой запрос выполняется, когда мы сохраняем данные в базе данных? Можно ли авторизоваться с помощью GET-запроса и нормально ли так делать? Какой код ответа мы получаем при падении ошибки на сервере, код при ошибочных credentials на форме авторизации? Можно ли заменить SSL-сертификат шифрованием данных в пакете от клиента к серверу для протокола HTTP или это будет равноценной заменой?   41. Есть веб-страница с полями e-mail, password и кнопкой submit. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что данные отправлены в базу данных? 42. Какое минимальное количество тест-кейсов необходимо, чтобы убедиться в корректной работе этой веб-страницы? 43. Как проверить безопасность на веб-странице (на выбор)?   Редакция DOU.ua выражает благодарность за вопросы и рецензию: Роману Поботину, Андрею Заблоцкому, Виктору Максименко, Марьяне Батюк, Ирине Литвин, Сергею Могилевскому, Святославу Логину, Роману Маринскому, Олегу Заревичу, Олесе Паславской, Тарасу Лирке, Максиму Богуну, Вадиму Гуличу, Виталию Кашубе, Юрию Суравскому, Светлане Франковой, Владимиру Арутину, Станиславу Жупинасу, Людмиле Федчук, Иванне Черухе, Юлии Левченко, Владиславу Куличенко, Юрию Бояру.