Что такое AICPA SOC 2 и 3?

Сертификация ISO vs. AICPA SOC

Для чего аудит нужен Яндекс.Паспорту?

Что изучают аудиторы?

Gap-аудит

Уникальные решения Яндекса vs. рамки стандарта

Документы и отчёты (и на бумаге тоже!)

Результаты

• SOC 3 отчёт краткая версия, которую мы можем показывать людям за пределами компании.
• SOC 2 отчёт полный, раскрывает детали процессов, может передаваться вовне только под NDA в случае необходимости.

• Наши процессы соответствуют международным стандартам. И этому есть независимое и публичное подтверждение.
• Хотим расширять скоуп сертификации. Паспорт взяли первым, потому что это единая точка доступа к данным пользователей, но останавливаться не планируем будем сертифицировать и другие сервисы.

Привет, меня зовут Григорий Бизюкин, я преподаватель Школы разработки интерфейсов и фронтенд-разработчик в Яндексе. Давайте поговорим о функциональном программировании в мире JavaScript. Мы все про ФП что-то слышали, нам всем оно интересно, но у меня, когда я искал полезные материалы для подготовки к лекциям, сложилось такое впечатление: есть куча статей, каждая из которых либо говорит об ФП общими словами, либо раскрывает отдельный маленький кусочек темы, чего, конечно, недостаточно.

^{Добавим функционального света}

Впервые я попробовал обобщить в одном месте самые популярные и, как мне кажется, применимые приёмы функционального программирования в лекции для ШРИ. Потом захотелось расширить материал и рассмотреть ещё больше концепций. В результате получилась эта статья. В ней мы разберём всё самое сложное простым языком с понятными примерами. Надеюсь, вам будет интересно!

Функциональное программирование

Когда кто-то рассуждает о функциональном программировании, речь может идти как о парадигме целиком, так и об отдельных подходах, таких как чистые функции, неизменяемые данные и другие.

Важно понимать, что когда на глаза попадается очередная статья Почему разработчик обязательно должен знать ФП, то автор, вероятно, говорит именно о нескольких подходах из мира ФП, которые можно применить у себя на проекте, чем о том, что вам пора пересесть за Haskell.

Функциональное программирование штука интересная, но вряд ли вы захотите переписать весь проект на функциональном языке. На практике именно отдельные подходы оказываются самыми полезными и применимыми. На них и сконцентрируемся. В контексте ФП часто можно встретить термины вроде линз и монад. Здесь они останутся за скобками, потому что уж слишком специфичны.

Если ваша задача изучить подходы ФП, чтобы наконец-то разобраться с композицией, частичным применением, каррированием, неизменяемыми данными и чистыми функциями, скорее всего, эта статья ответит на большинство ваших вопросов. Но если вам интересно функциональное программирование как отдельная дисциплина, то статью можно рассматривать как плавное введение. В конце будут ссылки на материалы, которые помогут продолжить изучение.

За и против

Единого мнения, разумеется, нет, но во фронтенде есть тенденция к разумному применению некоторых подходов из мира ФП. Именно разумному использованию: всегда важно понимать, какая задача решается и какие способы решения будут наиболее эффективны.

В целом считается, что ФП делает код понятнее, потому что является более декларативным. Остальные рассуждения оставим за скобками, так как на Хабре уже достаточно статей, где рассмотрены разные аргументы как за ФП, так и против. При желании можно обратиться к ним, чтобы решить для себя, когда вы хотите использовать ФП, а когда нет. Здесь мы сосредоточимся на объяснении терминов и подходов.

Императивный vs декларативный

Императивный подход говорит о том, как решать задачу, декларативный что хотим получить в результате.

В жизни мы, как правило, думаем о результате. Например, когда просим маму приготовить пиццу, делаем это декларативно: Мам, хочу пиццу! Если бы мы делали это императивно, то получилось бы что-то вроде: Мама, открой холодильник, достань тесто, возьми помидоры и т. д.

В разработке та же история. Когда мы пишем декларативно, код выглядит гораздо проще:

const array = [4, 8, 15, null, 23, undefined]// императивный подходconst imperative = []for (let i = 0, len = array.length; i < len; ++i) {    if (array[i]) {        imperative.push(array[i])    }}// декларативный подходconst declarative = array.filter(Boolean)

Для фильтрации массива чисел больше не нужно думать о деталях: о том, как инкрементировать переменную i и как не выйти за границы массива. Нам достаточно передать предикат Boolean в функцию filter, и дело сделано.

Причём если вам кажется, что декларативный стиль нечто новенькое, то спешу вас заверить это не так. Вы наверняка писали css-стили, где говорили, что именно хотите получить в результате:

/* css */.button {    color: azure;}

Нам неважно, как именно браузер будет парсить css, искать на странице элемент, соответствующий селектору, и перекрашивать его в определённый цвет. Мы говорим только о том, что хотим получить.

Такая же история и с SQL:

-- SQLSELECT titleFROM filmsWHERE rating > 9GROUP BY director

Запрос говорит о результате, а не о том, как именно его выполнить.

Функции и процедуры

Функция понятие, близкое к математическому. Она что-то получает на вход и всегда что-то возвращает.

const f = (x) => x * Math.sin(1 / x)

Процедура, в свою очередь, вызывается ради побочных эффектов:

const print = (...args) => {    const style = 'color: orange;'    console.log('%c' + args.join('\n'), style)}

В данном случае код будет вызываться ради того, чтобы вывести в консоль свои аргументы оранжевым цветом и разделить их символом новой строки.

В JS не существует процедур, потому что то, что мы считаем процедурой, на самом деле является функцией без return. Если опустить return, функция всё равно неявно возвращает undefined и остаётся функцией.

Но в функциональном программировании мы стремимся как можно больше использовать функции, которые явно что-то возвращают.

Параметры и аргументы

Параметры это переменные, созданные в объявлении функции. Аргументы конкретные значения, переданные при вызове.

// x  параметр (почти любое число)const f = (x) => x * Math.sin(1 / x)// 0.17  аргумент (конкретное число)f(0.17)

Сигнатура

Количество, тип и порядок параметров. Объявление функции в JS не содержит информации о типе параметров из-за динамической типизации. Если не используется TypeScript, эту информацию можно указать через JSDoc.

/** * @param {*} value * @param {Function|Array<string>|null} [replacer] * @param {number|string|null} [space] * @returns {string} */function toJSON (value, replacer, space) {    return JSON.stringify(value, replacer, space)}

Арность

Арность количество параметров, которые принимает функция. В JavaScript арность функции можно определить при помощи свойства length.

const awesome = (good, better, theBest) => {}awesome.length // 3

У свойства length есть особенности, которые следует учитывать:

// аргументы по умолчаниюconst defaultParams = (answer = 42) => {}defaultParams.length // 0// остаточные параметрыconst restParams = (...args) => {}restParams.length // 0// деструктуризацияconst destructuring = ({target}) => {}destructuring.length // 1

Рекурсия

Когда функция вызывает саму себя, происходит рекурсивный вызов. Для его корректной работы необходимо, чтобы внутри функции было хотя бы одно рекурсивное условие, на которое мы обязательно рано или поздно выйдем. Если этого не произойдёт, программа зациклится.

function factorial (n) {    if (n <= 1) {        return 1    }    return n * factorial(n - 1)}

Проблема в том, что в случае рекурсии с очень большой глубиной может произойти переполнение стека. Это можно исправить при помощи хвостовой рекурсии. Тогда каждый последующий рекурсивный вызов будет замещать в стеке текущий. Чтобы хвостовая рекурсия стала возможной, необходимо, чтобы функция не использовала замыкание и явно возвращала рекурсивный вызов в качестве самой последней операции. Пример про факториал можно было бы переписать так:

function factorial (n, total = 1) {    if (n <= 1) {        return total    }    return factorial(n - 1, n * total)}

Несмотря на заманчивые возможности, поддержка хвостовой рекурсии до сих пор отсутствует и вряд ли появится в будущем, поэтому сведения о ней носят чисто теоретический характер. Если добавить в самое начало функции console.trace, можно убедиться, что каждый новый вызов создаёт новый кадр в стеке, несмотря на то, что условия рекурсии выполняются. Более подробно об оптимизации хвостовых вызовов можно почитать здесь.

Функция первого класса

Функции, которые мы можем использовать как обычные объекты, называются функциями первого класса. Их можно присваивать, передавать в другие функции и возвращать.

// присваиватьconst assign = () => {}// передаватьconst passFn = (fn) => fn()// возвращатьconst returnFn = () => () => {}

Функция высшего порядка

Функции, которые принимают или возвращают другие функции. С ними мы работаем каждый день.

// map, filter, reduce и т.д.[0, NaN, Infinity].filter(Boolean)// обещанияnew Promise((res) => setTimeout(res, 300))// обработчики событийdocument.addEventListener('keydown', ({code, key}) => {    console.log(code, key)})

При этом высшим порядком могут быть не только функции, но и, например, компоненты в React, принимающие или возвращающие другие компоненты. Они, соответственно, называются компонентами высшего порядка.

Предикат

Это функция, которая возвращает логическое значение. Самый распространённый пример использование предиката внутри функций filter, some, every.

const array = [4, 8, 15, 16, 23, 42]// isEven  это предикатconst isEven = (x) => x % 2 === 0const even = array.filter(isEven)

Замыкание

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

const createCounter = tag => count => ({    inc () { ++count },    dec () { --count },    val () {        console.log(`${tag}: ${count}`)    }})const pomoCounter = createCounter('pomo')const work = pomoCounter(0)work.inc()work.val() // pomo: 1const rest = pomoCounter(4)rest.dec()rest.val() // pomo: 3

В примере внутри замыкания хранятся две переменные: tag и count. Каждый раз, когда мы создаём новую переменную внутри другой функции и возвращаем её наружу, функция находит переменную, объявленную во внешней функции, через замыкание. Если тема замыканий кажется чем-то загадочным, почитайте о них подробнее в блоге HTML Academy.

Мемоизация

Полезный приём функция кеширует результаты своего вызова:

const memo = (fn, cache = new Map) => param => {    if (!cache.has(param)) {        cache.set(param, fn(param))    }    return cache.get(param)}const f = memo((x) => x * Math.sin(1 / x))f(0.314) // вычислитьf(0.314) // взять из кеша

Можно заметить, как одни возможности становятся базой для других, более сложных. Благодаря функциям первого класса становятся возможны функции высших порядков, благодаря которым становятся возможны замыкания. А благодаря замыканиям становится возможной мемоизация.

Конвейер и композиция

Конвейер и композиция это вызов следующей функции с результатами предыдущей. В зависимости от того, в какую сторону мы передаём данные: слева направо или справо налево, получается либо конвейер, либо композиция.

Забавно, что в ООП тоже есть композиция, но она имеет там совершенно другой смысл.

Конвейер

Наверное, в жизни разработчиков конвейеры чаще всего встречаются при работе в командной строке, когда результат работы программы передаётся дальше при помощи конвейерного оператора.

# вывести идентификаторы процессов с подстрокой kernelps aux | grep 'kernel' | awk '{ print $2 }'

Возможно, в JavaScript тоже появится нечто похожее. В одном из предложений для ESNext описывается конвейерный оператор, при помощи которого можно будет делать вот такие штуки:

const double = (n) => n * 2const increment = (n) => n + 1// без конвейерного оператораdouble(increment(double(double(5)))) // 42// с конвейерным оператором5 |> double |> double |> increment |> double // 42

Если бы у нас была функция pipe, которая аналогичным образом организовывает поток данных, через неё можно было бы записать так:

pipe(double, double, increment, double)(5) // 42

Аргумент, переданный в конвейер, последовательно проходит слева направо:

// 5 -> 10 -> 20 -> 21 -> 42

Хм, а что если запустить конвейер в другую сторону?

Композиция

Если запустить конвейер в обратную сторону, получится композиция. Композицию функций можно создать без операторов, просто вызывая каждую следующую функцию с результатами предыдущей.

// композиция функций в чистом видеdouble(increment(double(double(5)))) // 42

Если записать то же самое через вспомогательную функцию compose, получится:

compose(double, increment, double, double)(5)

Внешне всё осталось почти так же, но место вызова функции increment изменилось, потому что теперь цепочка вычислений стала работать справа налево:

// 42 <- 21 <- 20 <- 10 <- 5

Если рассмотреть композицию и конвейер ближе, станет понятно, почему в функциональном программировании предпочитают композицию. Композиция описывает более естественный порядок вызова функций.

// оригинальная цепочка вызововone(two(three(x)))// более естественно с точки зрения чтенияpipe(three, two, one)(x)// более естественно с точки зрения записиcompose(one, two, three)(x)

Таким образом, конвейер и композиция это два направления одного потока данных.

Преимущества

Когда поток данных организован через вспомогательные функции pipe или compose, больше не нужно писать много скобок, кроме того, код выглядит более декларативным, то есть более читаемым. Но есть ещё два момента, которые можно легко упустить.

Создание новых абстракций

Функции чем-то похожи на кубики Лего. Когда мы строим программу, она состоит из отдельных кубиков, причём каждый из них решает свою задачу.

Часть кубиков есть изначально это встроенные функции, готовые библиотеки и код, написанный ранее. Когда мы добавляем в программу что-то ещё, то для создания новых кубиков обычно используем уже существующие.

