По суті, SDLC - це деякий цикл, в якому кожен етап впливає на дії, що будуть виконані у всіх наступних етапах, таким чином направляючи розробку у правильне русло.

Отже, існує кілька моделей цього циклу, деякі менш популярні, деякі - найбільш. Зараз коротко пройдемося по ним.

Waterfall

Завжди починають саме з неї, бо ця модель є найпершою структурованою.

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

Плюси моделі Водоспаду такі:

• Проста як двері. Її дуже просто пояснити клієнту і користувачам.
• Оскільки не виконавши попередній етап, не можна перейти до наступного, перед початком нового етапу завжди створюється досить непогана документація.
• Команда зфокусована лише на одному етапі одночасно.

Але, мінуси все ж переважають:

• Не передбачає повернення до попередніх етапів, тобто, після зміни вимог вже під час розробки модель просто ламається.
• Передбачена лише для маленьких і "одноразових" проектів, де розробка робиться лише once and forever.
• Не передбачає жодних прототипів на старті - працюючий продукт виходить лише ближче до кінця процесу.
• Якщо при розробці виявили проблеми, їх можна починати фіксити лише на наступному етапі - Testing.

Висновок. Модель рекомендується лише для маленьких короткотривалих проектів без ризиків зміни вимог після їх визначення.

V-Model

Ця лінійна модель (ще називають Verification and Validation Model) є невеликим розширенням Водоспаду: для кожного етапу до кодування передбачається окремий етап дизайну відповідних тестів:

Таким чином, вже одразу після етапів збору вимог, дизайну системи, архітектурного дизайну ми робимо дизайн відповідних тестів: User Acceptance tests, Functional tests, Integration tests і Unit tests відповідно.

В принципі, переваги і недоліки у V-Model такі ж, як і у Водоспада. Також рекомендується використовувати лише для маленьких і "зрозумілих" проектів.

Ітеративна модель

Ця модель вже дещо популярніша від попередніх, дехто навіть може використовувати її сьогодні.

Суть моделі полягає у тому, щоб розбити розробку продукту на ітерації, кроки в яких - однакові:

Таким чином, Ітеративна модель дещо нагадує Agile: планування, робота з вимогами, розробка і тестування є складовими кожної ітерації. Головним є те, що етапи можуть виконуватись одночасно, як-от розробка тест-кейсів і кодування, а також можливе повернення до попереднього етапу.

Отже, плюси такі:

• Для початку роботи не вимагається наявність всіх вимог до продукту.
• Досить швидко зʼявляється прототип.
• Тестування і відладка в маленьких ітераціях набагато легші.
• Модель підтримує зміну вимог.
• Можемо виміряти прогрес.
• Підходить для великих проектів.
• Дозволяє засетапити кілька команд для паралельної розробки.

І мінуси:

• Треба більше ресурсів, щоб правильно керувати процесом при переході між ітераціями.
• Оскільки потребує багато ресурсів, не підходить для малих проектів.

Спіральна модель

Спіральна модель - це покращена Ітеративна модель. Ця методологія поєднує у собі ітеративний підхід з лінійним Водоспадом - для оцінки ризиків, що підходить для дуже великих і ризикових продуктів. По суті, модель поділяється на спіралі (ітерації), які у свою чергу поділяються на фази.

Отже, модель має 4 фази:

1. Identification. Саме з цієї фази починається кожна спіраль. Включає збір вимог до продукту, а також багато комунікації, метою якої є повна зрозумілість вимог всім сторонам. У другій і наступних спіралях включає збір вимог для систем, підсистем, модулів і т.д.
2. Design. На першій спіралі у цій фазі створюється концептуальний дизайн продукту. На наступних спіралях - архітектурний дизайн, дизайн підсистем, модулів і т.д.
3. Construction. У цій фазі проводиться розробка і тестування продукту. На першій спіралі ж розробляється POC (Proof of Concept).
4. Evaluation. І нарешті - оцінка зробленого самим замовником, що включає також оцінку ризиків - як саме варто продовжувати розробку, чи взагалі варто, що треба врахувати у майбутньому і т.д.

Ключовими відмінностями від Ітеративної моделі є те, що у Спіральній неможливо повернутися до попереднього етапу, коли наступний уже почався, а також те, що тестування у спіральній моделі виконується лише після кодування. Коротше, запозичення з Водоспаду.

Agile

І, нарешті, найсучасніша методологія - Agile. Хоча, насправді, Agile - це набір практик, який успадковують його фреймворки: Scrum, Kanban, XP...

Тож у чому переваги Agile? Ну, скажімо, це найбільш оптимальний підхід до розробки програмних продуктів, який фокусується на унікальності кожного окремого продукту. Так, Agile знову ж пропонує поділити розробку на ітерації, але тут вони зазвичай дуже короткі: від одного до трьох тижнів. Після кожної ітерації виходить робочий продукт, і проводиться демо для стейкхолдерів.

Роком народження Agile вважають 2001, коли у мережі опублікували так-званий The Agile Manifesto, хоча його імплементації зʼявились раніше. Цей маніфест каже, що треба більше цінувати:

• Людей, а не процеси: в Agile самоорганізація і взаємодія є важливими.
• Працюючий продукт, а не гарну документацію. Тут мається на увазі, що найкращий спосіб комунікації між клієнтом і розробниками - демо, а не текст. Технічну документацію ніхто не відміняє!
• Співпрацю з клієнтом, а не роботу над контрактом: клієнт має бути постійно залученим у процес розробки для узгодження і коригування вимог.
• Реагування на зміни, а не дотримання плану: запити на зміни мають бути почутими і швидко задоволеними.

Також Agile вводить такі ролі:

• Product Owner (ще називають "голос клієнта") - є "власником" вимог до продукту і відповідальною за їх узгодження і валідацію особою. Постійно комунікує з командою розробки, працюючи над так-званими User Stories - тасками з точки зору бізнесу.
• Scrum Master - це по суті роль менеджера, який наглядає за проектом і перевіряє, чи всі Agile принципи, процеси і цінності дотримуються командою розробки.
• Team Member - всі інші члени команди, як-от девелопер, куа, бізнес аналітик, дизайнер і т.д.

Отож, як я вже сказав, Agile - то лише звід практик, а моделями SDLC є саме фреймворки Agile: Scrum, Kanban, Extreme Programming... І проект може як обирати між цими фреймворками, так і комбінувати їх. Звісно ж, всі ці моделі створені саме для великих і довгих (навіть нескінченних) проектів, де точні вимоги до фінального продукту формуються досить довго.

Scrum

Scrum - це один з найвідоміших фреймворків Agile.

По суті, все те ж саме, що і диктує Agile, але конкретніше. За Скрамом, ітерації поділяються на такі етапи:

• Planning: визначаються пріоритети спринта і формується скоуп тасок на цей спринт.
• Daily standup: всім нам знайомий дейлік, де кожен має відповісти на питання "що робили вчора", "що будете робити сьогодні" і "які є блокери".
• Demo meeting: демо з кастомером, на якому демонструється робота, зроблена за спринт, і кастомер ділиться фідбеком.
• Retrospective meeting: є багато форматів, але в загальному тут команда підводить підсумки спринта і кожен має можливість поділитись тим, що йому сподобалось і не сподобалось протягом роботи над цим спринтом, щоб у наступному спринті це покращити.

Варто також зазначити, що ще є Grooming meeting (ще називають Backlog Grooming) - це такий мітинг, де команда проходиться по якійсь частині беклогу, оцінюючи сторі, а також намагаючись максимально продумати (прогрумити) їх, позбавившись будь-яких неточностей чи незрозумілостей.

Kanban

Також дуже популярний фреймворк Agile, який часто напряму порівнюють зі Скрамом.

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

До речі, Канбан вийшов з компанії Toyota, а сам цей термін з японської перекладається як "вивіска з лого компанії".

Саме Канбан завжди асоціюється з цими дошками з колонками, що відповідають статусу тікетів, які рухаються з колонки до колонки. Така модель ідеально підходить проектам, де непросто оцінити складність тікетів і, відповідно, проестімейтити їх у сторіпоінтах - як на моєму проекті раніше: коли два однакових тікети можуть важити як 2 сторіпоінти, так і 20.

Extreme Programming (XP)

Цю методологію я ще не зустрічав на реальних проектах, але багато чув про неї.

По суті, модель фокусується на кількох речах:

• Парне програмування: вся девелопмент робота виконується у парах, як кажуть "один - driver, інший - navigator". Передбачається, що якщо писати код у парі, багів буде значно менше, а процес код ревью взагалі не потрібен. Також обовʼязково має бути зміна ролей у процесі розробки (ну тобто спочатку один пише код а інший "навігує", через деякий час ролі змінюються).
• Тести: весь код має бути покритий надійними юніт- і функціональними тестами, щоб ще більше зменшити імовірність появи багів, а також забезпечити можливість перевикористання коду.
• Комунікація: знову ж, посилена комунікація між членами команди і стейкхолдерами, ледь не до сумісного написання коду.

У цієї методології також є свій офіційний сайт, де можна почитати про неї детальніше.

Висновки

Software Development Life Cycle - цикл розробки ПЗ, який потрібен бізнесу для планування і керування процесом розробки, а також для оцінки продуктивності і ризиків. Етапи SDLC найчастіше включають збір і валідацію вимог, планування, дизайн, кодування, тестування і підтримку (або deployment).

Існує багато моделей (методологій) SDLC, найбільш відомі з яких: Waterfall, V-модель, Ітеративна, Спіральна, а також Agile.

Waterfal - найперша структурована лінійна модель SDLC, яка передбачає те, що кожен наступний етап розробки може початись лише після закінчення попереднього. Підходить лише для маленьких проектів, де одразу є зібрані вимоги, що всім очевидні і не будуть змінюватись впродовж розробки.

V-модель - невелике покращення Водоспаду, яке полягає у тому, що розробка тест-кейсів відбувається одразу ж після відповідних етапів: User-Acceptance, Functional, Integrational, Unit.

