1. прототипна спадкування (також: прототипи, об'єктні посилання)
2. Функціональне програмування (також: замикання, функції першого класу, лямбда)
Не мати уявлення про парадигмах, не згадати прототипна ООП або функціональне програмування.
Функціональне програмування має на увазі обчислення математичних функцій, уникаючи загальних станів і змінюваних даних. Lisp (специфікований в 1958 році) є одним з перших функціональних мов програмування і сильно натхненний лямбда-численнями. Lisp і подібні йому мови широко застосовуються і до цього дня.
1. Чисті функції / чистота функцій
2. Уникнення побічних ефектів
3. Простий склад функцій
4. Приклади функціональних мов: Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, OCaml і т.д.
5. Особливості, які підтримує функціональне програмування: функції першого класу, функції вищих порядків, функції як аргументи / значення
1. Відсутність згадок чистих функцій / уникнути побічних ефектів
2. Не навести приклади функціональних мов
Класова спадкування: екземпляри успадковуються від класів, створюються подклассовие відносини (ієрархічна систематизація класів). Примірники реалізуються через конструктор функції, через дескриптор new. Примірник класу може не містити дескриптор class починаючи з ES6.
Прототипна спадкування: екземпляри успадковуються безпосередньо від інших об'єктів, реалізуються через фабрики або Object.create () і екземпляри можуть бути складені з безлічі різних об'єктів для спрощення вибіркового наслідування. Прототипна спадкування більш просте і гнучке, ніж класове.
1. Класи: тісні зв'язки, ієрархія
2. Прототипи: конкатенативного спадкування, делегування, функціональне спадкування, композиція
Чи не вказати на переваги прототипного успадкування перед класовим
Плюси ООП: проста для розуміння концепція об'єктів і методів виклику. ООП прагне використовувати імперативний стиль, ніж декларативний, який читається як прямий набір машинних інструкцій.
Мінуси ООП: як правило, присутня залежність від загальних станів. Об'єкти і їх поведінка пов'язані однією сутністю, до якої випадково може бути отриманий доступ будь-якою кількістю функцій в невизначеному порядку, що може привести до непередбачуваного поведінки, наприклад, станом гонки.
Плюси ФП: використовується функціональна парадигма, що дозволяє уникнути загальних станів і небажаних ефектів, виключаються помилки, можливі через конкурування функцій. Завдяки таким фічам, як неявне програмування, функції, як правило, радикально спрощуються і легко перебудовуються для більш легкого, в порівнянні з ООП, повторного використання коду.
Обчислення, що використовують чисті функції легко масштабуються на кілька процесорів або розподілених обчислювальних кластерів без побоювання виникнення боротьби за ресурси.
Мінуси ФП: надмірна експлуатація функціональних підходів, на зразок неявного програмування, може привести до зниження читабельності коду, так як кінцевий код виходить більш абстрактним, коротким і менш конкретним.
Найчастіше люди більше знайомі з ООП і імперативним підходом, так що деякі загальні ідіоми функціонального програмування можуть викликати труднощі у новачків.
1. Проблеми загальних станів, небажаної поведінки
2. Можливості ФП по радикальному спрощення коду програм
3. Різниця в складності вивчення
4. Побічні ефекти і їх вплив на надійність програм
5. Складність зміни і загальна крихкість бази ГО коду в порівнянні з такою у функціональному стилі
Чи не згадати недоліки одного з підходів - кожен, хто стикався з одним з них, знає і про пару-другу недоліків
Питання із секретом. Правильна відповідь - ніколи. Композиція - більш простий і гнучкий підхід, ніж спадкування класів.
«... композиція об'єктів краще, ніж наслідування класів»
Існує більш, ніж один тип прототипного спадкування:
1. Делегування (ланцюжок прототипів)
2. Конкатенація (міксини, Object.assign ())
3. Функціональне спадкування (не плутати з функціональним програмуванням. Функція використовується для створення замикання для private / інкапсуляції)
1. У ситуаціях, коли модулі або функціональне програмування не забезпечують очевидного рішення
2. Коли потрібно зібрати об'єкт з декількох джерел
3. У будь-якому випадку, коли потрібно застосувати спадкування
1. Не знати, коли застосовуються прототипи
2. Не знати про Міксини або Object.assign ()
Це цитата з книги "Design Patterns: Elements of Reusable Object-Oriented Software". Повторне використання коду має досягатися за рахунок збирання малих одиниць функціональності в новий об'єкт, а не наслідуванням класів і створенням ієрархій.
1. Уникнення успадкування і тісних зв'язків
Чи не назвати якусь із згаданих вище проблем. Чи не пояснити різницю між композицією і спадкуванням або зуміти розповісти про переваги композиції.
Двостороння зв'язок даних має на увазі, що поля інтерфейсу пов'язані з моделлю даних динамічно, тобто при зміні полів інтерфейсу змінюється модель, і навпаки.
Односпрямований потік даних означає, що тільки модель - джерело істини. Зміни в інтерфейсі запускають повідомлення, які сигналізують користувачеві про намір моделі (або «store» в термінах React). Сенс в тому, що дані завжди йдуть в одному напрямку, що полегшує розуміння.
Односторонні потоки даних детерміновані, тоді як двостороння прив'язка може викликати небажані ефекти, які важче відстежити і зрозуміти.
1. React - новий канонічний приклад односпрямованого потоку даних, так що згадка реактив буде хорошою ідеєю. Cycle.js - ще одна популярна реалізація односпрямованого потоку даних.
2. Angular - популярний фреймворк, який використовує двосторонню прив'язку.
Нерозуміння цих концепцій, нездатність пояснити різницю між ними.
Монолітна архітектура означає, що ваш додаток написано як єдиний зв'язний блок коду, чиї компоненти спроектовані для спільної роботи і використання загальних ресурсів.
Підхід мікросервісов має на увазі, що додаток складається з безлічі невеликих незалежних додатків, здатних працювати з власними ресурсами і потенційно на великій кількості окремих машин.
Переваги монолітної архітектури: основною перевагою монолітної архітектури є те, що більшість додатків, як правило, мають безліч загальних проблем, таких як логирование, обмеження швидкості і необхідність функцій безпеки - в єдиному додатку для кожного компонента їх простіше вирішувати.
Мінуси монолітного додатки: так як всі компоненти тісно пов'язані один з одним, у міру розвитку додатки, стає важче його розуміти, з'являється багато неочевидних залежностей і побічних ефектів.
Плюси мікросервісов: мікросервіси зазвичай краще організовані, так як кожен компонент виконує своє завдання і працює незалежно від кожного іншого компонента. Додаток на основі відокремлених компонентів також простіше переконфигурировать і змінювати.
Мінуси мікросервісов: при створенні нового мікросервіса може з'явиться багато раптових проблем, які не очікувалися при проектуванні. Для монолітного додатки можна використовувати проміжне програмне забезпечення для вирішення різних наскрізних проблем без особливих трудовитрат.
При мікросервісной архітектурі або будуть потрібні накладні витрати на окремі модулі для кожної наскрізний проблеми, або потрібно инкапсулировать їх на іншому рівні обслуговування, через який проходить весь трафік.
Зрештою, навіть монолітні архітектури мають тенденцію направляти трафік через зовнішній рівень обслуговування, але з монолітної архітектурою можна відкласти витрати на цю роботу до тих пір, поки проект не стане більш зрілим.
Мікросервіси ж часто розгортаються в власних віртуальних машинах або контейнерах, що призводить до швидкого збільшення числа конфліктів по віртуальним ресурсів.
1. Незважаючи на початкову дорожнечу, мікросервіси виграють в довгостроковій перспективі за рахунок кращого масштабування
2. Практичні відмінності мікросервісов і монолітних додатків
1. Незнання відмінностей архітектур
2. Незнання недоліків мікросервісов
3. Недооцінювати переваги масштабування мікросервісов
Синхронне програмування означає, що за винятком умов і викликів функцій, код виповнюється послідовно від верху до низу, затримуючись на довгих завданнях, таких як мережеві запити і читання / запис з диска.
Асинхронне програмування має на увазі, що коли потрібна операція блокування дії, з'явиться вікно, і код продовжує працювати без блокування до очікування результату. Коли відповідь готовий, запускається переривання, це призводить до запуску обробника подій і потік управління триває. Таким чином, один програмний потік може обробляти безліч паралельних операцій.
Призначені для користувача інтерфейси за своєю природою асинхронні, більшу частину часу вони проводять, очікуючи призначеного для користувача введення, щоб перервати цикл і запустити обробник.
Node.js за замовчуванням асинхронний, по суті, сервер проводить весь час у циклі, чекаючи мережевий запит.
1. Значення блокувань, вплив на продуктивність
2. Розуміння оброблювачів і чому вони важливі для інтерфейсів
1. Нерозуміння термінів синхронності і асинхронності
2. Нездатність визначити наслідки для продуктивності