Например, у нас есть два готовых кубика: получить слова из текста, оставить только уникальные слова:

// готовые кубикиconst words = str => str    .toLowerCase().match(/[а-яё]+/g)const unique = iter => [...new Set(iter)]const text = `Съешь ещё этих мягкихфранцузских булок, да выпей же чаю`const foundWords = words(text)const uniqueWords = unique(wordsFound)

Затем мы замечаем, что хотим переиспользовать возможности двух кубиков, и создаём новую деталь. Для этого мы строим новую абстракцию оборачиваем последовательный вызов двух функций в новую функцию, которая и станет нашей новой деталью.

function getUniqueWords (text) {    return unique(words(text))}const uniqueWords = getUniqueWords(text)

Сила композиции в том, что с её помощью можно создавать новые абстракции гораздо проще и удобнее:

// создаём новую деталь через композициюconst getUniqueWords = compose(unique, words)const uniqueWords = getUniqueWords(text)

Когда мы решим переиспользовать эту деталь и создать на её основе ещё одну более сложную сущность, композиция запросто с этим справится.

В примере ниже мы берём ранее созданную деталь и делаем новую функцию, которая будет не только находить уникальные слова, но ещё и сортировать их по алфавиту.

const sort = iter => [...iter].sort()// новая деталь, которая пригодится для новых построекconst getSortedUniqueWords = compose(sort, getUniqueWords)const sortedUniqueWords = getSortedUniqueWords(text)

Если речь идёт о конструировании сложных деталей, вложенную композицию можно заменить на линейную:

// вложенная композицияcompose(sort, compose(unique, words))// линейная композицияcompose(sort, unique, words)

Таким образом, композиция это не просто шаблон для организации потока вычислений, но и фабрика по производству новых деталей.

Бесточечный стиль

Его следовало бы назвать стилем без параметров, потому что когда говорят о бесточечном стиле, то под точкой подразумевается параметр функции.

Когда новая функция создаётся путём оборачивания другой функции, для передачи данных из внешней функции во внутреннюю требуется один или несколько параметров. Когда же мы используем композицию, необходимость в этом отпадает, потому что результат одной функции передаётся дальше по цепочке.

// стиль с параметрамиfunction getUniqueWords (text) {    return unique(words(text))}// стиль без параметров (бесточечный стиль)const getUniqueWords = compose(unique, words)

При работе со стилем без параметров функция не упоминает данные, которые мы обрабатываем.

В разработке есть две по-настоящему сложные проблемы: инвалидировать кеш и придумать названия для переменных. Композия не поможет решить задачу с кешем, но проблем с именованием параметров точно станет меньше.

Ограничения

Функция возвращает одно значение, следовательно, внутри конвейера или композиции мы можем передать дальше только один аргумент. Но как быть, если функция определена с несколькими параметрами, необходимыми для работы?

const translate => (lang, text) => magicSyncApi(lang, text)const getTranslatedWords = compose(translate, unique, words)getTranslatedWords(text) // упс... что-то сломалось

Здесь на помощь приходит частичное примирение и каррирование, о которых мы поговорим позже.

Пишем сами

Реализовать конвейер можно было бы так:

const pipe = (...fns) => (x) => fns.reduce((v, f) => f(v), x)

Чтобы реализовать композицию, достаточно заменить reduce на reduceRight:

const compose = (...fns) => (x) => fns.reduceRight((v, f) => f(v), x)

Как на практике?

На практике не так много случаев, где можно применить композицию. Кроме того, применимость ограничена отсутствием в JS встроенных механизмов нужно использовать библиотеки или самостоятельно реализовывать у себя необходимые функции. Но при этом, как ни странно, если вы используете на проекте Redux, ничего подключать не придётся, потому что композиция входит в состав библиотеки.

На проекте с Redux композиция наверняка будет использоваться для middleware, потому что createStore принимает только один усилитель (enhancer), а их, как правило, требуется хотя бы несколько.

// композиция в reduxconst store = createStore(    reducer,    compose(        applyMiddleware(...middleware),        DevTools.instrument(),    ))

Мы помним, что композиция направлена справа налево. Промежуточные слои, которые должны быть вызваны раньше других, помещаются правее или ниже. В примере выше DevTools добавляются до применения middleware, чтобы можно было корректно дебажить асинхронный код.

Другой кейс, где может пригодиться композиция фильтрация или преобразование потока данных:

const notifications = [    { text: 'Warning!', lang: 'en', closed: true },    { text: 'Внимание!', lang: 'ru', closed: false },    { text: 'Attention!', lang: 'en', closed: false }]// goodnotifications.filter((notification) => {    // ...проверить все условия})// betternotifications    .filter(isOpen)    .filter(isLang)// the bestcompose(    isLang,    isOpen)(notifications)

Частичное применение и каррирование

Преобразуют функцию с исходным набором параметров в другую функцию с меньшим числом параметров, но делают это по-разному.

Для демонстрации работы частичного применения и каррирования будем использовать такую незамысловатую функцию:

const sum = (x, y, z) =>    console.log(x + y + z)

Частичное применение

Преобразует функцию в одну функцию с меньшим числом параметров.

const partialSum = partial(sum, 8)partialSum(13, 21) // 42

Каррирование

Преобразует функцию в набор функций с единственным параметром.

const curriedSum = curry(sum)curriedSum(8)(13)(21) // 42

Несмотря на то, что в классическом понимании каррирование преобразует функцию в набор функций с единственным параметром, на практике реализации каррирования могут принимать несколько аргументов за раз:

curriedSum(8, 13)(21) // 42curriedSum(8, 13, 21) // 42

В чём разница?

Как мы уже выяснили, частичное применение преобразовывает функцию в одну единственную, в то время как каррирование преобразовывает её в набор функций. Это означает, что когда мы передаём аргументы в количестве меньшем, чем арность функции, при частичном применении происходит вызов функции:

const partialSum = partial(sum, 42)partialSum() // NaN, потому что 42 + undefined + undefined

В то время как каррирование будет возвращать новые функции до тех пор, пока не наберётся достаточное число аргументов.

const curriedSum = curry(sum)curriedSum(8) // новая функция  sum(8)curriedSum(8)(13) // ещё одна новая функция  sum(8, 13)curriedSum(8)(13)(21) // 42, потому что набралось нужное число аргументов

Можно провести аналогию: вы делаете заказ в ресторане. Если использовать частичное применение, официант задаст вам только один вопрос о том, что вы хотите заказать, и если вы ответите хочу пиццу, то остальное он додумает сам и принесёт ту пиццу, которую посчитает нужной.

В случае с каррированием официант, наоборот, будет задавать наводящие вопросы: какую именно пиццу вы хотите, на каком тесте, какого размера и т. д. То есть будет спрашивать до тех пор, пока не убедится, что вы сообщили всю необходимую информацию.

Решение задачи с композицией

Проблему с композицией из предыдущего примера при помощи частичного применения или каррирования можно решить вот так:

const translate => (lang, text) => magicSyncApi(lang, text)// через частичное применениеconst english = partial(translate, 'en')// через каррированиеconst english = curry(translate)('en')// создать новую деталь с возможностью переводаconst getTranslatedWords = compose(english, unique, words)getTranslatedWords(text) // теперь всё работает

Порядок данных

Частичное применение и каррирование чувствительны к порядку данных. Существует два подхода к порядку объявления параметров.

// сперва итерация, затем данные (iterate-first data-last)const translate => (lang, text) => /* */// сперва данные, затем итерация (data-first, iterate-last)const translate => (text, lang) => /* */

В обычном проекте вы вряд ли будете писать функции, где более специфические данные следует передавать в первую очередь, поэтому полезно держать под рукой хелпер для преобразования iterate-last в iterate-first. Его можно написать и применить вот так:

function flip (fn) {    return (...args) => fn(...args.reverse())}const curryRight = compose(curry, flip)const partialRight = compose(partial, flip)

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

Специализация

Кроме применения в композиции для настройки сигнатуры функции, у частичного применения и каррирования есть другая полезная особенность. С их помощью можно делать функции более специфичными. Например, мы хотим сделать запрос API:

const fetchApi = (baseUrl, path) =>    fetch(`${baseUrl}${path}`)        .then(res => res.json())

Затем понимаем, что хотим переиспользовать функцию для запроса данных с определённого адреса. В этом случае мы точно так же, как создавали детали через композицию, можем создать новую, но на этот раз более специфическую деталь при помощи каррирования или частичного применения.

// каррированиеconst fetchCurry = curry(fetchApi)const fetchUnsplash = fetchCurry('https://api.unsplash.com')const fetchRandomPhoto = fetchUnsplash(fetchApi, '/photos/random')// частичное применениеconst fetchUnsplash = partial(fetchApi, 'https://api.unsplash.com')const fetchRandomPhoto = partial(fetchUnsplash, '/photos/random')

Пишем сами

Свою версию частичного применения можно написать примерно так:

function partial (fn, ...apply) {    return (...args) => fn(...apply, ...args)}

Каррирование выглядит немного сложнее:

function curry (fn) {    return (...args) => args.length >= fn.length ?        fn(...args) : curry(fn.bind(null, ...args))}

Как на практике?

Две основные возможности частичного применения и каррирования: настройка функций для реализации композиции и специализация. Композиция используется редко, поэтому специализация является гораздо более полезной.

А ещё в JavaScript у функций есть метод .bind, который реализует частичное применение из коробки, поэтому, если порядок параметров позволяет, то вуаля:

const fetchApi = (baseUrl, endpoint) =>    fetch(`${baseUrl}${endpoint}`)        .then(res => res.json())const fetchUnsplash = fetchApi.bind(null, 'https://api.unsplash.com')const fetchRandomPhoto = fetchUnsplash.bind(null, '/photos/random')

Неизменяемые данные

Неизменяемые или иммутабельные данные устойчивы к изменениям (мутациям). Каждый раз, когда в данных требуется что-то изменить, создаётся копия, а исходники остаются без изменений. Этот подход помогает избежать досадных ошибок, но важно не забывать всегда использовать неизменяемые данные, когда это необходимо.

Для иллюстрации принципа работы неизменяемых данных подойдёт пример со стаканом. Представим, что у нас есть стакан с водой, из которого мы немного выпиваем, а через некоторое время делаем ещё один глоток. Стакан опустеет ровно настолько, сколько мы из него выпили. Это изменяемые данные.

// mutable glassconst takeGlass = (volume) => ({    look () { console.log(volume) },    drink (amount) {        volume = Math.max(volume - amount, 0)        return this    }})const mutable = takeGlass(100)mutable.drink(20).drink(30).look() // 50mutable.look() // 50

С неизменяемыми структурами данных совершенно другая история. Перед тем, как сделать глоток, создаётся точная копия стакана, и мы пьём уже из копии. Таким образом, после первого глотка у нас будет два стакана: один полный, из другого мы немного отпили. Исходный стакан останется без изменений. Это и есть неизменяемые данные.

// immutable glassconst takeGlass = (volume) => ({    look () { console.log(volume) },    drink (amount) {        return takeGlass(Math.max(volume - amount, 0))    }})const immutable = takeGlass(100)immutable.drink(20).drink(30).look() // 50immutable.look() // 100

Преимущества неизменяемых структур данных:
предсказуемое изменение состояния,
быстрое сравнение по ссылке,
кешируемость,
легко распараллеливать,
легко тестировать.

Но у неизменяемых структур есть два больших недостатка: нужно помнить о том, что данные надо копировать, когда это необходимо, и, соответственно, появляются затраты на копирование. Рассмотрим их подробнее.

Нечаянное мутирование данных

В JavaScript запросто можно нечаянно мутировать массив или любой другой объект:

function sortArray (array) {    return array.sort()}const fruits = ['orange', 'pineapple', 'apple']const sorted = sortArray(fruits)// упс... исходный массив тоже изменилсяconsole.log(fruits) // ['apple', 'orange', 'pineapple']console.log(sorted) // ['apple', 'orange', 'pineapple']

Мы можем попробовать защититься от этого, но есть проблема. Вещи, которые кажутся неизменяемыми, на самом деле таковыми не являются. Объявление через const защищает от изменений только ссылку, а сам объект остаётся открыт для мутаций.

const object = {}// const означает константную ссылкуobject = {} // TypeError: Assignment to constant variable// но сам объект можно беспрепятственно изменятьobject.value = 42 // мутация объекта

Все ссылочные типы: объекты, массивы и другие всегда передаются по ссылке. Во время присваивания или передачи параметра происходит копирование ссылки, но не самих данных.

const array = []// копия ссылкиconst ref = arrayref.push('apple')// ещё одна копия ссылкиconst append = (ref) => {   ref.push('orange')}append(array)// массив дважды мутирован через ссылкуconsole.log(array) // [ 'apple', 'orange' ]

А что если применить средства метапрограммирования и, например, заморозить объект? В этом случае мы всё равно сможем изменить вложенные объекты по ссылке.

const object = { val: 42, ref: {} }const frozen = Object.freeze(object)// игнорирование ошибки без 'use strict'// или же TypeError: Cannot assign to read only property...frozen.val = 23// мутирование вложенных данных по ссылкеfrozen.ref.boom = 'woops'console.log(frozen) // { val: 42, ref: { boom: 'woops' }