Ітеративна модель - принципово нова модель, яка вводить поділ процесу розробки на ітерації, які складаються з однакових етапів. При цьому є можливість повертатися до попередніх етапів у разі необхідності. Це дає можливість застосувати модель для сучасних і довготривалих проектів, де повні вимоги до початку проекту ще не відомі і можуть змінюватись.

Спіральна модель - це комбінація Водоспаду і Ітеративної моделі, яка допомагає краще оцінювати ризики. Розробка також ділиться на ітерації (спіралі), які у свою чергу діляться на фази. Головна відмінність від Ітеративної моделі - не можна переходити до попереднього етапу після його закінчення. Також, тестування виконується лише після кодування.

Agile - звід практик для моделей SDLC, який створений з урахуванням того, що кожен проект унікальний. Передбачає поділ розробки на ітерації (зазвичай з фіксованою тривалістю). Agile передбачає, що: люди і самоорганізація є важливішими за процеси; жива комунікація між командою і клієнтом краща, ніж письмова документація; зміни і побажання клієнта мають бути швидко враховані і реалізовані.

Scrum - фреймворк Agile, який передбачає спринти - ітерації тривалістю у кілька тижнів, демо як комунікацію між клієнтом і командою і можливість продемонструвати виконану роботу, а також ретроспективи - зустрічі для виявлення проблем, що мали місце протягом останнього спринта.

Kanban - фреймворк Agile, що на відміну від Scrum, не має естімейшина тасок у сторіпоінтах і не передбачає фіксованих за часом ітерацій. Kanban фокусується на статусах тікетів і їх менеджменті через славетну Kanban-дошку.

Extreme Programming - фреймворк Agile, що фокусується на парному програмуванні і якісних тестах.

Джерела

https://www.tutorialspoint.com/sdlc/index.htm

https://www.roberthalf.com/blog/salaries-and-skills/6-basic-sdlc-methodologies-which-one-is-best

https://www.virtasant.com/blog/sdlc-methodologies

https://www.javatpoint.com/software-engineering-software-development-life-cycle

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

Тож давайте розглянемо тут ці принципи, щоб потім можна було флексити на співбесідах.

KISS

Принцип KISS розшифровується як Keep it Simple, Stupid,проте інколи його вживають або просто як Keep it Simple (щоб не називати людей stupid), або ж Keep it Short and Simple.

Офіційне формулювання:

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

По суті, так, якщо вас спитають про цей принцип, достатньо сказати, що прості системи працюють краще і надійніше, ніж складні. Тепер давайте поговоримо про інші трактування і applications цього принципу, в тому числі у фронтенді.

1. Не треба для якоїсь маленької фічі додавати у проект цілу велику бібліотеку. Надзвичайно розповсюджено зараз, особливо на фронті - як-от з бібліотекою moment.js. Нам треба одну дату в проекті відформатувати, а ми додаємо цілу бібліотеку, тим самим додаючи цілу одну залежність, збільшуючи розмір бандлу, збільшуючи кількість потенційних вразливостей у проекті і так далі.

2. (перетинається з YAGNI). Не варто перевантажувати інтерфейс - надмірно розбивати один метод на купу інших, виносити певний хардкод в конфігураційні файли, додавати можливість налаштування чомусь простому...
Приклад. Є у нас бекенд, який запускається на строго визначеному порті (ну максимум додали можливість задавати порт у конфіг-файлі). І ми такі "ну блін, це ж не зовсім зручно, давайте напишемо логіку для автоматичного знаходження першого вільного порта і будемо біндитись туди, це ж краще". Ну зробили так. А потім адміни голову ламають, як наш бекенд порт вибирає собі, мають налаштовувати фаєрвол для всіх портів одразу і т.д. По-перше, не варто було так робити - треба було по-простому - конфіг файл і все. По-друге, якби клієнту знадобився такий автовибір порту, він би сам цю логіку на своїй стороні написав.

3. Не потрібно оптимізовувати проект, економлячи кілька наносекунд. Швидш за все, ця оптимізація зробить з коду кашу, і він точно не буде short and simple. До цього ж відноситься і реалізація астрономічної точності математичних розрахунків на неастрономічних проектах.

4. Що більше стрічок коду у проекті, то більше в ньому потенційних багів, тому що кількість багів у проекті прямо пропорційна кількості стрічок коду.

5. Насправді, кожен початківець стикається з результатом "невиконання" цього принципу тоді, коли начитавшись розумної літератури, починає новий проект. Стільки всяких ідей крутиться в голові, треба ж зробити так, щоб у майбутньому було простіше розширяти проект, треба продумати всі моменти... Так, якщо цього не зробити, то у вас вийде Фейсбук, технічний борг у якому хрін випилиш. Але якщо упоротись - ви проект так і не закінчите. Тому варто шукати золоту середину.

До речі, цікавий факт: принцип зʼявився у 1960 році в колах ВМС США.

YAGNI

Розшифровується як You Aren't Gonna Need It.

Офіційне формулювання:

Можливості, які не описані у вимогах системи, не повинні бути реалізовані.

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

Ну і знову ж, поговоримо про реальні приклади і застосування цього принципу.

1. Замовник не має оплачувати те, чого він не замовляв. Навіть якщо ви думаєте, що якась штука буде йому корисною, він має про це знати ще до того, як ви почнете її писати, бо, повірте, у майбутньому це гарантовано вилізе боком.

2. Поговоримо про "вилізе боком" з попереднього пункту. Ну от ви написали якусь додаткову логіку "на майбутнє". Потім замовник вам дає завдання написати нову фічу, і ви такі: "блін, вона ж повністю протиречить тій додатковій логіці, що я написав раніше...". І це ще ок, ви просто видалите її. Але ж може бути, що ви написали новий модуль типу "на майбутнє", і вже використали його десь. Так тепер вам ще і попереднє все переписувати, перетестовувати і так далі.

3. Написавши нову штуку, на вас лягає зобовʼязання її підтримувати: писати тести, документацію, підганяти конфігурацію і слідкувати за помилками, пояснювати юзерам, як вашою штукою користуватись, і так далі. Воно вам треба?

4. Якщо проект fixed-price, а ви додали якусь нову штуку, якої не було в ТЗ, замовник з легкістю може почати вами маніпулювати: "ой, а ви ось це зробили, але воно взагалі не так повинно працювати, допишіть будь ласка". Таким чином, ви додали роботи, тобто витратили гроші вашої компанії, і цілком можливо навіть вивели її в мінус, тому варто чекати небажаних гостей.

DRY

Ну тут все просто: Don't Repeat Yourself. Принцип був сформований у відомій книзі "Програміст-прагматик" Ендрю Ханта і Дейва Томаса. Насправді, цей принцип не стільки про дублювання коду (бо про це і так каже майже будь-який інший принцип), скільки про єдине джерело даних (Single Source of Truth).

Офіційне формулювання:

Будь-яка інформація повинна мати єдине, однозначне і авторитетне представлення в системі.

Безліч разів бачив, що дані в додатку дублюються просто для того, щоб було "простіше працювати", типу дані однакові, але зберігаються в різних форматах. Я теж коли писав свої проекти, думав: "блін, нашо мені кожен раз конвертувати цю стрічку в мій формат, якщо можна просто в таблиці поруч нове поле зробити і туди це все класти". Насправді, нове поле поруч з оригінальним - це ще не страшно, бо його видно. А ось коли у нас одні і ті самі дані в різних таблицях - це вже страшно. Та, насправді, навіть коли вони поруч, дуже просто забути продублювати операції для роботи з ними. У будь-якому разі, рано чи пізно ці дані розсинхронізуються, і стане погано.

Так, принцип також застосовують до коду, але я хотів би тут перерахувати ті виключення, при яких цей принцип можна і треба не виконувати.

Ну ось наприклад ви пишете фронт і бек - валідація. Її просто обовʼязково дублювати, це загальновідоме правило і без цього ніяк не можна, бо інакше ви або змушуєте клієнт і сервер страждати від величезної кількості запитів (якщо валідувати тільки на бекенді), або ж порушуєте найпростіші принципи компʼютерної безпеки (валідуючи лише на фронті).

Також як чудовий приклад виключення з принципу DRY можна назвати компʼютерні ігри. Зазвичай у онлайн-іграх деякий код дублюють і на клієнті, і на сервері, заради оптимізації. Адже без такої оптимізації навіть гравці з відносно непоганим пінгом бачили б слайдшоу замість плавного руху персонажів, до прикладу (ну типу клієнт сам обраховує приблизні вектори руху персонажів і рухає їх, поки достовірна інформація йде з сервера, і виходить імітація відсутності затримок).

Висновки

KISS (Keep It Simple, Stupid): більшість систем працюють краще, якщо вони залишаються простими, а не ускладнюються. Суть: треба писати по-дубовому, не створювати мільйон абстракцій і конфігурацій. Також не варто лише задля маленької фічі запихати в проект величезну бібліотеку.