Вместо заморозки можно воспользоваться Proxy API, но в этом случае тоже придётся дополнительно обрабатывать вложенные структуры, потому что они всё ещё открыты для изменений.

const object = { val: 42, ref: {} }const proxy = new Proxy(object, {    set () { return true },    deleteProperty () { return true }})// изменение или удаление свойства не сработаетproxy.val = 19delete proxy.val// точно так же, как и добавление новогоproxy.newProp = 23// но вложенные объекты всё ещё мутабельныproxy.object.boom = 'woops'console.log(proxy) // { value: 42, ref: { boom: 'woops' } }

В общем, в JavaScript нельзя просто так взять и защитить данные от непреднамеренного изменения.

Затраты на копирование

С копированием данных тоже не всё так просто. В большинстве случаев работает копирование массивов и объектов встроенными средствами JavaScript:

const array = [4, 8, 15, 16, 23]const object = { val: 42 }// создать новый объект или массив[].concat(array)Object.assign({}, oject)// но через деструктуризацию удобнее[...array]{...object}

К сожалению, в этом случае создаётся поверхностная копия, поэтому мы избавляемся от мутаций только до тех пор, пока отсутствуют другие вложенные объекты:

const object = { val: 42, ref: {} }const copy = { ...object }copy.val = 23copy.ref.boom = 'woops'console.log(object) // { val: 42, ref: { boom: 'woops' }

Такая же история с функциональными методами массивов map и filter создают поверхностную копию исходного массива.

const array = [null, 42, {}]const copy = array.filter(Boolean)copy[0] = 23copy[1].boom = 'woops'console.log(array) // [ null, 42, { boom: 'woops' } ]console.log(copy) // [ 23, { boom: 'woops' }

Поэтому для создания полноценной копии нужна встроенная функция глубокого копирования, которая потребует дополнительных затрат. Реализовать глубокое копирование можно несколькими способами, подробнее о возможных вариантах читайте здесь:

The problems of shared mutable state and how to avoid them
What is the most efficient way to deep clone an object in JavaScript?

Неизменяемые структуры данных (persistent data structures)

Итак, с неизменяемостью в JavaScript всё сложно, но мы можем обойти существующие ограничения при помощи специальных структур данных. Если взять библиотеку, которая реализует неизменяемые структуры и воспользоваться ей у себя на проекте, мы получим два преимущества. Во-первых, будет гораздо сложнее нечаянно мутировать данные, потому что библиотека каждый раз самостоятельно создаёт копии. Во-вторых, под капотом, скорее всего, будут разного рода оптимизации для более эффективного копирования данных, как, например, копирование при записи, когда во время чтения данных используется общая копия, а в случае изменения создаётся новый объект.

Пожалуй, две самые популярные библиотеки в мире фронтенд разработки это Immutable и Immer. При помощи Immer мы можем сделать вот что:

import produce from 'immer';const object = { ref: { data: {} } };const immutable = produce(object, (draft) => {  draft.ref.boom = 'woops';});console.log(object) // { ref: { data: {} }console.log(immutable) // { ref: { data: {}, boom: 'woops' }console.log(object.ref.data === immutable.ref.data) // true

Да, нам всё равно приходится для изменения данных вызывать функцию produce, но это уже лучше, чем рассчитывать на отсутствие случайных мутаций. Кроме того, в режиме разработки Immer замораживает все объекты, которые возвращает produce, чтобы защитить разработчика от возможных нечаянных мутаций.

Как на практике?

Следует помнить об изменчивой природе ссылочных типов данных и точно знать какие методы мутирующие, а какие нет. Во многих случаях деструктуризации будет достаточно:

const addTodo = (state = initState, action) => {    switch (action.type) {        case ADD_TODO: {            return {                ...state,                todos: [...state.todos, action.todo]            }        }        default: {            return state;        }    }}

Но, как мне кажется, во многих других ситуациях неизменяемые структуры данных подойдут куда лучше:

import produce from 'immer'const addTodo = (state = initState, action) =>    produce(state, draft => {        switch (action.type) {            case ADD_TODO: {                draft.todos.push(action.todo)                break            }        }    })

Чистые функции (pure functions)

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

Чистые функции могут вызывать другие чистые функции, но если внутри цепочки вызовов попадётся хотя бы одна функция, которая не отвечает условиям чистоты, вся цепочка перестаёт быть чистой. Рассмотрим подробно каждое из условий, которым должны отвечать чистые функции.

Побочные эффекты (side effects)

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