YAGNI (You Aren't Gonna Need It): можливості, які не описані у вимогах системи, не повинні бути реалізовані. Суть: не варто реалізовувати те, що ви думаєте, полегшить роботу або знадобиться у майбутньому.

DRY (Don't Repeat Yourself): будь-яка інформація повинна мати єдине, однозначне і авторитетне представлення в системі. Суть: не допускайте ситуацій, коли ви зберігаєте одні і ті ж дані (просто в різних формах) у різних місцях в системі.

Джерела

Коротко про KISS, YAGNI і DRY на Хабрі: https://habr.com/ru/company/itelma/blog/546372/

KISS by Sergey Nemchinskiy: https://www.youtube.com/watch?v=rix-fkrloq4

YAGNI by Sergey Nemchinskiy: https://www.youtube.com/watch?v=Ot2eB07rjcI

DRY by Sergey Nemchinskiy: https://www.youtube.com/watch?v=NWemqNMCesQ

Спочатку трохи історії. Роберт Мартін, відомий автор книжок про обʼєктно-орієнтоване програмування, все своє життя збирав (і сам виводив) деякі принципи, що використовуючи їх у розробці програмного забезпечення, можна було зробити його краще з точки зору коду і архітектури. А потім просто деякий Michael Feathers помітив, що назви "загальних" принципів Мартіна складаються в акронім - SOLID. Так вони і стали відомими.

Тож, що ж це за "загальні" принципи:

1. S - SRP - Single Responsibility Principle
2. O - OCP - Open-Closed Principle
3. L - LSP - Liskov Substitution Principle
4. I - ISP - Interface Segregation Principle
5. D - DIP - Dependency Inversion Principle

Single Responsibility Principle

На мою думку, найпростіший принцип серед усіх. Ми так чи інакше майже завжди його використовуємо на підсвідомому рівні.

Формулювання Роберта Мартіна:

Кожний обʼєкт повинен мати одну відповідальність і ця відповідальність повинна бути повністю інкапсульована у класі.

Щоб зрозуміти цей принцип, треба зайти з іншого боку. У будь-якого програмного забезпечення є така штука, як вісь змін. Це той набір класів, методів/функцій, полів, які постійно змінюються. Ну, тобто, щось таке:

Часто кажуть "вісь змін проходить через ось ці класи".

Звісно, осей змін може бути кілька у великій системі. Наприклад: одна вісь змін - бізнес логіка, а друга - робота з базою даних.

Так ось за принципом SRP через ваш клас має проходити лише одна вісь змін, тобто ваш клас повинен змінюватись лише з однієї причини, що можливо тільки тоді, коли він виконує одну функцію - відповідальний тільки за одну річ.

Також, якщо ви, наприклад, за бажанням клієнта змінили в коді одну маленьку штуку, а потім виявилось, що це вплинуло на якийсь взагалі лівий модуль в додатку, і все зламалось - це і є порушення SRP.

Приклад

Припустимо, ви пишете софт для компанії, яка робить побутову техніку, і ваш перший продукт - духова шафа. Перша задача - навчити духову шафу тримати температуру якийсь заданий час. У вас є годинник і термометр - треба для них код написати, щоб їх використовувати в програмах для приготування їжі. І ви такий "напишу я клас DateTimeTemperature, який буде все робити". Написали величенький клас, який увійшов до кодової бази компанії, і в основу духової шафи. А потом пішли на іншу роботу, бо там більшу зарплату запропонували.

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

Все йде добре, але раптом у коді духових шаф знайшли баги. Запросили команду тестувальників, як Atlassian задумались раптом про доступність. Протестували клас DateTimeTemperature - купу багів знайшли. Пофіксили. Але ж у чайниках і витяжках той самий код, та от лежить він хрін знає де. Ось так і вийшло, що в одному і тому ж коді купа багів, але в одному місці їх пофіксили, а в іншому - ні.

Висновок: треба було зробити два окремих класи - DateTime і Temperature. Вони б увійшли до єдиної стандартної бібліотеки компанії і їх би всі використовували. А ще кожен з цих класів мав би одну відповідальність.

Цікаві факти

Є такий патерн - Active Record. Це коли у класі окрім бізнес-логіки лежить ще і код для роботи з базою даних - записати себе, знайти себе і т.д. Хоч цей патерн і повністю порушує SRP, його часто використовують. Наприклад, ruby on rails повністю побудований на Active Record. Laravel і Yii - PHP фреймворки - теж його використовують. C# так само колись був побудований на Active Record, але скоро все ж перейшов на ORM.

Open-Closed Principle

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

Формулювання (не Роберта Мартіна, а декого Бертрана Меєра):

Програмні сутності - класи, функції, модулі і т.д. - повинні бути відкриті для розширення і закриті для змін.

Почнемо з того, як це можливо взагалі? А все дуже просто. Якщо є нормальний програмний продукт, який протестований, якщо він нормально спроектований – додавання нової функціональності не повинно валити існуючі тести та додавати нові баги (це ж треба буде повне регресійне тестування проводити, якщо так).

Як Бертран Мейер пропонує це реалізовувати? Припустимо ми написали клас. Коли закінчили, вішаємо на нього умовний "замочок", який забороняє нам змінювати його (звісно ж крім багфіксів). І все. Якщо хочемо розширити клас, додати нову функціональність – використовуємо наслідування. При цьому дозволяється у новому класі змінювати попередній інтерфейс.

Остання штука звучить тупо, адже викликає сайд-ефекти у клієнтських класів - їх також доведеться переписувати. Саме тому вже Роберт Мартін запропонував "поліморфний" Open-Closed принцип.

Поліморфний Open-Closed принцип забороняє змінювати інтерфейс. Тобто клієнтський код повинен спілкуватися з реалізацією лише через інтерфейс (який незмінний), а цей інтерфейс вже повинен реалізовуватись старою та новою реалізаціями. При цьому нова реалізація може або делегувати старій виконання якихось шматків коду, або наслідуватись від неї.

Оскільки поліморфний принцип більш логічний, у сучасній розробці використовують саме його.

На завершення скажу, що цей принцип у сучасних реаліях перетинається з Dependency Inversion, тому що найчастіше передбачає використання класів через відповідні інтерфейси, оскільки за допомогою цього досить просто розширювати функціональність класів, до прикладу, завдяки патернам Decorator або Proxy. Візьмемо, наприклад, клієнт і сервер. Додавши серверу інтерфейс (або абстракцію), до якого звертатиметься клієнт, ми спокійно між інтерфейсом та класом можемо додати аутентифікацію, авторизацію, логування, кешування тощо.

Використання у фронтенді

Далеко не у кожному проекті є тайпскрипт, проте цей принцип має застосування і у звичайному JS. Припустимо, ми робимо компонент кнопки - проста така кнопка з іконкою всередині. Без питань зробили, юзаємо. Через деякий час треба робити нові кнопки вже з іконкою і текстом. Ну не проблема - допишемо вже існуючий компонент і додамо необовʼязковий текст. Ще через місяць прилітає таска: зробити кнопки з бейджом непрочитаних повідомлень (як на айфонах). Та все просто - додамо бейдж до вже існуючої кнопки. І так можна продовжувати ще довго.

Уважний розробник (а тестувальник тим більше) скаже, що після кожної такої зміни компоненту у ньому можуть зʼявитись баги, і необхідно його (і всі місця, де він використовується) перетестовувати. А якщо, припустимо, ми передамо у цю кнопку лише текст з бейджом, то вийде взагалі якась фігня. Саме тому перед кожною такою зміною варто подумати, чи не краще було б створити новий компонент. Так нам не треба буде їх постійно перетестовувати, та й імовірність зловити нові баги значно зменшиться. Звісно, назви компонентів будуть трохи довші (як-от IconButtonWithTextAndBadge), але на мою думку це інколи навіть краще.

Приклад від себе

Ось я працюю над accessibility фіксом для одного маленького дропдауну в Джирі на одній сторінці. Я не можу просто зробити по-нормальному те що мені треба, бо:

- сто пудів впадуть тести;

- якщо впали тести, значить зламалась поточна поведінка;

- якщо зламалась поточна поведінка, то є висока імовірність, що зʼявились нові баги.

А тепер уявіть, що цей дропдаун використовується ще в якійсь жопі, про яку ми і гадки не маємо. А якщо у компонента немає тестів/сторібуку, то ми про це взагалі ніколи не дізнаємось! (ну, хіба що лише тоді, коли нам прилетить по дупі за наші "фікси"). Саме тому працюючи над кожним таким фіксом, моя задача - зробити його максимально сумісним зі старою поведінкою так, щоб впала мінімальна кількість тестів. Тож я намагаюсь реалізувати цей фікс максимально не змінюючи попередній код, а лише дописуючи нове (за можливості). Звісно, ідеальним рішенням було б зробити новий дропдаун на основі старого, вже з фіксами, і використати саме його у тому місці, яке зарепорчено в тасці - так ми і інтерфейс зберігаємо, і зводимо імовірність появи багів у інших місцях до мінімуму.

Liskov Substitution Principle

Насправді досить простий принцип. Взятий у Барбари Лісков, але формулювання використовують Мартіна (а все тому, що Лісков - математикиня).

Формулювання Роберта Мартіна:

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

Тобто, поведінка базового класу не повинна протиречити поведінці нащадків.

Приклад

Стандартний приклад - класи Rectangle і Square:

class Rectangle {
  width: number
  height: number

  constructor(width: number, height: number) {
    this.width = width
    this.height = height
  }

  setWidth(width: number) {
    this.width = width
  }

  setHeight(height: number) {
    this.height = height
  }

  areaOf(): number {
    return this.width * this.height
  }
}

class Square extends Rectangle {
  width: number
  height: number

  constructor(size: number) {
    super(size, size)
  }

  setWidth(width: number) {
    this.width = width
    this.height = width
  }

  setHeight(height: number) {
    this.width = height
    this.height = height
  }
}

const square: Square

square.setWidth(20) // змінює ширину і висоту, все правильно
square.setHeight(40) // теж змінює ширину і высоту, ок

Але якщо ми, наприклад, почнемо писати тести...

function testShapeSize(figure: Rectangle) {
  figure.setWidth(10)
  figure.setHeight(20)
  assert(figure.areaOf() === 200)
  // умова не зпрацює, якщо figure — екземпляр класу Square
}

Математично, так, квадрат - це прямоукутник, але він поводить себе інакше!

Таким чином, Liskov Substitution Principle пропонує використання композиції замість наслідування. А якщо і наслідування, то класи-нащадки не мають протиречити базовому класу, наприклад - надавати інтерфейс вужче базового.

Ще один приклад: класи DB і MockDB. При реалізації моку для тестів, імовірно, клас буде наслідуватись від DB і реалізовувати тільки методи, необхідні для тестів, а інші - кидати NotImplementedException. Якщо прийде інший розробник і вирішить написати свої тести з використанням цього ж моку, він з великою імовірністю отримає цей NotImplementedException. Таким чином, тут клас-нащадок надає інтерфейс вужче базового.

Ще одне формулювання від розумних дядьків:

Підклас не має вимагати від викликаючого його коду більше, ніж базовий клас, і надавати менше, ніж базовий клас.

В даному випадку "вимагати більше" - це наприклад перед викликом методів робити якусь ініціалізацію. А "надавати менше" - замість очікуваного обʼєкту повертати null.

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

Interface Segregation Principle

Доволі простий принцип, якщо ви працюєте зі строго-типізованою мовою.

Формулювання Роберта Мартіна:

Клієнти не мають залежати від методів, які вони не використовують.

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

Приклад

Спочатку - стандартний приклад. Є у нас сайт з оренди нерухомості, фронт на тайпскрипті, і ми пишемо типи юзерів. У нас будуть:

• Звичайні юзери: можуть оформлювати оренду, ставити рейтинг орендодавцю і писати коменти;
• Орендодавці: можуть робити все те ж, що і звичайні юзери, плюс додавати нові оголошення;
• Адміни: можуть робити все вищезазначене, а також видаляти коменти і банити інших юзерів.

Припустимо, що буде у нас масив з юзерами усіх видів. І ми такі бахаємо великий інтерфейс:

interface User {
    id: number,
    role: Role,
    nickname: string;
    rentApartment(apartmentId: number): void,
    setRating(apartmentId: number, rating: number): void,
    addComment(apartmentId, number, comment: string): void,
    addApartment(title: string, description: string, photo: string): void,
    removeApartment(apartmentId: number): void,
    removeComment(commentId: number): void,
    banUser(userId: number): void
}

Ну а потім починається:

• Нашо всім юзерам метод бану, якщо ніхто, крім адміна, цього зробити не може?
• Як тоді визначати такі методи? Опшинал?

і так далі. Правильніше зробити три інтерфейси: IUser, ILandlord і IAdmin, при цьому IUser навіть можна зробити базовим - і всі питання одразу ж відпадуть.

Приклад №2

Більш показовим прикладом є фасад класу для роботи з БДшкою. У ньому зазвичай є абсолютно всі методи: від пошуку до операцій CRUDу. Ну ми ж гарні розробники, думаємо "забахаємо інтерфейс до цього фасаду, треба ж, щоб все через інтерфейси спілкувалось" і бахнули один інтерфейс для всіх методів фасаду. Настав час писати клієнтів: один використовує тільки один метод пошуку, інший використовує якийсь складніший пошук, а третій взагалі лише операції CRUDу. І всі працюють через наш інтерфейс.

Припустимо, що інтерфейс трішки змінився, сигнатуру якогось там 340го методу змінили. І що? Правильно, після цього треба перекомпільовувати весь проект, хоча жоден з клієнтів навіть не використовує цей метод.

Звісно, найгірше стається тоді, коли цей фасад БДшки змінюється на щось інше, наприклад - два менші фасади по 4 методи. Якби для кожного клієнта під його потреби був маленький інтерфейс - ми б швидко все поправили. А так, з одним інтерфейсом - переписуй все.

Приклад №3

Цей приклад більше про фронтенд. От ми юзаємо якусь бібліотеку для графіків (нехай буде HighCharts). Використали з неї лише PieChart та і все. Через пару місяців вирішили оновити депенденсі на проекти, перед цим почитавши чейнджлог (у якому не знайшли речей, що стосуються PieChart'ів). Оновили - і все впало.

У цьому випадку інтерфейсом ми вважаємо те, як бібліотека експортує свої складові і розділяє їх. Припустимо, HighCharts ми в проект включаємо повністю, використовуючи лише PieChart - ось і проблема.

Щоб пофіксити це, гарно було б розділити бібліотеку на різні модулі (плагіни): Highcharts (загальний), TableChart, PieChart, DataParsing etc. Таким чином, при оновленні лише PieChart'у, ми б майже гарантовано не отримали жодних проблем.

Гарно реалізована з цієї точки зору бібліотека i18next. Вона поділена на плагіни, і кожний може підключатись до проекту окремо:

import i18next from 'i18next';
import Backend from 'i18next-http-backend';
import Cache from 'i18next-localstorage-cache';
import PostProcessor from 'i18next-sprintf-postprocessor';
import LanguageDetector from 'i18next-browser-languagedetector';

i18next
    .use(Backend)
    .use(Cache)
    .use(LanguageDetector)
    .use(PostProcessor);

Цей підхід також дозволяє:

• Окремо тестувати модулі розробникам бібліотеки;
• Не включати до проекту зайвого і економити розмір бандлу;
• Винести розробникам ці модулі в різні репозиторії і працювати над ними окремо.

Всі ми знаємо приклад, що суперечить принципу розділення інтерфейсів - бібліотека moment.js. Вона настільки розрослась, що використовувати і сапортити її стало проблематично, тож багато проектів перейшло на аналоги, а її розробники оголосили про закінчення підтримки.

Примітка

Варто зазначити, що інтерфейси практично завжди потрібні клієнтам, а не тому, хто надає сервіс - саме клієнти найкраще знають, що їм потрібно. Тому і створюючи інтерфейс, треба думати як клієнт, або навіть краще спитати, що клієнту треба - як у випадку з апішкою між фронтендом і бекендом.

Dependency Inversion Principle

Найскладніший особисто для мене принцип.

Формулювання:

Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Всі модулі повинні залежати від абстракцій.
Абстракції не повинні залежати від деталей реалізації. Деталі реалізації повинні залежати від абстракцій.

Деякі розробники просто описують цей принцип як "використовуйте всі класи через інтерфейси", щоб уникнути купи проблем у майбутньому, як ось тут:

interface ILogger { 
    write(message: string): void; 
} 

class FileLogger implements ILogger { 
    write(message: string): void { 
        // write to file 
    }
} 

class StandardOutLogger implements ILogger { 
    write(message: string): void { 
        // write to standard out 
    }
}

function doStuff(logger: ILogger): void { 
    logger.write("some message") 
}

Проте це не зовсім повне трактування, і далі я хотів би його розширити.

По-перше: що таке модулі вищого і нижчого рівня? Нижчий рівень - це ті загальні допоміжні модулі, які використовуються у більш конкретному коді. Як приклад можна навести будь-яку зовнішню бібліотеку, власний сервіс/модуль для роботи з чимось, типу локал стореджа, або навіть якийсь сервіс, що ми використовуємо через його АПІшку. Модулі вищого рівня мають цей код як свою депенденсі. Надалі будемо розглядати саме приклад для роботи зі стореджом.

Для чого потрібний цей принцип? Ну використовуємо ми, наприклад, локал сторедж по всьому коду, то й що? Ну, наприклад, даних стане настільки багато, що ми впремося у 5 мегабайт. Або треба зберігати картинки. Або взагалі сказали перевикористати код в нативній аплікушці, де локал стореджу просто не існує. Та це ще дрібниці - що як треба зробити мок цієї депенденсі для тестів? Всі такі зміни виливаються у купу змін в коді, через що він гарантовано десь зламається, та і ми задовбемось все переписувати.

Але ж як зробити так, щоб не наш код залежав від бібліотеки, а бібліотека залежала від нашого коду? Ну, повернемося до другої частини першого твердження: всі модулі мають залежати від абстракцій. Окей, зробимо абстракцію над функціями роботи з локал стореджем (або бібліотекою), і будемо залежати вже від неї. Це вже покращить наше становище - АПІшка локал стореджу буде використовуватись лише в абстракції, і при її зміні не потрібно буде переписувати півпроекту. Також це запобігає сильному звʼязуванню модулів - high coupling. Проте, саме на цьому багато розробників і зупиняються - робота зроблена - і таке рішення справді підходить для маленьких проектів.

Але ж поки ми виконали лише першу частину першого твердження - абстракція все ще залежить від деталей реалізації і локал сторедж аж ніяк не залежить від абстракції. Тут маємо до абстракції додати клієнтський інтерфейс і адаптер до нього. Наприклад, будемо використовувати сторедж для роботи з АРІ токеном:

interface TokenStorage {
    setToken(token: string): Promise<void>;
    getToken(): Promise<string>;
}

Також маємо таку абстракцію:

let storage;

async function setItem(name, value) {
    if (typeof storage.setItem !== "function") {
        throw "Storage should implement setItem method";
    }
    storage.setItem(name, value);
}

async function getItem(name) {
    if (typeof storage.getItem !== "function") {
        throw "Storage must implement getItem method";
    }
    return storage.getItem(name);
}

function setStorage(instance) {
    storage = instance;
}

export default {
    setStorage,
    getItem,
    setItem
};

і адаптер:

import storage from "../storage";

async function setToken(token: string): Promise<void> {
    storage.setItem("token", token);
}

async function getToken(): Promise<string> {
    return storage.getItem("token");
}

export default {
    setToken,
    getToken
};

Отже, маємо локал сторедж, який вже тепер залежить від створеної абстракції, і надає для неї адаптер. А клієнт має інтерфейс і також залежить від абстракції.

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

Ось тут добре написано про ці адаптери: https://bespoyasov.ru/blog/clean-architecture-on-frontend

Висновки

S - Single Responsibility Principle: програмні сутності мають мати лише одну відповідальність і ця відповідальність має бути інкапсульована в них. Знижує імовірність дублювання коду. Запобігає слабкому звʼязуванню сутностей всередині модулю (low cohesion).

O - Open-Closed Principle: програмні сутності мають бути закриті для змін і відкриті для розширення. В рази зменшує імовірність виникнення нових багів.

L - Liskov Substitution Principle: методи/функції, що використовують базовий тип, повинні мати можливість використання підтипів базового типу, не знаючи про це. Тобто підклас не має вимагати від викликаючого його коду більше, ніж базовий клас, і надавати менше, ніж базовий клас. Позбавляє розробників від неочікуваних результатів роботи.

I - Interface Segregation Principle: клієнти не мають залежати від методів, які вони не використовують. Тобто якщо один інтерфейс реалізують два клієнти, але деякі його методи не використовуються в них, треба розбити інтерфейс на два.

D - Depencency Inversion Principle: модулі вищого рівня не повинні залежати від модулів нижчого рівня - всі модулі повинні залежати від абстракцій;
Абстракції не повинні залежати від деталей реалізації - деталі реалізації повинні залежати від абстракцій. Тобто перед використанням якоїсь залежності нижчого рівня варто принаймні зробити інтерфейс/абстракцію над нею, а краще - ще й адаптер. Запобігає сильному звʼязуванню (high coupling) модулів.

Джерела

SOLID by Sergey Nemchinskiy: https://www.youtube.com/watch?v=O4uhPCEDzSo&list=PLmqFxxywkatQNWLG1IZYUhKoQrnuZHqaK

SOLID in FrontEnd by IT Sin9k: https://www.youtube.com/watch?v=WMO9aarO390&list=PLz_dGYmQRrr8rWKkoB3BtxF7JpCzUKny_

DIP by Web Dev Simplified: https://www.youtube.com/watch?v=9oHY5TllWaU

SOLID by Ostap Chervak & Andrii Zhydkov: https://uncomment.fm/episodes/03_solid

SOLID by StackOverflow: https://stackoverflow.blog/2021/11/01/why-solid-principles-are-still-the-foundation-for-modern-software-architecture/

SOLID book: https://ota-solid.vercel.app/

Event Loop, або ж цикл подій - це те, на чому заснований потік виконання в JS - всього лиш нескінченний цикл, який виконує задачі, що до нього приходять.

Перед тим, як приступити до будь-яких черг, треба класифікувати задачі, які потрапляють до Event Loop. Отже, є три типи задач:

• Macrotask (макрозадача) - також називають просто Task;
• Microtask (мікрозадача);
• Render Task.

А тепер детальніше:

• Макротаски - це синхронний код, підвантаження тегів<script>, обробка подій, а також частина Browser API: setInterval, setTimeout (точніше, функції, що в них передаються)... До цього типу задач відносяться майже всі, тому якщо сумніваємось - вважаємо, що це макрозадача.
• Мікротаски - в основному проміси, а точніше функції, які виконуються в then, catch, finally, а також з використанням await, тому що це теж обробка проміса.
• Задачі рендера - все, що стосується рендеру сторінки: Style Recalculate, Layout, Paint...

Для кожного з цих 3 типів задач існує своя черга: Macrotasks queue, Microtasks queue та Render queue. Завдання в ці черги потрапляють відразу ж, як вони зустрічаються в коді (ну чи в коді іншого файлу - коли ми курсор пересунули, наприклад), але це в жодному разі не означає, що вони виконуються миттєво. Ці черги якраз створені, щоб імітувати багатопоковість.

Тепер можемо подивитись на схему:

Як бачимо, є 3 різні черги і один нескінченний цикл, до якого потрапляють задачі з цих черг. А Event Loop власне просто перекидає в Call Stack те, що потрапляє до нього.

Виходить, вся багатопотоковість тут у тому, щоб правильно розставити пріоритети задач у Event Loop'і. Це зараз і розглянемо.

Але спочатку фрагмент коду. В якому порядку стрічки будуть виведені в консоль?

setTimeout(() => console.log("timeout"), 0);

Promise.resolve().then(() => console.log("promise"));

console.log("code");

Цю задачу дуже люблять давати на співбесідах. Поки ви думаєте, розпишу загальний алгоритм роботи Event Loop'а:

1. Виконуємо одну макротаску;
2. Виконуємо послідовно всі мікротаски;
3. Виконуємо послідовно всі задачі рендеру (цей етап може бути оптимізований браузером, якщо він вирішить, що рендер на конкретній ітерації не потрібен).

І так по колу. Звичайно, оскільки всі задачі лежать у чергах, спочатку будуть виконані старші, а потім нові.

Теперь повернемось до фрагменту коду. Ось відповідь:

"code"
"promise"
"timeout"

Давайте розберемось, чому так. Спочатку V8 проходиться по всьому коду (виконує його як синхронний). Цей етап можна назвати макрозадачею, оскільки ця задача по суті - виконання коду в тезі <script>. А теперь давайте подивимось, що ми робимо, поки виконуємо цю макрозадачу:

1. setTimeout(() => console.log("timeout"), 0); - ми передаємо у функцію з Browser API свою функцію і хочемо, щоб вона виконалась одразу ж. Ну браузер так і робить - одразу ж додає її в чергу - чергу макрозадач.
2. Promise.resolve().then(() => console.log("promise")); - тут ми одразу ж резолвимо проміс и хочемо, щоб далі виконалась передана функция. Як і в попередньому випадку, вона повинна виконатись "миттєво". Але це вже буде мікрозадача, тому що це виконання функції в then(). Додаємо її у чергу мікрозадач.
3. console.log("code"); - а це звичайний синхронний код.

Виходить, що функції з перших двох виразів потрапили до відповідних черг. А ось третій вираз виконується хоч і після перших двох, але в контексті першої макрозадачі - виконання скрипту. Саме тому рядок "code" виведеться першим.

Тепер наш код виконався, і перша макрозадача виконана. Виходить, що Event Loop виконав одну макрозадачу, і далі за алгоритмом слід виконувати всі мікрозадачі. Мікрозадача у нас лише одна в черзі - виконання колбека промісу. Виконуємо її та виводимо в консоль "promise".

Далі за алгоритмом слідує виконання всіх задач рендеру, але у нас їх немає, тому пропускаємо. Ну і нарешті – знову виконуємо одну макрозадачу. У черзі макрозадач лежить лише колбек setTimeout'у, виконуємо його і виводимо в консоль "timeout".

Навмисне створення макрозадач

Інколи буває корисно навмисне додати в чергу макрозадач яку-небудь функцію. Ось приклад:

<div id="progress"></div> 

<script>
    function count() { 
        for (let i = 0; i < 1e9; i++) {
            i++; 
            progress.innerHTML = i; 
        } 
    } 
    
    count(); 
</script>

Тут ми імітуємо складні обчислення – рахуємо до мільярда. Неважко здогадатися, що якщо виконати цей фрагмент коду, вкладка браузера зависне на якийсь час - не реагуватиме на жодні дії користувача. Вся справа в тім, що це одна велика макрозадача. І поки вона не виконається – ніщо інше не може виконуватися.

Насправді бувають приклади дійсно складних операцій. І щоб під час їх виконання браузер не зависав (або щоб мати можливість показати прогрес-бар того, що ми робимо), користуються лайфхаками для поділу цих завдань на дрібніші. Давайте так і зробимо:

<div id="progress"></div>

<script> 
    let i = 0;
    const count = () => { 
        // виконати частину великої задачі
        do { 
            i++;
            progress.innerHTML = i; 
        } while (i % 1e6 != 0); 
        
        if (i < 1e9 - 1e6) { 
            setTimeout(count); 
        }
    } 
    
    count(); 
</script>

Тепер цикл рахує до мільйона замість мільярда. Але після циклу є умова: якщо ми дорахували до мільярда – завершити виконання, а якщо ні – запустити цю ж функцію знову, але вже через setTimeout. Саме це і є лайфхак із розбиттям макрозадачі на кілька шматків. Тепер сторінка зможе реагувати на наші дії, бо ми розділили одну макрозадачу на тисячу дрібніших, а також ми зможемо бачити зміни в DOM.

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

Насправді, цей фрагмент коду можна зробити ще кращим:

<div id="progress"></div>

<script> 
    let i = 0;
    const count = () => { 
        if (i < 1e9 - 1e6) { 
            setTimeout(count); 
        }
        
        // виконати частину великої задачі
        do { 
            i++;
            progress.innerHTML = i; 
        } while (i % 1e6 != 0);
    } 
    
    count(); 
</script>

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

Такий лайфхак часто використовується при маніпуляціях з фокусом - щоб напевне поставити його туди, куди треба нам, при цьому уникнувши проблем (наприклад, якщо за дефолтом він стрибає на інший елемент).

Навмисне створення мікрозадач

А ось наступний лафхак цілком "легітимний" і потрібний для того, щоб запустити функцію асинхронно (після поточного коду), але до ререндеру (бо мікрозадачі виконуються до рендеру). Для цього достатньо скористатись вбудованою функцією queueMicrotask(func), яка одразу ж додасть нашу функцію до черги мікрозадач:

<div id="progress"></div>

<script> 
    let i = 0;
    const count = () => { 
        if (i < 1e9 - 1e6) { 
            queueMicrotask(count);
        }
        
        // виконати частину великої задачі
        do { 
            i++;
            progress.innerHTML = i; 
        } while (i % 1e6 != 0);
    } 
    
    count(); 
</script>

Використавши queueMicrotask(func), ми отримали такий самий результат, як при виконанні синхронного коду з першого фрагменту - результат зʼявляється в DOM лише після завершення обчислень.

Нащо ж тоді це треба? Ну, насправді, тут вже кейси доволі специфічні. Детальніше можете ознайомитись ось тут: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide, особисто мені сподобалась секція Batching Operations.

Кілька слів про Web Workers

Для тривалих важких обчислень, які не повинні блокувати цикл подій, ми можемо використовувати Web Workers. Це спосіб виконання коду в іншому, паралельному потоці.

Web Workers можуть обмінюватись повідомленнями с основним процесом, але они мають свої змінні і свой цикл подій. При цьому вони не мають доступу до DOM, тому основне їх застосування – обрахунки. Вони дозволяють використовувати кілька ядер процесора одночасно.

Висновки

Двигун JS - V8 - працює в одному потоці, який має назву Main Thread.

Event Loop - це нескінченний цикл, який є основою потоку виконання в JS, і який працює з задачами.

Щоб забезпечити імітацію багатопотоковості, задачі в JS поділяються на кілька типів: макрозадачі, мікрозадачі і задачі рендеру. Для кожного типу задач існує одноіменна черга.

Макрозадачі - основний тип задач - це синхронні задачі. До них входять виконання тегів <script> - всього коду, виконання обробників подій, а також частина Browser API: setTimeout, setInterval...

Мікрозадачі - це асинхронні задачі. До них входять виконання колбеків промісів (then, catch, finally), а також функції, які виконуються черезawait.

Задачі рендеру - це все, що стосується ререндеру сторінки.

Алгоритм роботи Event Loop'a такой:
1. Виконуємо одну макрозадачу з черги макрозадач;
2. Виконуємо всі мікрозадачі з черги мікрозадач;
3. Виконуємо всі задачі рендеру з черги задач рендеру.

Для поділу важких обчислень користуємось setTimeout'ом з нульовою затримкою, щоб дати можливість у перерві виконатись усім задачам з черг макрозадач, мікрозадач и задач рендеру.

Якщо хочемо виконати функцію асинхронно (після поточного коду), але до рендеру і обробки нових подій - користуємось функцією queueMicrotask. Це потрібно у специфічних випадках, як-от правильна обробка батчів або кешування.

Для важких обчислень зазвичай використовують HTML Web Workers, які мають свій цикл подій і виконують код у паралельному потоці, що дозволяє не блокувати основний.

Джерела

https://learn.javascript.ru/event-loop

https://habr.com/ru/post/461401/

https://www.digitalocean.com/community/tutorials/understanding-the-event-loop-callbacks-promises-and-async-await-in-javascript

Контекст (зазвичай називають просто this) - ключове слово, яке вказує на контекст виконання функції - обʼєкт. По суті це об'єкт, на якому викликана функція. Але важливо уточнити, що:

• По-перше, значення, яке повертає це ключове слово, не статичне, як у інших мовах програмування, тобто може змінюватись (але самі ми його банально присвоїти не можемо);
• По-друге, цей обʼєкт визначається в момент виклику функції і посилання на нього повертається при використанні ключового слова this.

Простіше буде уявити цей this як ключове слово, яке повертає значення якогось секретного поля в функції, в якому зберігається посилання на об'єкт, в якому виконується функція - контекст. (можливо, це так і є, я просто ще не знаю).

Одразу ж питання в студію: що буде виведено тут?

const myFunction = function() {
    console.log(this);
}

myFunction();

Як ми вже знаємо, контекст - це об'єкт, у якому працює функція. Ми викликаємо її там, де й створили, тож тут відповідь – Window.

Насправді, не завжди. Зараз досить часто використовується strict mode, а якщо він увімкнений, то глобальний контекст буде посилатися вже не на Window, а на undefined. Це варто запам'ятати, бо строгий режим увімкнено за замовчуванням вже майже скрізь.

Тепер переходимо до обʼєктів - саме з ними контекст і використовується.

Чого чекати в консолі, якщо викликати цю функцію?

const myObject = {
    myMethod: function() {
        console.log(this);
    }
};

Насправді, тут питання не "чого?", а "як?". А саме, все буде залежати від того, як ми викличемо цю функцію. Ось зібрав кілька варіантів:

//1
myObject.myMethod();

//2
const func = myObject.myMethod;
funct();

В першому варіанті ми, очевидно, отримаємо посилання на сам обʼєкт myObject, тому що функція була викликана на ньому. А ось у другому прикладі ми "витягуємо" функцію з обʼєкта і викликаємо її вже без привʼязки до нього. У такому випадку ми отримаємо Window або undefined, тому що визначення контексту відбувається при виклику функції, а не при створенні.

Звісно, можемо провернути і такой трюк:

const myMethod = function() {
    console.log(this);
};

const myObject = {
    myMethod: myMethod
};

myObject.myMethod(); // myObject

Тут ми вже навпаки "помістили" свою функцію до обʼєкту. Але ж від цього нічого не змінилось - ми все одно отримаємо сам обʼєкт у якості this, бо викликаємо функцію на обʼєкті.

Те, що ми щойно зробили, називається implicit binding, тобто неявне звʼязування. У цьому випадку контекст визначається сам, без нашої участі. Але є ще explicit binding і hard binding.

Explicit binding

Мb знаємо, що у всіх функцій є такі методи, як call і apply. Між собою вони майже не відрізняються, а ось їх сенс - викликати функцію з потрібним нам контекстом:

const myMethod = function() {
    console.log(this);
};

const myObject = {
    myMethod: myMethod
};

myMethod(); // this === Window
myMethod.call(myObject, arg1, arg2,...); // this === myObject
myMethod.apply(myObject, [array of args]); // this === myObject

Навіть додати нічого. Скажу тільки, що явне (explicit) звʼязування завжди переважає над неявним (implicit), тому не важливо, як ми викликаємо myMethod - на обʼєкті myObject чи як у фрагменті коду, якщо ми явно привʼязуємосвій контекст.

Hard binding

Звичайно, у функцій є ще один метод - bind. Його призначення відрізняється від попередніх call і apply. Цей метод використовується, щоб назавжди звʼязати функцію з наданим контекстом. Звісно, щоб не "псувати" початкову функцію, метод повертає нам нову функцію з уже привʼязаним контекстом:

const myMethod = function() {
    console.log(this);
};

const myObject = {
    message: "Hello"
};

const newMethod = myMethod.bind(myObject);
newMethod(); // this === myObject

Це називається hard binding, оскільки ми назавжди привʼязуємо до функції наш контекст. Варто зазначити, що тепер явне звʼязування працювати вже не буде:

const myMethod = function() {
    console.log(this.a);
};

const obj1 = {
    a: 2
};

const obj2 = {
    a: 3
};

const newMethod = myMethod.bind(obj1); // { a: 2 }
newMethod.call(obj2); // все ще { a: 2 }

Трохи про минуле

Раніше ж класів у JS не було, тому їх роль виконували функції з ключовим словом new. Розглянемо поведінку контексту в такій ситуації:

function foo(a) {
    this.a = a;
}

const bar = new foo(2);
console.log(bar.a) // 2

Як бачимо, якщо функція була викликана з ключовим словом new, її контекстом буде новий обʼєкт. Тобто, оскільки в будь-якому випадку створюється новий обʼєкт, нам не важливо, привʼязували ми контекст вручну чи ні:

function foo(something) {
    this.a = something;
}

const obj1 = {};

const bar = foo.bind(obj1);
bar(2);
console.log(obj1.a) // 2

const baz = new bar(3);
console.log(obj1.a) // 2
console.log(baz.a) // 3

Використовуємо функції з контекстом

Насправді, контекст часто використовується саме в роботі з функціями з бібліотек. Наприклад, ми робимо запит і хочемо, щоб після нього викликався наш колбек (яким є функція). І тут, звичайно ж, починаються проблеми з контекстом:

const myObject = {
    myMethod: function() {
        helperObject.doSomething('text', this.onDone);
    },
    
    onDone: function() {
        // Сам бог знає, який "this" тут буде
    }
};

Ви могли подумати, що контекстом у функції onDone буде обʼєкт, в якому вона створена - myObject. Але ж контекст визначається тільки тоді, коли функція викликається, тому ми і справді не можемо вгадати, яким буде контекст у цьому колбеці, коли бібліотека його викличе.

Ця проблема має кілька рішень (і ще одне розглянемо пізніше у цій статті).

Перше: часто бібліотеки надають ще один параметр для передачі нашого контексту для колбеку:

const myObject = {
    myMethod: function() {
        helperObject.doSomething('text', this.onDone, this);
    },
    
    onDone: function() {
        // this === myObject
    }
};

Друге: звичайно ж ми можемо передати колбек з уже привʼязаним контекстом:

const myObject = {
    myMethod: function() {
        helperObject.doSomething('text', this.onDone.bind(this));
    },
    
    onDone: function() {
        // this === myObject
    }
};

Третє: створюємо замикання і зберігаємо this у ньому:

const myObject = {
    myMethod: function() {
        var that = this;    

        helperObject.doSomething('text', function() {
            // Сам бог знає, який "this" тут буде, але у нас є "that"
        });
    }
};

Але так робити не рекомендується, бо це костиль. Таким чином ми починаємо користуватись якимись змінними замість справжнього контексту і можемо загубитись.

Звісно ж, усі ці проблеми зʼявляються, коли ми використовуємо і нативні функції накшталт setTimeout, addEventListener абоforEach... Тож невже ми маємо завжди гратись з контекстом?

Контекст у стрілкових функціях

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

Отже, почнемо з того, що у стрілкових функцій немає свого контексту. Кілька прикладів:

const myFunction = () => {
    console.log(this);
};

myFunction(); // Window || undefined

А щось змінилось? Поки нічого. Але що скажете тут?

const myObject = {
    myMethod: () => {
        console.log(this);
    }
};

myObject.myMethod(); // ???

А ось і відповідь. Як бачимо, поведінка нічим не відрізняється від попереднього прикладу, навіть якщо ми витягнемо функцію з обʼєкту:

myObject.myMethod(); // Window || undefined

const myMethod = myObject.myMethod;
myMethod(); // Window || undefined

Але чому? Як я вже казав, у стрілкових функцій просто немає контексту. Але звідки ж ми його тоді беремо? Можливо, це "обʼєкт на рівень вище"?

const parentObj = {
    childObj: {
        message: "Hello",
        method: () => {
            console.log(this);
        }
    }
};

parentObj.childObj.method(); // Window || undefined

І знов ні... З більшою вкладеністю теж працювати не буде.

Розуміємо контекст у стрілкових функціях

У більшості статей використовується поняття "батьківський контекст". Забудьте його, оскільки воно може дуже легко заплутати. А нормальне пояснення - нижче.

На початку цієї статті я казав, що this - всього лиш ключове слово, яке повертає посилання на контекст функции, який у свою чергу є якимось обʼєктом. Це ми говоримо про звичайні функції.

А якщо казати про стрілкові функції, то у них просто немає контексту. Відповідно, коли ми звертаємося до this у стрілковій функції, ми просто "проходимося по всім скоупам" і "знаходимо" якийсь контекст вище, от і все. Якщо знаходимо - він дорівнює контексту функції (звичайної), у якій виконується наша стрілкова функція. Якщо не знаходимо - отримуємо глобальний об'єкт або undefined, залежно від того, чи увімкнений строгий режим, тому що весь код у будь-якому випадку десь виконується, і у цього "десь" є свій контекст.

Привʼязуємо свій контекст до стрілкових функцій

Ну і, звісно ж, оскільки у стрілкових функцій немає контексту, новий приклеїти до них не вийде. Тобто, bind, call та apply ніякого ефекту не дадуть, якщо їх застосовувати до стрілкових функцій.

Також стрілкові функції - це вже не минуле, тому їх не можна викликати як конструктор з використанням ключового слова new.

Використовуємо стрілкові функції без контексту

Ці функції, не маючи власного контексту, буквально створені для того, щоб бути переданими кудись. Вони створені для невеликого коду, який не має свого контексту, виконуючись у поточному. Ось приклад, в якому чудово працюють стрілкові функції:

let group = {
    title: "Our Group",
    students: ["John", "Pete", "Alice"],
    
    showList() {
        this.students.forEach(st => alert(`${this.title}: ${st}`));
    }
};

group.showList();

А ось звичайна функція тут просто зламається:

let group = {
    title: "Our Group",
    students: ["John", "Pete", "Alice"],
    
    showList() {
        this.students.forEach(function(student) {
            // Error: Cannot read property 'title' of undefined
            alert(`${this.title}: ${st}`);
        });
    }
};

group.showList();

Вся сппава в тім, що звичайна функція отримує свій контекст, який бог знає чому рівний. І швидш за все, поля title у тому контексті не буде. А у стрілкової функції немає свого контексту, тому ми шукаємо вже існуючий контекст і отримуємо посилання на обʼєкт group. Саме з цієї причини стрілкові функції ідеально підходять для роботи із замиканнями або у якості колбеків.

Як працює this

Ну і наостанок хотів би розповісти, як насправді this дає нам посилання на обʼєкт, у якому виконується функція. Почнемо з прикладу:

let user = {
    name: "John",
    hi() { alert(this.name); },
    bye() { alert("Bye"); }
};

user.hi(); // "John"
(user.name === "John" ? user.hi : user.bye)(); // Error!

Як бачимо, такі функції (методи) ще і викликати правильно треба вміти! Чому ж при другому виклиці отримуємо помилку?

Якщо уважно подивитись, виклик складається з двох операторів: оператора-крапки та круглих дужок. Якщо з круглими дужками все зрозуміло, то із крапкою потрібно розібратися.

Ми казали, що те, що нам поверне this, залежить від того, як ми викличемо функцію. Тому справа тут якраз у операторі-крапці – саме він передає інформацію про об'єкт далі, до круглих дужок.

Так ось насправді оператор-крапка повертає не саму функцію, а деяке спеціальне значення, зване Reference Type. Цей тип є внутрішнім, і містить три значення: base, name, strict. Як ви вже здогадалися, в base лежить посилання на обʼєкт, name - це ім'я поля, а strict - чи увімкнений строгий режим. Тобто коли ми робимо виклик user.hi(), до круглих дужок доходить таке значення: (user, "hi", true). І коли дужки застосовуються до такого значення (відбувається виклик), вони отримують повну інформацію про об'єкт, і можуть визначити правильний this.

Що відбувається далі, на наступному рядку? Справа в тім, що значення Reference Type – це не звичайне посилання. А коли ми застосовуємо тернарний оператор (або будь-який інший оператор) до значень Reference Type, цей Reference Type змушений конвертуватися у звичайне значення, у даному випадку - функцію. І коли ми доходимо до круглих дужок - вони отримують лише функцію, а не значення Reference Type, що і призводить до втрати контексту. Ось ще один приклад для закріплення:

let obj, method;

obj = {
    go: function() { alert(this); }
};

obj.go();                  // (1) [object Object]

(obj.go)();                // (2) [object Object]

(method = obj.go)();       // (3) undefined

(obj.go || obj.stop)();    // (4) undefined

Висновки

Контекст - це обʼєкт, в контексті якого працює функція (обʼєкт, на якому викликана функція).

this - ключове слово, яке при виконанні повертає посилання на контекст.

Контекст залежить від того, як викликана функція, і визначається лише при її виконанні.

Глобальний контекст рівний обʼєкту Window або undefined, в залежності від того, чи увімкнений строгий режим.

Implicit binding - це неявне визначення контексту при виклику функції.

Explicit binding - це явне звʼязування контексту з функцією з використанням call и apply. call від apply відрізняється лише тим, що call приймає список послідовних аргументів, а apply - масив з усіма аргументами.

Hard binding - це жорстке звʼязування контексту і функції з використанням bind. Функція з контекстом, що був привʼязаний у такий спосіб, завжди буде посилатися лише на цей контекст, і жоден call чи apply не зможуть це змінити.

У cтрілкових функцій немає свого контексту, тому при зверненні в них до this шукається і повертається найближчий існуючий контекст. call, apply и bind не працюють зі стрілковими функціями.

Стрілкові функції створені для того, щоб бути переданими в інший код у якості колбеку.

Джерела

https://www.codementor.io/@dariogarciamoya/understanding--this--in-javascript-du1084lyn

https://www.codementor.io/@dariogarciamoya/understanding-this-in-javascript-with-arrow-functions-gcpjwfyuc

https://learn.javascript.ru/object-methods

https://learn.javascript.ru/arrow-functions

Перед розглядом складних замикань давайте розглянемо більш прості види областей видимості.

Область видимості

Тож Область видимості (scope) - це концепт в JS, який визначає доступність змінних і функцій в тому чи іншому місці коду. Ця концепція лежить також в основі замикань, поділяючи змінні на локальні та глобальні.

В JS існує кілька видів області видимості. При цьому варто зазначити, що вони звичайно ж можуть бути вкладеними.

Блоковий скоуп

Блоки коду, як if, for, while, або ж штучні ({ }) визначають нову область видимості для змінних, оголошених з використанням let і const. var натомість не має блокової області видимості - змінні, оголошені з використанням var, доступні майже скрізь завдяки механізму hoisting'а.

Скоуп функції

Функція, змісно ж, також має власну область видимості. Що правда, вона також працює і для var'ів навідміну від блокового скоупу. При цьому не важливо, функція оголошена як function declaration чи function expression.

Скоуп модуля

Логічно, що і у модулів також є свій скоуп. Якщо ми імпортували модуль, але він не експортує будь-яких змінних, ми не зможемо отримати до них доступ:

// модуль circle 
const pi = 3.14; 
console.log(pi); // 3.14 
// кінець модуля circle

// інший модуль
import './circle' 
console.log(pi) // ReferenceError
// кінець іншого модуля

Глобальний скоуп

Це найвища область видимості, яка обмежується скриптом. Вона, до речі, створена для того, щоб ми могли мати доступ до глобальних обʼєктів типу Window або document.

Насправді існує ще одна область видимості - лексична. Саме про це і поговоримо далі, в контексті замикань - так це простіше зрозуміти.

Замикання

Замикання - це функції, які посилаються на незалежні змінні. Тобто, функція, визначена у замиканні, запамʼятовує "середовище", в якому була створена. Незалежні змінні тут - це ті змінні, які були використані у функції як аргументи і не були створені у ній локально.

Отже, маємо такий приклад:

function makeWorker() {
    let name = "Pete";
    
    return function() {
        console.log(name);
    };
};

let name = "John";

let work = makeWorker();
work(); // "Pete", "John" чи взагалі помилка?

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

Лексичне середовище

Що таке змінна в JS? Непоганий початок, так? Насправді, змінних не існує. Зате існує таке поняття як лексичне середовище (Lexical Environment). В JS у кожної функції, виконуваного блоку коду чи скрипта є деякий обʼєкт, який має назву лексичне середовище. Цей обʼєкт складається з двох частин:

• Environment Record - обʼєкт, у якому всі створені в рамках даного блоку коду змінні зберігаються у якості полів;
• Посилання на зовнішнє лексичне середовище. У глобального дорівнює null.

Отже, змінна - це насправді поле деякого обʼєкта, який звʼязаний з тим блоком коду, в якому ця змінна оголошена.

Це якщо казати про змінні. А як щодо функцій (function declaration) і змінних, оголошених з використанням var? Насправді, все просто: перед початком виконання коду вони вже зберігаються у глобальному лексичному середовищі, дякуючи нашому улюбленому механізму hoisting'у.

Тепер поговоримо про вкладені лексичні середовища.

Під час виклику функції у нас, крім глобального лексичного середовища, зʼявляється ще одне - те, яке створюється для функції, що ми її викликаємо. Звідси можемо зробити висновок: коли код хоче отримати доступ до якої-небудь змінної, спочатку відбувається її пошук у внутрішньому лексичному середовищі функції, потім у зовнішньому, і так далі аж до глобального, поки змінна не буде знайдена. Саме тому якщо функція хоче отримати доступ до значення деякої змінної, вона завжди спершу шукає його у своєму власному лексичному середовищі. Тобто відповідь до першого фрагменту коду буде така:

function makeWorker() {
    let name = "Pete";
    
    return function() {
        console.log(name);
    };
};

let name = "John";

let work = makeWorker();
work(); // "Pete"

Варто зазначити, що лексичне середовище створюється кожен раз перед викликом функції, тобто новий виклик = нове лексичне середовище.

Вкладені функції

Тепер ближче до теми замикань. Іноді ми створюємо функцію, яка повертає нову функцію. Та функція, що всередині, називається вкладеною:

function makeCounter() { 
    let count = 0;
    
    return function() { 
        return count++; // є доступ до зовнішньої змінної count 
    }; 
} 

let counter = makeCounter(); 

alert(counter()); // 0 
alert(counter()); // 1 
alert(counter()); // 2

Як це працює? При виконанні функції counter починається пошук змінної count, яка буде знайдена у батьківському лексичному середовищі. Тож є два питання:

• Чому значення змінної count зберігається? Ти ж казав, що кожного разу при виклику функції створюється нове лексичне середовище...
• Чи буде ця змінна спільною, якщо ми створимо два таких лічильники:

    let counter1 = makeCounter(); 
    let counter2 = makeCounter(); 
    
    alert(counter1()); // 0 
    alert(counter1() ; // 1 
    alert(counter2()); // 1 чи 0?

Отже, по-перше, всі функції при "народженні" отримують приховане поле (функції ж насправді - об'єкти) під іменем [[Environment]], яке містить посилання на лексичне середовище місця, де функція була створена. Таким чином, функції знають, де вони були створені. Саме тому, коли ми визначаємо функцію makeCounter, у її поле [[Environment]] записується посилання на глобальне лексичне середовище. Далі ми викликаємо цю функцію і записуємо результат її виконання у змінну counter, яка вже, до речі, є у глобальному середовищі, але ще не задана (містить undefined).

При виклику makeCounter створюється її лексичне середовище, в якому є поле count. Далі ми створюємо анонімну функцію, яка одразу ж отримує посилання на батьківське лексичне середовище, тобто лексичне середовище makeCounter, і повертаємо її.

Отже, ми записали вкладену функцію у змінну counter і тепер хочемо її викликати. Оскільки у цій функції записане посилання на лексичне середовище makeCounter, вона звертається при всіх своїх викликах до однієї і тої ж змінної counter. Тобто, так, при виклику counter кожен раз саме для неї створюється нове лексичне середовище, але батьківське натомість залишається тим самим. Це відповідь на перше питання.

І друге питання: чи буде ця змінна спільною для різних лічильників. Відповідь - ні, тому що як раз тут при кожному виклику makeCounter створюється нове лексичне середовище, в якому зберігається початкове значення змінної counter, унікальної для кожного виклику.

Ось тепер маємо відповідь на найперше питання - що ж таке замикання. Замикання - це функція, яка запамʼятовує свої зовнішні змінні і може отримати до них доступ. І найголовніше - в JS усі функції за замовчуванням є замиканнями. А ось лексичне середовище, по суті - це реалізація механізму області видимості (Scope).

Блоки коду

Попередні приклади зосереджувались на функціях, але лексичне середовище існує для будь-якого блоку коду (інакше як би все працювало без змінних :О).

Лексичне середовище створюється при виконанні блоку коду і містить локальні змінні цього блоку. Наприклад:

А ось приклад для циклів:

for (let i = 0; i < 10; i++) {
    let x = i + 1;
} 
alert(x); // Помилка, немає такої змінної

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

IIFE

В минулому в JS не було лексичного середовища на рівні блоків коду, тому вигадали "костиль". Оскільки лексичне середовище працювало лише для функцій, їх почали використовувати, щоб створити ізольований блок коду:

(function() { 
    let message = "Hello"; 
    alert(message); // Hello 
})();

Так, тут ми просто створюємо анонімну функцію, яку одразу ж виконуємо, все просто. Це має назву immediately invoked function expression - IIFE.

Сейчас так делать не нужно, лексическое окружение создается для любого блока кода.

Збірка сміття

Зазвичай лексичне середовище видаляется одразу ж після того, як функція чи блок коду виконались:

function f() { 
    let value1 = 123; 
    let value2 = 456; 
} 

f();

Але якщо провернути трюк зі вкладеною функцією - у неї залишиться посилання на лексичне середовище батьківської функції, тому воно просто не зможе видалитись, поки не видалиться вкладена функція. У наступному прикладі зберігаються одразу ж три лексичні середовища:

function f() { 
    let value = Math.random(); 
    return function() { 
        alert(value); 
    }; 
} 

// Три функції в масиві, кожна з яких посилається на 
// лексичне середовище з відповідного виклику f() 
let arr = [f(), f(), f()];

Сюрпризи в дебагері

Єдине, про що варто також зазначити - приколи дебагера. Якщо ви якось захочете скористатись дебагером у браузері з двигуном V8, знайте, що він любить все оптимізувати, тому при відладці можуть бути сюрпризи:

let value = "Сюрприз!"; 

function f() { 
    let value = "найближче значення"; 
    
    function g() { 
        debugger; // в консолі напишіть alert(value): отримаєте "Сюрприз!" 
    }
     
    return g; 
} 

let g = f(); 
g();

або ж:

function f() { 
    let value = Math.random(); 
    
    function g() { 
        debugger; // в консолі напишіть alert(value): такої змінної немає! 
    }
     
    return g; 
} 

let g = f(); 
g();

Ще раз: такі приколи зʼявляються лише у відладці, при звичайній роботі все буде ок.

Висновки

В JS існує 5 видів області видимості: блокова, функція, модуль, глобальна, а також лексична. До блокових відносяться всі конструкції циклів, умовні конструкції, а також штучні блоки коду.

Глобальна область видимості створена для роботи з полями глобального обʼєкту: Window, document, Math...

Просте визначення замикання: замикання - це функції, що посилаються на незалежні змінні. Таким чином, функція, що визначена у іншій функції (замиканні) запамʼятовує середовище, в якому була створена.

Під капотом замикання засновані на механізмі лексичного середовища (Lexical Environment).

В JS всі функції є замиканнями (і стрілкові теж), а лексичне середовище по суті - це реалізація механізму області видимості (Scope).

У блоків коду в JS, таких як цикли, умовні конструкції, а також у штучних блоків коду ({ }) також є лексичне середовище.

Раніше у блоків коду не було власного лексичного середовища, тому використовували лайфхак: створювали анонімні функції і одразу ж викликали їх. Це зветься immediately invoked function expression (IIFE).

Лексичне середовище видаляється одразу ж після закінчення виконання функції чи блоку. Але якщо у скоупі відповідної функції є вкладена функція - батьківське лексичне середовище буде жити допоки на нього існують посилання.

Джерела

https://learn.javascript.ru/closure

Всього у JS вісім типів даних:

• number
• BigInt
• string
• boolean
• null
• undefined
• object
• Symbol

Незважаючи на те, що null і undefined залогікою повинні мати тип object, вони є окремими типами. Так склалось.

null - це особливе значення, яке буквально означає "у змінну записане нічого" - тобто значення невідоме. Важливо, что це не є посиланням на "нічого", як у інших мовах програмування.

undefined - це також особливе значення, яке вказує на те, що значення змінної ще не було задане. За замовчуванням лежить у всіх "незаданих" змінних, якщо:

• У змінну не записане значення при створенні;
• Функція нічого не повертає, але ми хочемо отримати щось від неї (саме тому ми бачимо undefined після створення функції у консолі браузера).

Зазвичай для маніпуляції з "порожніми" зміниими використовують саме null, а ось undefined використовується тільки для того, щоб перевірити, чи було взагалі значення змінній задане.

Примітиви і object

Всі типи в JS, крім object, є примітивами. Це означає, що обʼєкти зберігають в собі "набір даних", а примітивні типи, як-от рядки - представляють самі себе. Ба більше, при своренні обʼєкту ми отримуємо посилання на нього, а при створенні примітиву - саме значення. Тобто такий фокус не пройде:

let s = "hello";
let c = s;
c += " world";
console.log(s) // все ще "hello"

Звичайно ви можете (і маєте) заперечити: "Але ж у рядків є методи і навіть поля, як-от length! Чому ж тоді це примітив???". І цьому є появнення.

Примітиви створені для оптимізації. Але для зручності в JS також є і класи, які представляють "обʼєктні" аналоги цих примітивів. Тобто в JS є такі класи як Number, String, Boolean, і вони також мають конструктори, як і в інших мовах.

Таким чином, коли ми хочемо, наприклад, отримати значення поля length або викликати метод toUpperCase у рядка, під капотом створюється обʼєкт-обгортка для рядка, викликається метод, повертається значення і обʼєкт видаляється.

Я сказав, що є класи Number, String... Так ось, екземпляри цих класів можна без проблем створити з використанням конструкторів:

const s = new String("hello");
console.log(typeof s); // object

Це інколи буває корисно, але взагалі-то не рекомендується так робити, і причину цього я вказав на другому рядку фрагменту коду вище - стрічка більше не стрічка, а object. Замість цього часто роблять так:

const numString = "123";
const num = Number(numString); // 123

Як бачимо, це швидкий варіант парсингу.

Помилки typeof

І наостанок кілька неточностей в JS:

• typeof(null); // "object" - null - це окремий тип;
• typeof(alert); // "function" - типу function не існує, це зроблено для зручності розробки.

Висновки

JS - динамічно-типізована мова програмування - змінні можуть містити в собі дані будь-якого типу.

В JS нараховується вісім типів даних: number, BigInt, string, boolean, null, undefined, object, Symbol.

null і undefined - це окремі типи, незалежні від object. null зазвичай вказує на те, що змінні присвоєне "нічого", а undefined - що змінній взагалі нічого не було присвоєно. Також undefined за замовчуванням повертається з функцій, які нічого не повертають.

Всі типи, окрім object, є примітивами. Те, що, до прикладу, у рядків, є методи і поля, пояснюється тим, що при зверненні до них, рядки під капотом конвертують у їх обʼєктні репрезентації.

Використовувати обʼєктні репрезентації замість примітивних аналогів вкрай не рекомендується, бо тип у них буде object. Замість цього, до прикладу, для парсингу, краще використовувати відповідні функції, як-от Number().

У оператора typeof є кілька неточностей:
- typeof(null); // "object" - null - це окремий тип;
- typeof(alert); // "function" - типу function не існує, це зроблено для зручності розробки.

Джерела

https://learn.javascript.ru/types