function impure () {    // логирование    console.log('side effects')    // запись в файл    fs.writeFileSync('log.txt', `${new Date}\n`, 'utf8')    // запрос на сервер и т. д.    fetch('/analytics/pixel')}

Такие операции чем-то похожи на философский вопрос о звуке падающего дерева в лесу, когда рядом никого нет. Может показаться, что когда мы что-то логируем внутри функции, это никак не влияет на нашу программу. Если где-то падает дерево, но рядом никого нет, то и звука тоже не будет. Но если рассматривать звук как физическое явление колебаний воздуха, то оно произойдёт независимо от наличия наблюдателя. Точно так же вызов функции оставит логи на сервере или где-то ещё, даже если текущее состояние программы никак не изменится.

Работа с глобальными переменными тоже побочный эффект.

function impure () {    // глобальная переменная    app.state.hasError = true}

Как правило, изменение глобальных значений непосредственно влияет на текущее состояние приложения, в то время как операции ввода/вывода меняют что-то за пределами приложения. Но в веб-разработке всё вращается вокруг DOM. Это не только доступы и изменение глобальных переменных, но ещё и операции ввода/вывода. Получается, что фронтенд один сплошной побочный эффект. Другими словами, фронтенд замечателен тем, что совмещает в себе всё самое лучшее.

function impure () {    // модификация DOM    document.getElementById('menu').hidden = true    // установка обработчика    window.addEventListener('scroll', () => {})    // запись в локальное хранилище    localStorage.setItem('status', 'ok')}

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

Мутация данных внутри функции ещё одна разновидность побочных эффектов. Функция, которая мутирует данные, как бы оставляет след в виде изменений после вызова. Сложность в том, что многие встроенные функции JS по умолчанию мутируют данные. Если об этом забыть, можно нечаянно оставить после вызова функции след из побочных эффектов.

function impure (o) {    return Object.defineProperty(o, 'mark', {        value: true,        enumerable: true,    })}const object = {}const marked = impure(object)// defineProperty мутировала исходный объектconsole.log(object) // { mark: true }

Лучший способ избежать мутации данных использовать неизменяемые структуры данных.

Зависимость от параметров

Чистые функции зависят только от своих параметров. Если функция обращается к глобальной переменной или получает данные через операцию чтения данных извне, она теряет свою чистоту.

function impure () {    // глобальная переменная    if (NODE_ENV === 'development') { /* */ }    // чтение данных из DOM    const { value } = document.querySelector('.email')    // обращение к локальному хранилищу    const id = localStorage.getItem('sessionId')    // чтение из файла и т. д.    const text = fs.readFileSync('file.txt', 'utf8')}

Внешние зависимости можно заменить на зависимость от параметров.

Непредсказуемый результат

Чистые функции всегда возвращают один и тот же результат для одних и тех же параметров. Как только появляется непредсказуемость, функция теряет чистоту. Простой пример непредсказуемого результата работа со случайностью.

function impure (min, max) {    return Math.floor(Math.random() * (max - min + 1) + min)}impure(1, 10) // 4impure(1, 10) // 2

Чтобы сделать функцию чистой, достаточно вынести неопределённость за пределы функции и передать её в качестве параметра. Например, вот так:

function pure (min, max, random = Math.random()) {    return Math.floor(random * (max - min + 1) + min)}pure(1, 10, 0.42) // 5pure(1, 10, 0.42) // 5

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

Преимущества чистых функций

Их плюсы:
проще разобраться, как устроена функция,
их можно запросто кешировать,
легко тестировать,
легко распараллеливать.

Кроме того, они обладают ссылочной прозрачностью. Это эффект, который позволяет вместо вызова функции без особых трудностей подставить результат её работы.

const refTransparency = () =>    Math.pow(2, 5) + Math.sqrt(100)// вызов функцииrefTransparency()// можно раскрытьMath.pow(2, 5) + Math.sqrt(100)// и без особых трудностей понять результат32 + 10 // 42

Так почему бы всё не написать на чистых функциях?

Абсолютная и относительная чистота

Если взять и написать программу только из чистых функций, то получится:

(() => {})() // абсолютная чистота

Такая программа не делает ничего. Программа без побочных эффектов штука бесполезная. Мы пишем код ради побочных эффектов. Поэтому вместо того, чтобы полностью от них избавиться, нужно уменьшить их количество, изолировать оставшиеся в одном месте, а большинство функций сделать чистыми.

// побочные эффекты выносятся за пределыconst text = fs.readFileSync('file.txt', 'utf8')// функция получает нужные данные только через параметрыfunction pure (text) {    // ... чистота}

Кроме того, чистота относительна. Функция ниже чистая или нет?

// pure или impure?function circleArea (radius) {    return Math.PI * (radius ** 2)}

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

Заключение

Мне кажется, чистые функции одна из самых полезных и применимых методик, для которой не нужен ни функциональный язык, ни библиотеки. Достаточно по-новому взглянуть на свой код. Неизменяемые данные тоже хороши, но для работы с ними потребуются дополнительные библиотеки. Да и остальные концепции тоже можно использовать, но реже.

В статье мы рассмотрели базовые концепции ФП, однако на этом всё не заканчивается. Если у вас есть желание погружаться в тему дальше, советую почитать:

Жаргон функционального программирования
Functional-Light JavaScript
Mostly adequate guide to Functional Programming

Кроме того, загляните в репозиторий Awesome FP JS, вдруг найдёте что-то интересное для себя. Если же захочется целиком погрузиться в функциональную парадигму, но при этом продолжать разрабатывать фронтенд, можно посмотреть в сторону Ramda или Elm.

Спасибо за внимание!

Среди отзывов, полученных мной после этого доклада, занявшего второе место по полезности по результатам опроса после конференции, был такой: Краткий пересказ документации Workbox. Что ж, в какой-то степени это действительно так: я рассказал пошаговую историю превращения обычного веб-приложения в прогрессивное с помощью этой замечательной библиотеки. Буду очень рад, если доклад и конспект вдохновят вас и помогут начать ваше собственное путешествие в мир сервис-воркеров и PWA.

• Действительно, почему бы не сделать так, что веб-приложения будут доступны всегда, вне зависимости от статуса подключения, если соответствующие API имеются?
• Почему бы не настроить действительно умное кеширование и переиспользовать данные, которые мы когда-либо загрузили?
• Почему бы не сделать так, что действия пользователей, которые они совершили офлайн, никуда не пропадают, а тщательно записываются и, если нужно, отправляются на сервера автоматически при первой возможности подключения. Например, для аналитики это очень важно?
• Если соединение нестабильно, почему бы не сделать так, чтобы это не нарушало пользовательский опыт? Все возможности имеются.
• Следующая идея обновление приложения и данных, которые использует приложение. К этому мы привыкли при использовании нативных мобильных приложений. То есть они где-то в фоне себя потихоньку обновляют, так что мы всегда работаем с самой последней версией.
• Кроме того, современные устройства оснащены массой интересных API и аппаратных, и программных, так что не использовать их странно, если это релевантно для конкретного приложения и конкретного бизнес-сценария.

• Уровень абстракций настолько комфортен для разработчика, насколько это возможно. У нас все еще есть полный контроль, полное понимание того, что именно мы делаем то есть не ждите большой кнопки сделать круто. При этом мы избавлены от копания в глубоких технических деталях HTTP-запросов, алгоритмов кеширования, если нам это не нужно. Если нужно, то можем опуститься и на этот уровень.
• Где уместно, возвращается декларативность, применимая к идее кеширования, что тоже очень значительно упрощает и делает комфортной саму разработку.
• Модульность помогает нам и системам сборки оптимизировать размер итогового файла сервис-воркера, неиспользуемый код не окажется в production.
• Если нужно, мы всегда можем расширить текущие модули и текущие методы.
• Функциональность из коробки настолько широка, что покроет, я думаю, процентов 90 всех возможных сценариев, которые потребуются при создании, в частности, офлайн-приложения.
• Мощный инструментарий: инструменты командной строки, модули для Node, плагины для систем сборки.
• Очень важный момент бесплатность, открытый исходный код, активная разработка и поддержка со стороны Google и сообщества разработчиков.

Синтаксис

Отношение типов

Управляющие конструкции

Как технически реализовать микрофронтенды/виджеты?

declare const DoggyWidget: {    init: ({        container: HTMLElement,    }) => DoggyWidgetInstance;}declare interface DoggyWidgetInstance {    destroy(): void;    updateDoggy(): void;}

<script>

class Widget {    constructor({ container }) {        this.container = container;        container.classList.add('doggy-widget');        this._renderImg();        this._renderBtn();        this.updateDoggy();    } }

    _renderImg() {        this.img = document.createElement('img');        this.img.classList.add('doggy-widget__img');        this.img.alt = 'doggy';        this.container.appendChild(this.img);    }

    _renderBtn() {        this.btn = document.createElement('button');        this.btn.classList.add('doggy-widget__btn');        this.btn.addEventListener('click', () => this.updateDoggy());        this.container.appendChild(this.btn);        this.btn.innerText = 'New doggy!';    } 

    updateDoggy() {        const { width, height } = this.container.getBoundingClientRect();        const src = `https://placedog.net/${width - 10}/${height - 10}?random=${Math.random()}`;        this.img.src = src;    }

    destroy() {        this.container.innerHTML = '';        this.container.classList.remove('doggy-widget');    }

(() => {    class Widget {        ...    }    window.DoggyWidget = {        init(config) {            return new Widget(config);        }    }})();

<script src="doggy-widget.js"></script><link rel="stylesheet" href="doggy-widget.css"><div id="widget-1"></div><div id="widget-2"></div><script>    const widget1 = DoggyWidget.init({         container: document.getElementById('widget-1'),    });    const widget2 = DoggyWidget.init({         container: document.getElementById('widget-2'),    });</script>

        * {            font-family:         Arial, Helvetica, sans-serif !important;            font-size: 10px !important;        }

<link rel="stylesheet"       href="bootstrap.min.css">*, ::after, ::before {    box-sizing: border-box;}

<body>  <div class="blah">      <!-- general content is not affected -->      <div class="myContainer cleanslate">          <!-- this content will be reset -->      </div>  </div></body>

    constructor({ container }) {        this.shadowRoot = container.attachShadow(            { mode: 'open' }        );        this.innerContainer = document.createElement('div');        this.innerContainer.classList.add('doggy-widget');        this.shadowRoot.appendChild(this.innerContainer);            }

    _renderImg() {                this.innerContainer.appendChild(this.img);    }    _renderBtn() {                this.innerContainer.appendChild(this.btn);    }

    destroy() {                this.shadowRoot.innerHTML = '';    } 

     constructor() {                const link = document.createElement('link');        link.rel = 'stylesheet';        link.href = 'doggy-widget.css';        this.shadowRoot.appendChild(link);            }

<script src="doggy-widget.js"></script>

<link rel="stylesheet" href="doggy-widget.css">

var str = JSON.stringify(['haha'])> '["haha"]'JSON.parse(str)> ["haha"]

var str = JSON.stringify(['haha'])> '"[\"haha\"]"'JSON.parse(str)> '["haha"]'

Array.prototype.toJSON: () => Object

Array.prototype.toJSON = function () {    var c = [];    this.each(function (a) {        var b = Object.toJSON(a);        if (!Object.isUndefined(b))            c.push(b)    });    return '[' + c.join(', ') + ']'}

var _json_stringify = JSON.stringify;JSON.stringify = function(value) {    var _array_tojson = Array.prototype.toJSON;    delete Array.prototype.toJSON;    var r=_json_stringify(value);    Array.prototype.toJSON = _array_tojson;    return r;};

    _renderImg() {        const img = document.createElement(img');        this.img = img;        img.classList.add('doggy-widget__img');        img.alt = 'doggy';        this.container.appendChild(this.img);         this.updateDoggy(img);    }

window.addEventListener('error', (e) => {    console.log('got error:', e.error);    e.preventDefault();});

window.addEventListener('unhandledrejection', (e) => {    console.log('got promise reject:', e.reason);    e.preventDefault();});

Promise.reject(new Error('bla'))

window.addEventListener('error', (e) => {    console.log('got error:', e.error);    e.preventDefault();});

<iframe>

(() => {    window.DoggyWidget = {        init({ container }) {            const iframe = document.createElement('iframe');        }    }})();

(() => {    window.DoggyWidget = {        init({ container }) {            const iframe = document.createElement('iframe');            iframe.style.width = '100%';            iframe.style.height = '100%';            iframe.style.borderWidth = 0;            iframe.style.display = 'block';            iframe.src = 'https://some-url/doggy-widget.html';                    }    }})();

(() => {    window.DoggyWidget = {        init({ container }) {            const iframe = document.createElement(iframe');            iframe.style.width = '100%';            iframe.style.height = '100%';            iframe.style.borderWidth = 0;            iframe.style.display = 'block';            iframe.src = 'https://some-url/doggy-widget.html';            container.appendChild(iframe);                        ...        }    }})();

declare const DoggyWidget: {    init: ({        container: HTMLElement,    }) => DoggyWidgetInstance;}declare interface DoggyWidgetInstance {    destroy(): void;    updateDoggy(): void;}

destroy() {    this.container.innerHTML = '';}

destroy() {    // чистим iframe для ie11 и legacy edge     this.iframe.src = '';    this.container.innerHTML = '';}

updateDoggy() {    this.iframe.contentWindow        .postMessage({ command: 'updateDoggy' });}

window.addEventListener('message', (e) => {    if (e.data.command === 'updateDoggy') {        widget.updateDoggy();    }})

https://website.ru/    https://yastatic.net/react/16.8.4/react-with-dom.min.js    Widget #1        <iframe> https://widget-1.ru/            https://yastatic.net/react/16.8.4/react-with-dom.min.js    Widget #2        <iframe> https://widget-2.ru/            https://yastatic.net/react/16.8.4/react-with-dom.min.js

const globalOne = window;let iframe = document.createElement('iframe');document.body.appendChild(iframe);const globalTwo = iframe.contentWindow;

window.someMethod = () => {...}

const script = document.createElement(script);script.src = 'foobar.js';globalTwo.head.appendChild(script);

globalTwo.postMessage();

globalTwo.someMethod();

const iframe = document.createElement('iframe');document.head.appendChild(iframe);const script = document.createElement('script');script.src = 'doggy-widget-inner.js';const loaded = new Promise((resolve) => {    script.onload = resolve;});loaded.then(() => {    iframe.contentWindow.init(config);})iframe.contentDocument.head.appendChild(script);

window.init = (config) => {    const widget = new Widget(config);    window.widget = widget;};

<head>    <iframe>        #document            <html>                <head>                    <script src="doggy-widget-inner.js"></script>                </head>                <body></body>            </html>    </iframe>    <iframe>        #document            <html>                <head>                    <script src="doggy-widget-inner.js"></script>                </head>                <body></body>            </html>    </iframe></head><body>    <div id="widget-1">        #shadow-root            <link rel="stylesheet" href="doggy-widget.css">            <div class="doggy-widget">                <img class="doggy-widget__img"/>                <button class="doggy-widget__btn"/>            </div>    </div>    <div id="widget-2">        #shadow-root            <link rel="stylesheet" href="doggy-widget.css">            <div class="doggy-widget">                <img class="doggy-widget__img"/>                <button class="doggy-widget__btn"/>            </div>    </div>    <script src="doggy-widget.js"></script></body>

• Полную изоляцию наших виджетов в CSS, потому что используем Shadow DOM.
• Полную изоляцию в JS, потому что код работает внутри выделенного iframe, и какой-либо monkey-patching в родительском документе на него никак не влияет.
• Независимые мониторинги, потому что код виджета работает, опять-таки, в независимом window, где мы можем слушать эксепшены.
• Работающее кеширование, так как контекст same-origin в браузере больше не изолирует кеши между виджетами.

• Некоторое усложнение кода. Загрузка становится асинхронной, но гораздо лучше использовать асинхронное взаимодействие, в отличие от секьюрного фрейма, где мы использовали постмесседжи.
• Небольшие накладные расходы запрос за дополнительным js-файлом, который загружается внутрь iframe.
• Необходимость в дополнительных ресурсах. Требуются дополнительные ресурсы браузера и устройства пользователя на работу отдельного контекста iframe, но они сильно меньше, чем у секьюрного фрейма.

const globalOne = window;let iframe = document.createElement('iframe');document.body.appendChild(iframe);const globalTwo = iframe.contentWindow;

const globalOne = window;const globalTwo = new Realm().globalThis;

const realm = new Realm();const { doSomething } = await realm.import(    ./file.js');doSomething();

Итоги

Зачем мы всё это делали

Как выглядит платформа

Архитектура

Отказоустойчивость

История первая про Яндекс.Ровер

История вторая про базы данных

1. дойти до всех клиентов, обеспечить обратную совместимость;
2. выкатить новый API, всех клиентов переключить на новый API;
3. выпилить старый код о клиентах, выпилить старый код на бэкенде.

История третья про качество

Что мы сделали в офлайне

Итоги

Технические вызовы при создании супераппа

UX супераппа. Айсберги на горизонте

Веб в целом как суперапп

О преждевременной оптимизации

React

Лишние ререндеры

const Foo = () => (    <Consumer>{({foo, update}) => (...)}</Consumer>);const Bar = () => (    <Consumer>{({bar, update}) => (...)}</Consumer>);const App = () => (    <Provider value={...}>        <Foo />        <Bar />    </Provider>);

• Пакет Why Did You Render. Это must have в любом проекте, у любого разработчика на React.
• В Developer Tools браузера Chrome можно включить опцию Paint flashing. Тогда он будет подсвечивать те области экрана, которые перерисовались. Вы визуально заметите, что и как часто у вас ререндерится.
• Самое убойное средство это в каждый рендер вставить console.log. Это позволяет оценить, сколько вообще у вас ререндеров: и нужных, и ненужных.
• И еще одна вещь: часто забываемый второй параметр в React.memo. Это функция, которая позволит вручную написать код сравнения props с предыдущими и самому возвращать true/false, то есть дополнительно к сравнению по ссылке сравнивать какое-то содержимое. Функция аналогична методу shouldComponentUpdate для классовых компонентов.

HTML-комментарии

ReactDOMServer.renderToString(    <div>{someVar}bar</div>);<div data-reactroot="">foo<!-- -->bar</div>

ReactDOMServer.renderToString(    <div>{`${someVar}bar`}</div>);<div data-reactroot="">foobar</div>

HOC

function withEmptyFc(WrappedComponent) {    return props => <WrappedComponent {...props} />;}function withEmptyCc(WrappedComponent) {    class EmptyHoc extends React.Component {        render() {            return <WrappedComponent {...this.props} />;        }    }    return EmptyHoc;}

switch (workInProgress.tag) {  case IndeterminateComponent: {    //     return mountIndeterminateComponent();  }  case FunctionComponent: {    //     return updateFunctionComponent();  }  case ClassComponent: {    //     return updateClassComponent();  }

Изоморфный код

TypeScript

Дизайн языка

Spread operator

// TS:res = {...obj, a: 1};// компилируется в ES5:res = __assign(__assign({}, obj), {a: 1});// хотелось бы:res = __assign({}, obj, {a: 1});// илиres = __assign({}, obj);res.a = 1;

Rest operator

var blackList = ['prop1', 'prop2', 'prop3'];var otherProps = {};// Цикл по всем полямfor (var p in props)    if (        hasOwnProperty(props, p) &&        // Вложенный цикл  поиск в массиве indexOf(p)        blackList.indexOf(p) < 0    )        otherProps[p] = props[p];

// хотелось бы ES5:Component.prototype.fn1 = function(path) {    utils.fn2.apply(utils, arguments);};

// получаем замедление в ES5:Component.prototype.fn1 = function(path) {    var vars = [];    for (var _i = 1; _i < arguments.length; _i++) {        vars[_i - 1] = arguments[_i];    }    utils.fn2.apply(utils, __spreadArrays([path], vars));};

=> вместо bind

• Самый очевидный минус: каждый конструктор тратит время на создание этой новой функции.
• Ее код не шарится между экземплярами. Он существует в стольких же экземплярах, сколько у вас создано экземпляров MyComponent.
• Вместо N вызовов одной функции вы получаете по одному вызову N функций в каждом из независимых экземпляров. То есть оптимизатор на такую функцию внимания не обращает, не хочет ее инлайнить или оптимизировать. Она выполняется медленно.

• Если в классе-потомке мы создадим метод onClick, он будет затерт в конструкторе предка.
• Если мы все-таки как-то создадим метод, то все равно не сможем вызвать super.onClick, потому что на прототипе метода не существует.
• Хоть как-то переопределить onClick в классе-потомке, опять же, можно только через стрелочную функцию.

@boundMethod вместо bind

import {boundMethod} from 'autobind-decorator';class Component {    @boundMethod    method(): number {        return this.value;    }}

const boundFn = fn.bind(this);Object.defineProperty(this, key, {    get() {        return boundFn;    },    set(value) {        fn = value;        delete this[key];    }});

class Base extends Component {    @boundMethod    method() {}}class Child extends Base {    method = debounce(super.method, 100);}

TL;DR

• Если вы заранее думаете над кодом и не выбираете заведомо неудачные варианты, которые работают плохо и медленно, это не преждевременная оптимизация. Это, наоборот, хорошо.
• Когда вы делаете осознанный выбор, скорость или красота кода, это тоже хорошо, если ваш выбор осознан.
• Очень плохо, если вы в принципе не умеете делать выбор, потому что не видите разных вариантов решения или не знаете, как писать производительный код, или не понимаете разницу в скорости работы вашего кода.

1. Siri это круто. Можно идти в плохую погоду, например по ужасному морозу, и говорить, что нужно включить, что лайкнуть, что дизлайкнуть.
2. Siri неплохо задокументирована, почти без багов. Я никаких серьезных багов сегодня не приводил.
3. Если у вас тип сущности содержится в названии этой сущности, то вы страдаете вместе с нами.

// Поток-производительData_t g_data1, g_data2, g_data3;bool g_flagg_data1 = calc1();g_data2 = calc2();g_data3 = calc3();g_flag = true; // Сигнализируем, что данные можно использовать.

// Поток-потребительif (g_flag) {  DoSomething(g_data1, g_data1, g_data2, g_data3);

1. Объявить g_flag как volatile. Это не позволит компилятору пропустить чтение/запись g_flag, но, к удивлению многих, не избавит от основной проблемы перестановки. Компиляторам запрещено переставлять инструкции чтения/записи volatile-переменных относительно друг друга, но разрешено переставлять их относительно обычных инструкций чтения/записи. То, что мы добавили volatile, никак не решает нашу проблему перестановок (/volatile:ms на VC ++ решает, но это нестандартное расширение языка, из-за которого код будет выполняться медленнее).
2. Если недостаточно объявить g_flag как volatile, тогда давайте попробуем объявить все четыре переменные как volatile! Тогда компилятор не сможет изменить порядок записи и наш код будет работать на некоторых компьютерах.

g_data1 = calc1();g_data2 = calc2();g_data3 = calc3();_ReadWriteBarrier(); // Только для VC++ и уже deprecated, но для 2005 это окей.g_flag = true; // Сигнализируем, что данные можно использовать.

g_data1 = calc1();g_data2 = calc2();g_data3 = calc3();MemoryBarrier(); // Дорогостоящий полный барьер памяти (full memory barrier). Только для Windows.g_flag = true; // Сигнализируем, что данные можно использовать.

#ifdef X86_OR_X64#define GenericBarrier _ReadWriteBarrier#else#define GenericBarrier MemoryBarrier#endifg_data1 = calc1();g_data2 = calc2();g_data3 = calc3();GenericBarrier(); // И почему мне пришлось самому это писать?g_flag = true; // Сигнализируем, что данные можно использовать.

// Поток-производительData_t g_data1, g_data2, g_data3;std::atomic<bool> g_flag // Обратите внимание!g_data1 = calc1();g_data2 = calc2();g_data3 = calc3();g_flag = true; // Сигнализируем, что данные можно использовать.

// Поток-производительData_t g_data1, g_data2, g_data3;std::atomic<bool> g_flagg_data1 = calc1();g_data2 = calc2();g_data3 = calc3();g_flag.store(true, std::memory_order_release);

// Поток-потребительif (g_flag.load(std::memory_order_acquire)) {  DoSomething(g_data1, g_data1, g_data2, g_data3);

• Не забывайте оптимизировать свой код на Python. Это первое, что нужно делать всегда, когда кажется, что что-то может происходить быстрее.
• Если вы провели оптимизацию, попробуйте сторонние библиотеки, которые содержат написанное с помощью C и C++ Extension или с помощью Rust. Возвращаясь немного назад, ujson не самая быстрая библиотека, есть быстрее: orjson, njson. Попробуйте их.
• И если ваша задача довольно узкая или вам хочется сделать что-то свое, пишите свои расширения, изучайте новые языки для этих расширений. Развивайтесь.

Присказка

Сказка

Жизнь

1. Релизы

2. Feature toggles

if (configurationService.isBooleanEnabled(NEW_FEATURE_ENABLED)) {    //new feature here} else {        //old logic}

public class User {    private Map<String, UserProperty> properties = new HashMap<>();    String getPropertyValue(String key) {        UserPropertyEntity userProperty = properties.get(key);        return userProperty == null ? null : userProperty.getValue();    }}

3. Метрики и мониторинги

@RestController@RequiredArgsConstructorpublic class MonitoringController {    private final ComplexMonitoring generalMonitoring;    private final ComplexMonitoring pingMonitoring;    @RequestMapping(value = "/ping")    public String ping() {        return pingMonitoring.getResult();    }    @RequestMapping(value = "/monitoring")    public String monitoring() {        return generalMonitoring.getResult();    }}

public enum MonitoringStatus { OK, WARNING, CRITICAL;}@RequiredArgsConstructorpublic class MonitoringEvent { private final String name; private volatile long validTill; private volatile MonitoringStatus status;}

public interface ComplexMonitoring { void addTemporary(String name, MonitoringStatus status, long validTillMilis); Result getResult(); //тут можно делать проверку для статусов в MonitoringEvent} 

public class MetricQueryRealJobExecutor { private static final RowMapper<Metric> METRIC_ROW_MAPPER = BeanPropertyRowMapper.newInstance(Metric.class); private final JdbcTemplate jdbcTemplate; public void doJob(MetricQuery task) { List<Metric> metrics = jdbcTemplate.query(task.getQuery(), METRIC_ROW_MAPPER); metrics.forEach(metric -> KEY_VALUE_LOG.info(KeyValueLogFormat.format(metric)) ); } @Data private static class Metric { private String key; private double value; }} 

• Плохой код не должен попадать в продакшен, для этого мы ставим всевозможные преграды: тесты, стрельбы, мониторинги. Задача без тестов не считается сделанной. Лучше заниматься оптимизацией работы тестов, чем получить проблему в продакшене.
• Feature toggles помогают нам управлять логикой работы бэкенда, а мы, в свою очередь, можем легко управлять toggles, и их плюсы все-таки перевешивают минусы.
• Мы должны уметь быстро обнаруживать проблему, в идеале раньше, чем ее заметят наши пользователи. Но ее мало обнаружить, нужно еще ее интерпретировать. Поэтому собирайте много метрик о состоянии системы. Это помогает в поиске проблемы.

Обычный рабочий процесс

std::string sample(int d, std::string (*cb)(int, std::string)) {  // Getting new descriptors from d with a timeout  auto result = get(d, 1000);  if (result != -13) {    // Descriptor is fine, processing with non bulk options    auto data = process(result, true, false, true);    // Passing processing result to the callback    return cb(data.second.first, data.second.second);  }  // Notifying callback on error  return cb(result, {});}

enum class Descriptor : int {};std::string sample(Descriptor d, std::string (*cb)(Descriptor, std::string)) {  // Getting new descriptors from d with a timeout  auto result = get(d, 1000);  if (result != Descriptor(-13)) {    // Descriptor is fine, processing with non bulk options    auto data = process(result, true, false, true);  // <== ERROR    // Passing processing result to the callback    return cb(data.second.first, data.second.second);  // <== ERROR  }  // Notifying callback on error  return cb(result, {});}

Боль

std::pair<Descriptor, std::pair<int, std::string>> process(bool, Descriptor, bool, bool);

Выжимка проблем

• Код написан на двух языках:
  Его в два раза больше.
  При отладке возникают проблемы со сверкой двух языков.
  

• Комментариев всё ещё недостаточно:
  Приходится читать код смежных функций.
  Есть магические константы.
  

• Код обработки ошибок и основной логики перемешаны:
  Большие блоки кода с большими отступами.
  

Читаемый код

std::string Sample(Descriptor listener,                              std::string (*cb)(Descriptor, std::string)){  UASSERT_MSG(cb, "Callback must be a non-zero function pointer");  const auto new_descriptor = Accept(listener, kAcceptTimeout);  if (new_descriptor == kBadDescriptor) {    return cb(kBadDescriptor, {});  }  auto data = Process(Options::kSync, new_descriptor);  return cb(data.descriptor, data.payload);}

Приёмы

Compute(payload, kComputeTimeout)

Compute(payload=payload, timeout=1023);

Compute({.payload=payload, .timeout=1023});

Compute(payload=payload, timeout=MAX_TEST_RUN_TIME);

Compute(payload, Device::kGPU)

Compute(payload=payload, is_cpu=False);

Compute(data.node_id, data.chunk_id)

std::tuple<int, std::string> Receive();

struct Response {    int pending_bytes;    std::string payload;};Response Receive();

void Accept(Descriptor, std::chrono::milliseconds)

def Accept(listener: Descriptor, timeout: datetime.timedelta) -> None:

namespace detail { void Compute(Data data); }

def _compute(data: Data) -> None:

descriptor, callback, mutator, GetDestination

connection_ = address.Connect(kTimeout);

self._connection = address.Connect(TIMEOUT);

ASSERT(attempts > 0);

assert timeout > 0

if (attempts <= 0) throw NegativeAttempts();

if (attempts <= 0) raise NegativeAttempts();

ASSERT(attempts > 0);if (attempts <= 0) throw NegativeAttempts();

if (value != BAD) {    auto a = foo(value);    auto b = bar(value);    if (a + b < 0) {         return a * b;    } else {         return a / b + baz();    }}return 0;

if (value == BAD) {    return 0;}auto a = foo(value);auto b = bar(value);if (a + b < 0) {     return a * b;}return a / b + baz();

Вместо заключения

Intro

Контекст

Линейные сценарии

Конечный автомат

Цепи Маркова

Outro

• Хорошая статья на Smashing Magazine про state-машины, там хорошо описано, как они работают поверх Redux.
• Цепи Маркова, краткое объяснение довольно простым языком на Brilliant.
• И очень хорошая видеолекция от профессора из MIT, в которой очень хорошо рассказывается математический аппарат цепей Маркова.

Технологии, основанные на квантовых эффектах, обладают интересной двойственностью: с одной стороны, они давно стали реальностью (достаточно вспомнить о транзисторах и лазерах) и продолжают активно развиваться; с другой стороны, непросто вспомнить, какие значимые результаты получили широкую огласку в последние годы. Почти наверняка большинство читателей так же, как и я, вспомнят разве что объявление о достижении квантового превосходства. Но там до конца так и не было ясно, случилось оно или не случилось.

И всё же прогресс в квантовых технологиях заметен хотя бы по тому, какое внимание им уделяют крупнейшие корпорации. IBM ещё в 2018 году рапортовали о сотне тысяч пользователей платформы Quantum Experience, Microsoft создаёт quantum development kit, и даже J.P. Morgan пытается развить в компании quantum culture. Любопытно, что сейчас всё больше говорят о связи квантовых вычислений и искусственного интеллекта.

В конце ноября 2020 года я встретился с Алексеем Фёдоровым, одним из ведущих российских специалистов в области квантовых технологий, автором десятков научных публикаций, руководителем научной группы Российского квантового центра, профессором МФТИ и обладателем бесчисленного множества других регалий. Он многое рассказал о состоянии современной квантовой науки, о грядущих технологических внедрениях и об интересных задачах, которые можно решать прямо сейчас. Видеозапись интервью смотрите на YouTube, там же доступна и запись последующего доклада на конференции YaTalks.

Про Алексея Фёдорова

Алексей Шаграев: Расскажи, пожалуйста, кем ты работаешь, чем занимаешься?

Алексей Фёдоров: Я руководитель научной группы Российского квантового центра (rqc.ru), и это означает, что я занимаюсь научными исследованиями в области квантовых информационных технологий. Мы активно развиваем два направления: квантовые коммуникации и квантовые вычисления. Вторая большая часть моей жизни преподавание: я преподаю на Физтехе курс Введение в современные квантовые технологии.

Ты попадал в какое-то бесчисленное количество рейтингов, например, в рейтинг Forbes 30 до 30. Как туда попадают и что это за рейтинги?

За 20192020 год я обнаружил себя в нескольких списках. Первый из них список Forbes по науке и технологиям. Как туда попасть сложный вопрос. Мне кажется, что туда попали в основном люди, за которыми действительно что-то числится и они при этом умело продвигали свои результаты (мне всегда очень помогал Российский квантовый центр). Все ребята, которые попадают в эти списки, судя по тому, что я вижу, активно работают над популяризацией достигнутых результатов, маркетингом и так далее.

Второй интересный список список Илонов Масков администрации Президента. Мне позвонили и говорят: Вас назвали в качестве одного из российских Илонов Масков. Я говорю: Ничего себе. А кого ещё?. И оказалось, что там длинный список очень крутых людей. Безусловно, это приятно. И, конечно, Илон Маск культовая личность. Часто проводят аналогию между квантовой и космической гонками, квантами и ядерной гонкой. Мы знаем, что Илон Маск занимается космосом, очень большим технологическим проектом, в котором с первого взгляда кажется, что всё бесконечно сложно и далеко от рынка. На кванты часто смотрят так же, поэтому сравнение с Илоном Маском приятное. Если удастся что-то в том же масштабе, в котором он сделал для космоса, сделать для квантов это будет очень круто. Так что это авансом, но очень крутой ориентир.

Что ты делал для того, чтобы популяризовать свою область?

Тут нужно сказать о Российском квантовом центре организации, где я работаю. Это очень необычная форма организации науки в России частный научный институт. Мы привыкли, что в России науку развивают университеты, институты академии наук, оборонная промышленность, какие-то отраслевые институты. А квантовый центр частный институт на площадке Сколково. Поэтому Центру, чтобы существовать, чтобы быть узнаваемым, важно заниматься популяризацией науки, объяснять обществу важность достигаемых результатов. Я работаю в Российском квантовом центре уже около 8 лет. Популяризация науки часть нашего ДНК, часть нашей культуры не просто достигать результатов, но и рассказывать обществу, в чём состоит их важность.

Мы рассказывали научному сообществу, в чём состоят научные достижения; технологическому сообществу в чём плюсы от внедрения квантовых технологии; обществу какие большие вызовы будущего решат квантовые технологии.

Про науку, приложения, квантовое превосходство, передачу информации и искусственный интеллект

Многим хорошо известно самое начало становления квантовой физики. А что произошло в последнее время, какие практические результаты нужно знать каждому, кто интересуется темой?

Квантовая механика возникла как научная теория в попытках объяснить необъяснённые на тот момент физические явления. Из этого произросла новая система взглядов на то, как устроен наш мир. Довольно быстро возникли идеи о том, как разрабатывать новые приборы и устройства, основанные на квантовых эффектах. Эти устройства мы все знаем: классическая IT-техника работает на транзисторах и интегральных схемах, которые не возникли бы, если бы не квантовая теория твёрдого тела и всё, что с ней связано.

Важным событием стало появление лазера. Лазеры, транзисторы и многие другие приборы, которыми мы сегодня активно пользуемся, основаны на коллективных квантовых явлениях, где одновременно происходит управление большим количеством квантовых систем: в лазере много частиц света (фотонов), настолько много, что мы можем видеть лазерный луч. При этом природа появления этого лазерного излучения квантовая, но она имеет, как говорят, макроскопические проявления.

Качественный скачок произошёл за последние 3040 лет. Мы научились приготавливать состояния отдельных квантовых объектов, а затем и управлять ими. Можно, например, изолировать один атом (точнее, создать условия, при которых он будет изолирован), контролировать степени свободы этого атома, кодировать в них информацию, использовать для каких-то интересных приложений. То же самое произошло с другими квантовыми объектами: частицами света фотонами. Из квантово-оптических экспериментов, в которых создавались отдельные состояния света и проводилось манипулирование ими, кстати, возникла вся область квантовой криптографии.

Сейчас в дополнение к коллективным квантовым явлениям существует возможность управлять индивидуальными квантовыми свойствами и создавать принципиально новые технологии, приборы и устройства, а с другой стороны открывать новые тонкие эффекты, которые были нам недоступны раньше.

В классическом искусственном интеллекте, которым занимаюсь я, жизнь устроена так: есть научные центры, где обычно не очень хорошо с данными, но очень хорошо именно с наукой, анализом. При этом есть коммерческие центры, большие компании, у которых очень много данных, на которых они получают интересные практические результаты, но их сложно воспроизвести из-за закрытости датасетов. В зависимости от того, чем тебе интереснее заниматься, ты идёшь делать науку в институт или работать в коммерческую корпорацию. А как в квантовых технологиях? Кто и как их развивает?

Не так давно наступил переломный момент. В течение последних десятилетий большинство результатов было получено в лабораториях и научных центрах; первые эксперименты научные публикации европейских, американских, российских, японских, китайских лабораторий. А в последние 5-10 лет мы видим очень активное вовлечение в квантовую гонку компаний, в основном из области IT, как раз во многом тех же, что развивают искусственный интеллект.

Если смотреть сейчас на главные технологические достижения, связанные с квантовыми компьютерами, то их обеспечивают Google, IBM, Intel, Microsoft, Amazon и другие компании. Сейчас действительно переломный момент: будет возникать конкуренция или коллаборация? Пока это до конца не ясно. Крупные компании (тот же Google) сотрудничают с университетами и научными центрами, работают над совместными научными публикациями. Но в какой мере корпорация сможет продолжать коллаборации, когда станет более заинтересована в экономическом эффекте это вопрос. Сейчас наука развивается и в университетах, и в частных компаниях, так что между ними наблюдается конкуренция за получение результатов.

Что касается национальных особенностей, то в США наиболее сильна частная экспертиза и крупнейшие компании финансируют собственные исследования; в Европе фокус на развитии технологий в университетах; в России же достаточно масштабную работу ведут госкорпорации. Квантовыми вычислениями занимается Росатом и не так давно созданный консорциум Национальная квантовая лаборатория, коммуникациями РЖД, сенсорами Ростех.

Наверное, одно из самых заметных событий, произошедших за последнее время объявление о достижении квантового превосходства. Но при этом не очень понятно: оно действительно произошло или всё-таки не очень? Да и вообще, что это такое?

Здесь, возвращаясь к предыдущему вопросу, замечу, что это достижение компании Google. Это достаточно значимое достижение с точки зрения науки я постараюсь объяснить, почему это важно произошло не в университете, не в научном центре, а в основном усилиями крупной компании, с привлечением, конечно, научных лабораторий.

Что такое квантовое превосходство? Довольно долго это была абстрактная концепция, введённая физиками. Суть квантового превосходства в обозначении момента, когда компьютеры, построенные на квантовых принципах (квантовые компьютеры), смогут решить некоторую задачу за разумное время, а классическими технологиями, компьютерами или суперкомпьютерами, за разумное время её решить будет невозможно.

Эта фраза про разумное время предмет дискуссии, который изначально был заложен в определение, но интуитивно всем более-менее понятно, что имеется в виду. Условно, это ситуация, когда квантовые компьютеры решают задачу за минуту, а классическому компьютеру требуется тысяча лет. Или: квантовый компьютер решает за 10 секунд, а классическому суперкомпьютеру требуется год. Масштаб может быть разный, но идея интуитивно понятна. Есть какая-то задача, которая классически решается сложно (долго), а на квантовом компьютере решается просто (быстро).

В Google построили процессор из 53 кубит, который называется Sycamore. Он показал, что достаточно абстрактную и неочевидно полезную с прикладной точки зрения задачу процессор Google решает за 200 секунд, а классический суперкомпьютер IBM Summit, по их оценкам, решал бы десятьтысяч лет. Задача действительно специфическая, для её понимания нужно немного погрузиться в детали работы квантовых процессоров. Одно из возможных практических применений такой задачи генерация случайных чисел.

Что это за задача?

Квантовые процессоры можно воспринимать как обобщение классических процессоров. Всё отличие состоит в том, что в регистрах вместо классических битов, которые могут быть в состоянии 0 либо в состоянии 1, находятся кубиты, которые могут быть одновременно и 0, и 1. Таким образом, если мы приготавливаем регистр из 53, как говорят, запутанных кубитов, они могут быть одновременно в каждом из всех возможных 2⁵³ состояний, тогда как классический регистр может быть только в одном из этих 2⁵³ состояний. Квантовый компьютер может работать не с одним состоянием, а с суперпозицией всех возможных состояний.

Второе отличие квантового процессора от классического операции, которые мы проводим над регистрами. На классическом компьютере мы делаем логические операции над битами, а в квантовом компьютере мы делаем операции над кубитами.

Задача, которую решал Google, состоит в следующем. Мы приготавливаем регистр из 53 кубитов, выполняем достаточно большое количество случайно выбранных одно- и двухкубитных операций и производим измерение получившегося квантового состояния. В результате измерения мы получаем образец (сэмпл) случайной классической 53-битной строки. Основной интерес представляет собой распределение вероятности, из которого получаются эти битовые строки (его определяют выбранные нами случайные одно- и двухкубитные операции). Эта задача называется сэмплированием из случайных квантовых цепочек (Random Quantum Circuits). Имея квантовый компьютер, выполнить подобное сэмплирование достаточно просто: достаточно его включить, выполнить все необходимые квантовые операции и провести измерения. Для классического компьютера данная задача оказывается вычислительно сложной: чтобы сымитировать работу квантового компьютера, в общем случае нужно хранить в памяти компьютера промежуточное состояние квантового регистра объёмом 2⁵³.

В эксперименте Google было проведено около 1,5тысяч операций за время когерентности кубитов. Команда Google взяла то время, которое было необходимо им на квантовом процессоре, и оценила время, необходимое для реализации части эксперимента на суперкомпьютере. Затем, как я понял, они провели несколько симуляций и аппроксимировали, что для финального эксперимента потребовалось бы десятьтысяч лет.

В 2017 году Джон Мартинис, который до последнего времени был лидером проекта Google по квантовому компьютеру, приезжал в Москву на конференцию Российского квантового центра ICQT-2017. Ещё в 2017 году он говорил, что готов к демонстрации квантового превосходства и вполне конкретно объяснял суть того, что будет делать (https://youtu.be/Q3zNpwgaAuY). Всё выглядело очень понятно, и все ждали, что завтра-послезавтра у них выйдет статья. Но она не выходила.

Прошло около полугода, они выпустили 72-кубитный чип. Тогда казалось, что 72 кубита это абсолютно точно то, чего достаточно для демонстрации квантового превосходства. Однако и с этим чипом они пока не продемонстрировали результатов.

В 2019 году Хартмут Невен из Google был в России на конференции Квантового центра (ICQT-2019), и уже он более явно говорил о том, что они находятся на пороге квантового превосходства, и для его демонстрации может быть использована определённая задача. Сейчас понятно, что к тому моменту, скорее всего, статья Google была готова или находилась в высокой степени готовности, уже была готова для отправки в научный журнал.

В то время, когда заявлялся результат, было очень много критики (в том числе от уважаемых людей из IBM) в адрес эксперимента, обсуждения были долгими и из-за этого у неспециалистов могло создаться впечатление, что результат не так уж и значим. Почему так получилось?

В академической среде существует практика, что до момента публикации анонсы полученных результатов запрещены. И чем престижнее научный журнал, тем жёстче это правило соблюдается. Поскольку публикация Google была направлена в престижный научный журнал Nature, они не могли публично комментировать достигнутый результат.

Тут каким-то образом в сети появляется сообщение Financial Times: на сайте NASA опубликован пресс-релиз, где сказано, что Google вместе с NASA достигли квантового превосходства (потом пресс-релиз был удалён). Это было мгновенно растиражировано. Все начали спрашивать, что же произошло на самом деле. Кто-то нашёл препринт научной статьи, непонятно как. Конечно, это всем дало некоторое время для того, чтобы детально разобраться в эксперименте, попытаться раскритиковать его.

Ряд команд, в том числе команда компании IBM, утверждали в своей научной публикации, что, если бы моделирование на классическом суперкомпьютере квантового суперпроцессора происходило иначе, то время, которое затратил бы классический суперкомпьютер, можно было бы значительно сократить скажем, до нескольких дней (работа компании Alibaba утверждала о моделировании поведения процессора Sycamore за 20 дней: https://arxiv.org/abs/2005.06787).

При этом команда Google ничего не могла на это ответить, поскольку они не имели права комментировать свои результаты!

Наконец, статья была опубликована. Джон Мартинис сделал замечательный доклад, рассказал детально обо всех технических результатах, которые были достигнуты: https://youtu.be/FklMpRiTeTA. Конечно, один из вопросов, который он поднимает это критика Google со стороны IBM. Он сказал очень разумную вещь (цитирую примерно): Мы провели эксперименты, мы опубликовали свои данные. Можете проверить, что мы сделали правильное заключение на основе тех данных, что получили. Конечно, можно моделировать квантовые процессы по-другому, можно что-то придумать. Но если я добавлю ещё один кубит в свой процессор, то снова значительно вырвусь вперёд.

Поэтому я бы сказал, что они действительно сделали очень точный, чистый и открытый эксперимент, достигнув порога квантового превосходства. Вопрос о том, может ли моделирование на классическом компьютере занимать меньше времени, конечно, остаётся. Тем не менее, на момент 2019 года сам факт квантового превосходства был продемонстрирован.

Есть выдающийся учёный Скотт Ааронсон, у него есть замечательный научный блог. У него в блоге охарактеризовали ситуацию так: квантовое превосходство 2019 года это победа квантового Давида над классическим Голиафом. Маленький процессор из 53 кубитов это очень маленький квантовый процессор И он уже конкурентен по сравнению с самым мощным суперкомпьютером из когда-либо созданных. Поэтому можно считать, что порог квантового превосходства пройден. Дальше мы можем набирать всё больше и больше экспериментов, всё больше и больше результатов, которые будут это подтверждать.

В декабре 2020 года о достижении квантового превосходства заявила команда учёных из Китая. Алексей написал об этом подробную заметку.

Другая вещь, о которой мы часто слышим в контексте применения квантовых технологий коммуникации. Например, обнаружение подозрительных элементов в сети, обнаружение перехвата сообщений. Какие у подобных задач существуют применения и почему они так важны?

Если говорить о квантовых коммуникациях на текущем этапе их развития, то речь идёт о решении конкретной проблемы в области криптографии проблеме защищённого распределения криптографических ключей между удалёнными пользователями. В будущем могут возникнуть и новые применения квантовых коммуникаций например, соединение разных квантовых компьютеров.

Существуют разные криптографические примитивы, которые мы используем каждый день: шифрование, электронные подписи, все они нуждаются в том, чтобы каким-то образом распределить криптографический ключ. Это можно делать по-разному: например, послать доверенного курьера, который отвезёт в чемоданчике ключ из Москвы куда-нибудь во Владивосток, и у нас будет возможность шифровать этим ключом весь трафик. Конечно, это решает определённый спектр задач, но, например, не помогает бизнесу из Москвы купить что-то во Владивостоке или Новосибирске, подписав свою платёжку электронной подписью. Также нужно обязательно доверять курьеру.

Для решения подобных задач была придумана инфраструктура, которой мы все сейчас пользуемся инфраструктура открытого распределения криптографических ключей, а также множество примитивов, которые на ней построены: асимметричное шифрование, электронные цифровые подписи и так далее.

У криптографии, построенной на принципах открытых ключей, асимметричной криптографии, есть огромное количество сильных сторон. Но есть и один серьёзный недостаток. Если появится достаточно мощный квантовый компьютер, он сможет взламывать криптографические алгоритмы с открытым ключом, который мы сейчас используем. Это такие примитивы как RSA, Диффи-Хеллман, эллиптические кривые определённых типов и так далее. Соответственно, появляется угроза: коммуникации, которые нам необходимо сделать защищёнными, не будут защищены в эпоху квантового компьютера. Что же мы можем с этим сделать?

Первый из возможных ответов квантовые коммуникации. Это технология распределения криптографических ключей, основанная на том, что информация кодируется в одиночные квантовые объекты. Вместо того, чтобы кодировать ключи в какие-то сигналы большой интенсивности, которые можно незаметно разделить, мы кодируем информацию в одиночные, например, частицы света и передаём их из точки А в точку Б.

Замечательное свойство квантовых объектов заключается в том, что любая попытка вмешательства между точкой приготовления состояния (передатчиком) и его измерения (приёмником), любое действие над квантовым состоянием приведёт к увеличению числа ошибок. И замечательный результат на грани математики, физики и технологий состоит в том, что по количеству ошибок мы можем оценить информацию, которой потенциально владеет злоумышленник. Таким образом, если мы передаём информацию и уровень ошибок не превышает критический порог, можно сказать: ОК, из такой информации мы можем при помощи определённых алгоритмов сгенерировать секретный криптографический ключ.

Если же число ошибок превышает критический порог, мы говорим, что информация, потенциально доступная злоумышленнику о передаваемой последовательности составляет 100%. Соответственно, легитимным пользователям получать секретные ключи из этого сообщения нельзя. Квантовая криптография (или квантовое распределение ключей) одно из главных направлений квантовых коммуникаций. Эта технология гарантирует обнаружение факта вмешательства и даёт ему оценку: критичным является это вмешательство или нет. Если оно не является критичным, мы исправляем ошибки, проводим процедуру усиления секретности и доказываем, что информация, которая потенциально доступна злоумышленнику о переданной криптографической последовательности, пренебрежимо мала.

Это уже не научная фантастика, технологии разработаны и внедряются в индустрию. Например, Центр квантовых коммуникаций НТИ МИСиС и стартап QRate занимаются разработкой новых поколений таких устройств и внедрением их для решения конкретных бизнес-задач. Поэтому квантовые коммуникации технология сегодняшнего дня, то, что конечный потребитель может попробовать, внедрить и оценить. Главным преимуществом является способность обеспечить долгосрочную защиту данных.

Второй способ жить в эпоху квантового компьютера разработка новых алгоритмов криптографии с открытым ключом, которые основаны на предположении наличия у злоумышленника квантового компьютера. Такая область называется постквантовой криптографией. Это новая математика, вдохновлённая исследованиями в области квантовых компьютеров. И, опять же, в Российском квантовом центре в сотрудничестве с Центром НТИ МИСиС мы занимаемся развитием таких алгоритмов (см. qapp.tech).

Это новые типы криптографических библиотек, которые легко использовать в мобильных устройствах, защищённых коммуникациях в интернете и так далее. Поэтому здесь такой take-home message: мы начнём пользоваться этими технологиями уже в самое-самое ближайшее время, и, возможно, этот переход произойдёт для нас совсем незаметно. Просто в какой-то момент вы увидите, что ваше соединение уже не HTTPS, а HTTPS-PQ (HTTPS Post-Quantum) или что-то подобное. Оно будет защищено не только от текущих угроз, но и от атак обозримого будущего.

Как квантовые вычисления связаны с искусственным интеллектом?

Область квантового машинного обучения или квантового искусственного интеллекта это, пожалуй, самая overhyped тема в сообществе физиков. Кого ни спросишь на конференции, все занимаются квантовым машинным обучением. Есть несколько плоскостей, в которых эта работа ведётся.

Во-первых, алгоритмы классического искусственного интеллекта могут помочь нам построить квантовые компьютеры лучшего типа. Поскольку задача управления квантовым процессором достаточно сложная, её тяжело решать напрямую. Можно придумать какие-то гибкие алгоритмы, основанные на машинном обучении, чтобы находить правильное состояние для квантового процессора и так далее. Это использование классического машинного обучения для квантовых компьютеров.Например, при помощи машинного обучения было более эффективным образом получено состояние конденсата Бозе-Эйнштейна атомов тулия в лаборатории РКЦ.

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

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

В этом смысле их соединение с квантовыми процессорами технологический perfect match. И поэтому, например, лаборатория Google по развитию квантовых компьютеров называется Google Quantum Artificial Intelligence Lab. В Российском квантовом центре у нас есть совместная Индустриальная лаборатория квантового искусственного интеллекта (при поддержке Газпромбанка) и была целая программа по квантовому машинному обучению для решения индустриальных задач (например, совместно с Росатомом).

Сложность квантовых алгоритмов машинного обучения.

Действительно, работы в этой области публикуются весьма активно. Алексей Фёдоров собрал таблицу сравнения сложности классических и квантовых алгоритмов для различных методов машинного обучения. В столбце QRAM указывается "yes", если алгоритм требует наличия Quantum Random Access Memory.

Таблица создана на основе обзоров J. Biamonte, P. Wittek, N. Pancotti, P. Rebentrost, N. Wiebe, and S. Lloyd, Quantum machine learning, Nature (London) 549, 195 (2017) и C. Outeiral, M. Strahm, J. Shi, G.M. Morris, S.C. Benjamin, and C.M. Deane, The prospects of quantum computing in computational molecular biology, WIREs Comput. Mol Sci. 11, e1481 (2021).

Algorithm	Classical	Quantum	QRAM	References
Linear Regression			Yes	Phys Rev A. 94, 022342 (2016); Phys Rev A. 96, 012335 (2017); IET Quantum Commun. 2, 55 (2020); arXiv:1907.06949.
Gaussian process regression			Yes	Phys. Rev. A 99, 052331 (2019); Phys. Rev. A 100, 012304 (2019).
Decision trees		Unclear	No	Quantum Information Processing 13, 757 (2013).
Ensemble methods			No	Sci Rep. 8, 2772 (2018); arXiv:1902.00869; arXiv:2002.05056.
Support vector machines			Yes	Phys. Rev. Lett. 113, 130503 (2014); Quantum Information and Communication 17, 1292 (2017); Phys. Rev. Lett. 122, 040504 (2019).
Hidden Markov models		Unclear	No	Applied Mathematical and Computational Sciences 3, 93 (2011); arXiv:1710.09016.
Bayesian networks			No	arXiv:1512.03145; Phys. Rev. A 89, 062315 (2014).
Graphical models		Unclear	No	Phys. Rev. X 7, 041052 (2017).
kMeans clustering			Yes	arXiv:1307.0411; Quant Inform Comput. 15, 318 (2018); Advances in Neural Information Processing Systems. New York: Curran Associates, 2019; p. 4136-4146.
Principal component analysis			No	Nat. Phys. 10, 631 (2014).
Persistent homology			No	Nat Commun. 7, 10138 (2016).
Gaussian mixture models			Yes	arXiv:1908.06657; Phys. Rev. A 101, 012326 (2020).
Variational autoencoder		Unclear	No	Quantum Sci. Technol. 4 014001 (2019)
Multilayer perceptrons		Unclear	No	Advances in imaging and electron physics. Volume 94. Amsterdam: Elsevier, 1995; p. 259-313; Int. J. Theor. Phys. 37, 651 (1998); arXiv:1711.11240; npj Quant. Inform. 3, 36 (2017); Phys. Rev. Res. 1, 033063 (2019).
Convolutional neural networks			No	Nat Phys. 15, 1273 (2019).
Bayesian deep learning			No	Quant Mach Intell. 1, 41 (2019).
Generative adversarial networks			No	Phys Rev Lett. 121, 040502 (2018); Phys Rev A. 98, 012324 (2018); arXiv:1711.02038.
Boltzmann machines			No	NIPS 2011 Deep Learning and Unsupervised Feature Learning Workshop. Toward the implementation of a quantum RBM. New York: Curran Associates, 2011; On the challenges of physical implementations of RBMs. Twenty-eighth AAAI conference on artificial intelligence. Palo Alto, California: Association for the Advancement of Artificial Intelligence, 2014; arXiv:1412.3489; Phys Rev A. 94, 022308 (2016); arXiv:1903.01359; Phys. Rev. X 8, 021050 (2018).
Reinforcement learning			No	Phys Rev Lett. 117, 130501 (2016); 2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC). New York: IEEE, 2017; p. 282287.

Про практику, языки квантового программирования, стартапы и увлекательные задачи

Можно ли прямо сейчас пойти и что-нибудь попробовать сделать, потрогать технологию, написать программу?

Сейчас для этого много возможностей. Есть ряд квантовых компьютеров, находящихся в облачном доступе, например, квантовый компьютер IBM.

Я уже рассказывал, что преподаю. На первом занятии я всегда спрашиваю студентов-магистрантов, программировали ли они когда-либо на квантовых компьютерах, и год от года количество положительных ответов увеличивается. Кто-то использует их для решения научных задач, кто-то просто ради интереса что-то пробует делать. Почему? Потому что, например, платформа IBM очень user-friendly. Можно прийти, прочитать, понять, как это работает, найти удобный инструмент и начать программировать; можно писать код, собирать операции над кубитами в визуальном интерфейсе и пытаться решать задачи на реальном квантовом компьютере.

Сейчас немало разрабатывается и более серьёзных инструментов: например, проекты Microsoft и Google по созданию инструментов квантового программирования, недавно анонсированный квантовый вариант Tensor Flow.

Есть большие пакеты для моделирования квантово-химических соединений, для моделирования квантовых систем и многое-многое другое. То есть даже если речь идёт о специалисте по вычислительной химии, ему уже есть с чем поработать на квантовых компьютерах.

Представь себе, что я начинающий разработчик, умею программировать на Python. И вот я хочу познакомиться с квантовыми вычислениями. Какую первую задачу мне стоит решить?

Это зависит от того, что тебе было бы интересно делать.

Если хочется при помощи навыков Python разобраться, как работают квантовые технологии, я бы предложил запрограммировать какой-нибудь несложный алгоритм обработки данных или алгоритм управления небольшим квантовым процессором. Или, не имея доступа к квантовому компьютеру, можно сэмулировать (просимулировать) при помощи классических ресурсов его поведение и таким образом получить программный эмулятор/симулятор квантового компьютера с небольшим числом кубитов.

Может быть, ты бы мне сказал: Мне интересно заниматься приложениями, алгоритмами. Я хочу делать квантовые алгоритмы для конечных пользователей. Тогда бы мы с тобой подумали о проектировании алгоритма решения, например, оптимизационной задачи и написании не очень сложной функции или не очень сложного набора программных инструментов для решения этого типа задач.

Люди с энтузиазмом и знаниями Python очень нужны в сообществе по разработке квантовых технологий. Python был нашим основным инструментом прототипирования всех алгоритмов обработки ключей для систем квантовой криптографии. Моя команда до этого занималась (и сейчас продолжает в каком-то смысле заниматься) разработкой программной платформы для обработки ключей в системах квантовых коммуникаций. Идея возникла так: учёные в основном используют Python для прототипирования, а потом уже индустриальное программное обеспечение пишется на C++ профессиональными инженерами.

Нарисуй, пожалуйста, потрет идеального человека, который прямо сейчас приходит в твою область и сразу даёт интересные результаты? Что он знает, что умеет?

Если это учёный, то в первую очередь речь идёт о глубоких знаниях в математике, физике и желании с чем-то разобраться в деталях. Наверное, главный критерий, по которому я пытаюсь принимать людей в команду есть ли в человеке желание досконально разобраться в каком-то вопросе. Мы очень много обсуждаем этот вопрос с моим коллегой Евгением Киктенко к нам приходит достаточно большое количество людей, из которых нужно выбирать. Жене удается найти в людях эту глубину и помочь раскрыться.

Если речь идёт о работе в стартапах, об инженернах, то нужны конкретные знания и мотивация решать инженерные задачи.

У нас есть стартап, который развивает квантовые вычисления сейчас мы делаем программную платформу для работы с квантовыми компьютерами с наборами сервисов для конечного пользователя. Появляются первые кейсы, когда сторонние пользователи начинают тестировать платформу. Команда, которая этим занимается, вся пришла из классического программирования, её технический руководитель Алексей Боев пришёл из классического машинного обучения из крупной компании. Соответственно, нужны навыки программистов, всё то же самое, к чему они привыкли при устройстве на работу в технологические компании. Специфика квантовых технологий проявляется на следующем этапе погружения. А сначала мы смотрим, насколько крутые у человека скиллы в области программирования.

Есть еще один спин-офф, занимающийся пост-квантовой криптографией, там мы, например, ищем криптографов, и нам важно, чтобы человек понимал криптографию, криптографические примитивы, доказательства и так далее.Опять же существенная часть команды это инженеры и программисты с опытом разработки сложных систем. Например, с одним из основателей проекта Николаем Пожаром мы в университете занимались разработкой программной платформы для сложных сенсорных систем.

Давай поможем ответить этому идеальному человеку на вопрос, чего он хочет. Какие сейчас есть нерешённые захватывающие задачи, способные обеспечить прорывные результаты?

Большая задача, которую я вижу, и она драйвит всю прикладную часть моих исследований привести квантовые технологии к конечному пользователю, сделать так, чтобы пользователь понял все преимущества, которые дают ему либо квантовые компьютеры, либо квантовая и пост-квантовая криптография. Идея, которой я пытаюсь заразить людей, приходящих в эти проекты они сейчас на том этапе, когда научная разработка благодаря их труду может стать программным продуктом, используемым в индустрии каждый день.

И у нас прорывы были связаны с тем, что для проекта, который считали академическим, мы находили индустриального партнёра, проводили с ним совместное тестирование, и люди понимали: вчера это была наука, сегодня технология, а завтра уже будет продукт и бизнес. И есть большое количество направлений, новых продуктов, которым ещё только предстоит созреть. Кроме крутых учёных нужны инженеры, специалисты разного типа, которые могли бы сделать этот, простите за заезженную фразу, квантовый скачок из лаборатории в бизнес.

Если говорить о технических направлениях, то и в квантовых коммуникациях, и в квантовых вычислениях огромное количество вызовов. Например, один из трендов попытка максимально интегрировать классические суперкомпьютеры и квантовые компьютеры. Часто разработчики квантовых процессоров рассматривают их размещение рядом с суперкомпьютером понятно, что они должны взаимодействовать. Каким образом наладить это гибридное взаимодействие при реализации квантовых алгоритмов огромный вопрос, на который нет окончательного ответа. Чтобы придумать гибридные алгоритмы, гибридные схемы взаимодействия, нужно понимать, как работают и классические, и квантовые компьютеры и оптимально использовать их ресурсы. Это точно большая задача!

Следующая большая веха будет связана с внедрением квантовых кодов коррекции ошибок, и здесь очень с высокой вероятностью вдохновение может прийти не от квантовых физиков, а от людей, которые занимались кодами коррекции ошибок в классических информационных технологиях. Есть много возможностей принести новые инструменты из ИТ в квантовые вычисления или квантовые коммуникации, получить новые продукты, новые качества, новые сущности. Поэтому здесь вопрос, наверное, ещё в энтузиазме людей. Если вы готовы врываться в эту, безусловно, конкурентную и сложную область, то есть огромное поле того, что можно сделать.

Какую роль в твоей жизни играют стартапы?

Стартапы главный мотивационный фактор доводить работу до законченных результатов. Я немного рассказал о том, как устроен Российский квантовый центр, что для нас важна классная наука, для нас важно рассказывать о результатах, но не менее важной составляющей нашей ДНК являются стартапы. Мы пытаемся перенести научные результаты в плоскость технологий, продуктов, коммерческого использования.

В первый раз я прошёл этот путь с компанией QRate. Она появилась около 5 лет назад и планомерно развивается как технологический стартап с очень серьёзной составляющей в части инжиниринга, R&D, адаптации новых технологий. Уже появилось несколько поколений продуктов для разных пользователей и разных рынков. Конечно, я в процессе очень многому научился, а ещё стартап стимулирует действовать так, чтобы научные результаты, которые ты делаешь в рамках и в интересах спин-оффа, давали конкурентное преимущество, а не просто превращались в научную публикацию. Мне это понравилось. Поэтому позже появились ещё два стартапа, которыми я занимаюсь: QApp (пост-квантовые алгоритмы, qapp.tech) и QBoard (квантовые вычисления, создание платформы для квантовых компьютеров, qml.rqc.ru).

Насколько легко тебе было переключить сознание между научной деятельностью и стартапами, бизнес-историей?

Я пытался переключать сознание насовсем. Так не работает. Сказать: Я больше не занимаюсь наукой, я занимаюсь только стартапами, у меня не получается. Когда я говорю: Я занимаюсь только наукой, не занимаюсь стартапами, у меня тоже не получается. Поэтому какую-то часть времени мы занимаемся прикладными вопросами в интересах стартапа, в интересах компаний, а другую часть творческими научными задачами, которые могут быть сильно отдалены по времени от практических результатов. Но, тем не менее, это очень интересно. Практические задачи, как я и сказал, очень важный драйвер мотивации. Они заставляют не отступать в момент, когда что-то не получается. Дожать и получить результат очень важно для будущего практического внедрения.

Про путь в науке

Ты в 15 лет поступил в Бауманку?Как это вообще возможно?

Я в 15 лет закончил школу, так получилось, и потом поступил в Бауманку. Мои родители решили, что начальные классы школы это скучно, и сказали: А почему бы тебе не пойти сразу в пятый класс?. Я такой: А почему бы и нет?. Так и получилось.

Сложно учиться, когда ты моложе одногруппников?

Да. Причём, когда я пришёл, то сразу сказал на кафедре: Мне, наверное, будет сложно, потому что я моложе всех на два года. Они говорят: Да? А давай тогда ты будешь старостой. Тебе так будет легче. Поэтому я ещё и был старостой в своей группе. Это помогло мне немножко собраться и двигаться вперёд. Но для Бауманки, на самом деле, это нормальная история: многие ребята поступают достаточно рано.15 лет далеко не рекорд.

Почему квантовые компьютеры? Как ты попал в эту область?

Это был длинный путь. Я учился на факультете информатики и систем управления. Занимался классическим IT, если можно так сказать: информатикой, криптографией, и в какой-то момент понял, что мне очень не хватает физики. Начал читать всякие научно-популярные статьи, и узнал, что прямо сейчас происходит какая-то интересная история про кванты. Квантовые компьютеры, квантовая криптография. А почему нам про это не рассказывают? Начал сам про это читать, ходил на занятия на кафедру физики в Бауманке. И как-то так получилось, что в момент выбора научной стези я уже понимал, что хочу заниматься квантовыми вычислениями и квантовой криптографией.

Причём здесь есть личная история. Я увлёкся квантовой криптографией. Это направление меня очень заинтересовало, так что я долго им занимался, но никогда не думал, что из этого получится что-то практическое. Я думал, что это будет теоретическая работа: буду статьи читать, статьи писать и так далее. Но в какой-то момент познакомился с Юрием Курочкиным он сейчас CTO QRate, спин-оффа Российского квантового центра, который как раз занимается разработкой систем квантовой криптографии. Даже уже не просто разработкой, а внедрением их в разные приложения. И я увидел, что у меня появился человек, благодаря которому, скорее всего, все теоретические идеи в какой-то момент воплотятся в железо. И это действительно получилось. В дипломе, который я писал под руководством Юры, уже содержались элементы экспериментов по квантовой криптографии. А буквально через несколько лет появилась промышленная установка квантовой криптографии, которую производит QRate.

Алексей Фёдоров выступил на конференции YaTalks 5 декабря 2020 года. Посмотреть запись можно на сайте конференции, а также в YouTube. Запись интервью доступна по ссылке.

• Партнер по данным, Data Partner. Мы так переименовали Data steward. Да, слово steward имеет здравое значение в переводе: распорядитель чего-то чужого, а данные в этом смысле чужие. Но все равно партнер по данным звучит гораздо лучше.
  
  Партнер по данным на логическом уровне должен ответить на вопрос концептуальной модели: какие вообще направления бизнеса и взаимосвязи между ними у нас есть, как часто будут меняться атрибуты. И из этого построить логическую модель, прямо по классике.
• И инженер данных, здесь все классически. Он отвечает на вопросы физической модели: как хранить атрибуты, нужны ли партиции, нужно ли закрытие SCD2. И обеспечивает сам расчет данных по инкременту, а также пересчет истории, то есть фактически ETL-процесс.

• Закрепить разделение логического и физического проектирования в методологии, полностью закрыть физическое проектирование.
• Сокрытие физического проектирования провести как при загрузке данных, так и при использовании модели, чтобы было удобно загружать и строить витрины.
• И так как мы все сокрыли с физической точки зрения, то нужно еще выбирать оптимальный формат хранения для каждого конкретного случая: группировать и догруппировать атрибуты. Все это скрыто внутри.

Почему сложно перестать дублировать код?

SOLID на пути к переиспользуемым компонентам

• S принцип единственной ответственности.
• O принцип открытости/закрытости.
• L принцип подстановки Лисков.
• I принцип разделения интерфейсов.
• D принцип инверсии зависимостей.

Базовое

Принцип open/close

// утилита для формирования класса, можно использовать любой аналогimport cx from 'classnames';// добавили новый проп  mixconst Button = ({ children, mix }) => {  return (    <button      className={cx("my-button", mix)}    >      {children}    </button>}

Изменчивость компонентов

Темизация

import cx from 'classnames';import b from 'b_';const Button = ({ children, mix, theme }) => (  <button    className={cx(     b("my-button", { theme }), mix)}  >    {children}  </button>)

Вложенность компонентов

Продвинутое

Single Responsibility Principle

• Риск при редактировании одной части системы сломать другую.
• Плохие абстракции. Получаются компоненты, которые умеют выполнять несколько функций, из-за чего сложно понять, что именно должен делать компонент, а что нет.
• Неудобная работа с компонентами. Очень сложно делать доработки или исправлять баги в компоненте, который делает всё сразу.

const withTheme1 = (Button) =>(props) => {    return (        <Button            {...props}            styles={theme1Styles}        />    )}const Theme1Button = withTheme1(Button);

import "./styles.css"; // Базовый компонент кнопки. Принимает содержимое кнопки и стилиconst ButtonBase = ({ style, children }) => { console.log("styl123e", style); return <button style={style}>{children}</button>;}; const withTheme1 = (Button) => (props) => { // HOC применяет стили, только если выбрана тема "theme1" if (props.theme === "theme1") {   return <Button {...props} style={{ color: "red" }} />; }  return <Button {...props} />;}; const withTheme2 = (Button) => (props) => { // HOC применяет стили, только если выбрана тема "theme2" if (props.theme === "theme2") {   return <Button {...props} style={{ color: "green" }} />; }  return <Button {...props} />;}; // ф-я для оборачивания компонента в несколько HOCconst compose = (...hocs) => (BaseComponent) => hocs.reduce((Component, nextHOC) => nextHOC(Component), BaseComponent); // собираем кнопку, передав нужный набор темconst Button = compose(withTheme1, withTheme2)(ButtonBase); export default function App() { return (   <div className="App">     <Button theme="theme1">"Red"</Button>     <Button theme="theme2">"Green"</Button>   </div> );}

Композитные компоненты

• Container связь между остальными компонентами.
• Field текст для обычного селекта и инпут для компонента CobmoBox, где пользователь что-то вводит.
• Icon традиционный для селекта значок в поле.
• Menu компонент, который отображает список элементов для выбора.
• Item отдельный элемент в меню.

Overrides

<Select  ...  overrides={{    Field: {      props: {theme: 'dark'}    },    Icon: {      props: {size: 'big'},    },    Menu: {      style: {backgroundColor: '#CCCCCC'}    },  }}/>

Dependency Inversion Principle

import InputField from './InputField';import Icon from './Icon';import Menu from './Menu';import Option from './Option';

• Во-первых, при изменении Menu придётся править Select.
• Во-вторых, если мы захотим использовать другой компонент меню, нам тоже придётся вносить правки в компонент селекта.

// теперь вместо прямого импорта Select принимает одним из параметров компонент менюconst Select = ({  Menu: React.ComponentType<IMenu>}) => {  return (    ...    <Menu>      ...    </Menu>    ...  )...}

import { compose } from '@bem-react/core'import { withRegistry, Registry } from '@bem-react/di'const selectRegistry = new Registry({ id: cnSelect() })...selectRegistry.fill({    'Trigger': Button,    'Popup': Popup,    'Menu': Menu,    'Icon': Icon,})const Select = compose(    ...    withRegistry(selectRegistry),)(SelectDesktop)

• Полный контроль свободу в настройке всех составляющих компонента.
• Гибкую инкапсуляцию возможность сделать компоненты очень гибкими и полностью кастомизируемыми. При необходимости разработчик переопределит все блоки, из которых состоит компонент, и получит то, что хочет. При этом всегда есть вариант создать уже настроенные, готовые компоненты.
• Масштабируемость способ хорошо подходит для библиотек любых размеров.

Сложности разработки переиспользуемых компонентов

Liskov Substitution Principle

• читать и писать что-то в глобальный стор,
• взаимодействовать с window,
• взаимодействовать с cookie,
• читать/писать local storage,
• делать запросы в сеть.

• использовать возможности типизации,
• избегать взаимодействия в обход API компонента,
• избегать побочных эффектов.

const Component = () => {   /*      К сожалению, использование хуков приводит к тому, что компонент много знает о своем окружении.      Например, тут он знает о наличии стора и его внутренней структуре.      При переносе в другой проект, где стор отсутствует, код может сломаться.   */   const {userName} = useStore();    // Тут компонент знает о куках, что не очень хорошо для переиспользования (может сломаться, если в другом проекте это не так).   const userToken = getFromCookie();    // Аналогично  доступ к window может стать проблемой при переиспользовании компонента.   const {taskList} = window.ssrData;    const handleTaskUpdate = () => {       // Компонент знает об API сервера. Это допустимо только для верхнеуровневых компонентов.       fetch(...)   }    return <div>{'...'}</div>;  }; /*   Здесь компонент принимает только необходимый ему набор данных.   Его можно легко переиспользовать, потому что только верхнеуровневые компоненты будут знать все детали.*/const Component2 = ({   userName, userToken, onTaskUpdate}) => {   return <div>{'...'}</div>;};

Interface Segregation Principle

Где и как переиспользуем?

Библиотеки компонентов

Стек

Размер

Обновление

Кастомизация и дизайн

Витрина компонентов

Дизайн-система

Выводы