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

itertools — модуль стандартной библиотеки Python, который предоставляет ленивые итераторы для композиции цепочек обработки данных.

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

Функции разделены на три группы: бесконечные итераторы (count, cycle, repeat), конечные итераторы (chain, islice, groupby и др.) и комбинаторные (product, permutations, combinations).

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

Подводные камни: groupby требует предварительной сортировки по тому же ключу; итераторы одноразовые; tee() может неэкономно расходовать память.

Зачем вообще ленивые итераторы?

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

Ленивый итератор не строит коллекцию целиком. Он помнит текущее состояние и умеет «добыть» следующий элемент. Поэтому itertools работает с любыми итерируемыми источниками — файлами, генераторами, сетевыми потоками — и не требует, чтобы весь объём данных поместился в оперативную память.

Память vs скорость:
Ленивость экономит память, но не всегда ускоряет код. Если данные всё равно нужны целиком — например, для сортировки — список может оказаться быстрее. Используйте итераторы там, где важна потоковая обработка.

Три семейства инструментов

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

Бесконечные итераторы: count, cycle, repeat

count — это range без конца. Ему можно задать начальное значение и шаг, и он будет выдавать числа до тех пор, пока его не остановят снаружи. cycle бесконечно повторяет переданную последовательность, а repeat — бесконечно или заданное число раз возвращает один объект.

Классический трюк — сочетание map и count: map(f, count()) работает как математическое табулирование tabulate(f), знакомое из SML и Haskell.

Конечные итераторы: chain, islice, groupby и другие

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

batched появился в Python 3.12 и сразу стал незаменимым инструментом: партии запросов к API, пакеты строк для вставки в базу, страницы данных. Последняя партия может быть короче — это поведение по умолчанию.

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

Комбинаторные итераторы: product, permutations, combinations

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

product с аргументом repeat удобен для перебора многомерных конфигураций: product([0, 1], repeat=3) даст все двоичные triples, как в таблице истинности.

Подводные камни, за которые хватаются новички

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

• groupby работает только с подряд идущими одинаковыми ключами. Перед вызовом сортируйте данные по тому же ключу, иначе группы разобьются.
• Итераторы одноразовые. После list(iterator) исходный итератор опустошён, и второй проход по нему даст пустой результат.
• tee копирует данные во внутренний буфер, пока все производные итераторы не прочитают их. Если один итератор сильно отстаёт, память может расти не хуже списка.
• zip_longest с бесконечным итератором никогда не остановится. Ограничивайте такие комбинации islice или takewhile.
• product полностью потребляет входные итераторы, чтобы построить пулы значений. С бесконечными последовательностями его использовать нельзя.

Рецепты: от простого к составному

Документация Python включает раздел рецептов — готовые комбинации функций, которые решают частые задачи. Некоторые из них настолько удобны, что со временем превращаются в полноценные функции модуля: так появились accumulate, compress и pairwise.

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

Выводы

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

Together, they form an iterator algebra making it possible to construct specialized tools succinctly and efficiently in pure Python.

Источник: itertools — Functions creating iterators for efficient looping. Если в вашем коде до сих пор царят вложенные циклы и огромные списки — попробуйте заменить их на поток. Скорее всего, получится короче, быстрее и понятнее.

Мы пообщались с сотрудниками и экспертами сопровождения Яндекс Практикума и составили обширный лонгрид, в котором вы найдете фишки для выстраивания эффективного и живого общения с командой.

Оглавление

1. Почему важно живое общение
2. Как организовывать созвоны, от групповых до 1-2-1
3. Как готовиться и проводить групповые созвоны
4. Что делать с 1-2-1
5. Как давать обратную связь
6. Как разрешать конфликты
7. Как проводить брейнштормы
8. Как организовать трекер
9. Как организовать общение в течение дня
10. Как в развитии софтов может помочь школа Яндекс Практикума

Почему важно живое общение

Под живым общением мы подразумеваем живую коммуникацию, при которой команда активно вовлекается в работу, а не сухо отвечает «Ок» или вообще молчит. Выстроить работу без этого сложно. Команда — это люди с общими целями, но у каждого участника есть своя идентичность. Живое общение помогает:

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

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

Мидлам чаще приходится применять софт-скилы: помогать, давать обратную связь джунам, проводить встречи и т. д. Развитое живое общение поможет наладить с коллегами понимание и потенциально вырасти в должности — сеньоры пользуются софт-скилами чуть ли не чаще, чем хардами. И помочь в этом может Школа наставников Яндекс Практикума.

Как организовывать созвоны, от групповых до 1-2-1

Самые ходовые инструменты: Discord, Zoom, Microsoft.Teams, Google.Meet

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

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

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

В Zoom или Meet есть свои плюсы — можно записать митинги. Но есть и минусы: если кто-то что-то обсуждает, ты не можешь к ним как в офисе подойти и послушать, что они говорят. А Discord как раз это решает.

Как готовиться и проводить групповые созвоны

Для начала нужно объяснить, зачем человеку приходить на встречу. Сформируйте и зафиксируйте в описании цель встречи, адженду, тщательно продумайте состав участников: точно ли вам нужна вся команда?

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

Собирайте ожидания от встречи

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

Проводите разминки

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

Контролируйте общий план созвона, чтобы не отклоняться от курса

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

В такие моменты важно говорить уверенно: да, было!

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

Поддерживайте динамику созвона с помощью теории вдоха-выдоха

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

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

Проводите шеринг и дебрифинг

Шеринг — это когда мы дали блок информации или провели какую-то активность, а потом спрашиваем, какие у вас чувства, эмоции относительно этого, что думаете?

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

Вернуться в начало

Что делать с 1-2-1

1-2-1 можно проводить регулярно, когда к команде присоединяется новый участник. Нужно отслеживать в каком он состоянии, как адаптируется.

Либо когда команда создается с нуля, они друг к другу притираются. Когда команда уже сбитая между собой, то 1-2-1 начинают тратить время. А если и менеджер новый, они вообще теряют смысл, потому что команде хорошо, и нужно вливаться уже менеджеру.

Фиксируйте, что обсуждали ранее — лучше обезличенными формулировками

У меня всегда были записки о предыдущей встрече, что я должен сделать на следующей. Я выбирал однозначные обезличенные формулировки, чтобы человек понял и не ушел в защиту. Например, если у меня есть вопросы к перформансу сотрудника, я спрашивал: «Если 100% перформанса, это тебя никто не отвлекает, то какой у тебя сейчас процент от 100%?». Мы выявляли, что не так, и тогда можно было давать обратную связь о том, что мешает человеку достичь результата. То есть я пытался заставить его рефлексировать, дать ответ и возможность помочь ему.

Как давать обратную связь

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

Добавляйте конкретики

К примеру, даже в похвалу. Недостаточно просто сказать — «Ты классный сотрудник». Человек может испытать какую-то эмоцию, но что делать с этой информацией, непонятно. Важно сказать, что именно вы сюда вкладываете, что именно мне нужно продолжать делать в моей хорошей работе, чтобы она продолжала быть хорошей.

Сначала учите, а потом лечите и мочите

Это метод, при котором вы объясняете человеку, почему его действия плохие. Возможно, он просто не знает. Когда вы убедились, что он вас понял, то объясняете, как делать правильно, а уже потом даете фидбэк. До стадии «мочить» я не доходил, обычно во второй мы пытались выправить поведение.

Также есть метод «Пинок»:
P — это позитив,
IN — что-то, что можно доработать,
N — это негатив,
OK — самая важная часть — понял ли человек обратную связь.

Многие менеджеры команды сопровождения рассказывали, что команда просит не использовать метод сэндвича — позитивная обратная связь, потом критика, потом снова что-то приятное.

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

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

Вернуться в начало

Как разрешать конфликты

Открытые конфликты — это прекрасно. Можно сразу разобраться, что произошло, и поговорить, либо с привлечением тимлида, либо самим.

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

Выводите людей на чистоту

Можно сначала попробовать на 1-2-1 собрать фактуру, то есть вообще разобраться, что происходит. Это создаст безопасную, доверительную атмосферу. А дальше уже обязательно честно со всеми поговорить. Это тоже про культуру — мы не замалчиваем проблемы, а умеем открыто их принимать.

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

Как проводить брейнштормы

Самые ходовые инструменты: Miro, Jam, Draw.io, Microsoft Whiteboard, Plant UML

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

Важно ответить на такие вопросы:

• Кто модератор?
• Где проводить брейншторм?
• Как потом транслировать результаты?
• Сколько времени нужно заложить на выступление?
• Как эффективно выстроить коммуникацию?

На брейншторме должна быть «строгая» модерация

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

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

Разбивайте большую команду на маленькие группы

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

Мы использовали Miro и аналоги: в Meet есть Jam, Draw.io, но они не такие удобные. Для брейнштормов архитектуры мы готовим UML-диаграммы, их можно редактировать в режиме реального времени. То есть кто-то пишет код, и он появляется на картинке. Потом его можно перекинуть в Notion.

В работе не всем удобно, что Whiteboard сильно отдельно от Jira и Confluence. То есть когда база знаний в одном месте, а идеи генерируются в другом месте, приходится постоянно это между собой актуализировать.

Вернуться в начало

Как организовать трекер

Самые ходовые инструменты: Jira, Notion, Redmine, Яндекс.Трекер, ClickUp

Трекер — это всего лишь инструмент. Кто-то может им не пользоваться, им достаточно написать на доске цель и идти к ней. А кому-то нужно отслеживать количество часов работы, чтобы вести учет для статистики, отчетов и т. д.

Выделите у цели четкие стадии работы

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

Кастомизируйте любой инструментарий под свой бизнес-процесс

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

Например, я использовал ClickUp, но там нельзя давать тикет по номеру. В Jira это очень удобно: название проекта, несколько букв и номер. Он легко запоминается, в ClickUp такой штуки нет. Там ID какой-то просто набор букв, и ты никогда в жизни его не запомнишь.

Используйте Kanban-доски

У нас командная работа организована в Notion по Kanban. Есть 4 вертикальные колонки: сделаны, в работе, в плане на спринт и жду ответ. А в горизонтальных колонках указаны ответственные. И, соответственно, они скрываются, открываются как выпадающие списки, то есть мы можем всегда зайти и посмотреть, кто что из нас делает.

Добавляйте фишки в оформление

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

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

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

Вернуться в начало

Как организовать общение в течение дня

Самые ходовые инструменты: Telegram, Mattermost, Slack, Discord

Мемы — это тимбилдинг

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

Заведите отдельный канал для разгрузки

У нас был канал в Discord, где можно было поделиться честным мнением о чем-то. Если ты не хочешь быть токсичным, но при этом хочешь выразить то, что тебе совсем не нравится, ты можешь написать туда: бесит Flask — и слить в канал свои переживания.

Сообщайте коллегам свои рабочие часы

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

Как в развитии софтов может помочь школа Яндекс Практикума

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

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

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

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

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

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

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

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

Школа наставников доступна всем, кто пройдет этапы отбора на роль наставника в Практикуме. Узнать, какие роли открыты сейчас, можно здесь.

Реклама АНО ДПО «Образовательные технологии Яндекса», LjN8JtbN9

Началось все с того, что в конце 2022 года я твердо решил, что хочу устроиться в FAANG компанию, но для этого, как вы наверно все знаете, нужны знания алгоритмов и структур данных, коих у меня не было, потому что в обычной работе тебе не нужны heap, tree, disjoint set и другие структуры данных, поэтому начать пришлось практически с нуля.

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

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

Начинать решать LeetCode нужно не подряд, а по темам: сначала array, hashmap, set — и только потом stack, tree, graphs.

Если задача не решается за 30–40 минут — смотрите разбор, изучайте решение и возвращайтесь к ней снова. Повторение — ключ к закреплению.

Python — лучший язык для LeetCode: лаконичный синтаксис и богатая стандартная библиотека (Counter, defaultdict, heapq) экономят время на интервью.

Уверенность при прохождении coding-интервью появляется примерно после 400–500 решённых задач; 600+ задач снимают страх полностью.

Советы

1. Первый совет – обращайте внимание на процент Acceptance, чем этот процент больше, тем лучше, потому что это означает, что у многих людей получается решить эту задачу и есть вероятность, что и у вас получится.Также можете открыть study plan и попробовать решать задачи оттуда:
    – Топ 100 залайканных задач, если много лайков, значит есть вероятность, что это не какая-то хитросплетеная задача, которая может понизить вашу оценку(есть много задач для которых нужны специфичные знания и это может быть неочевидно с первого взгляда)
    – Топ 150 задач для подготовки к интервью, вероятность встретить эти задачи на интервью высока, но тут могут быть сложные задачи, которые трудно будет решить в начале пути
    – Как пишет leetcode, это “Must-do problem list for interview prep”. Задачи в этих списках распределены на разные темы, решать нужно их следуя следующему совету.
2. Второй совет – начинайте с самых фундаментальных структур данных, таких как array(одномерный/двумерный), set, hashmap, они будут встречаться вам постоянно, к примеру, во многих задачах время выполнение можно улучшить добавив set или hashmap(но нужно учесть, что увеличится потребление памяти) и только после того как освоите их, можно начинать углубляться в другие структуры как stack, queue, linked list, tree, graphs.
   На самом leetcode есть карточки, в которых дается объяснение структурам данных и алгоритмам + задачи для закрепления этих тем, как и написано выше, начинайте с простых карточек – array, string и постепенно повышайте уровень, я несколько раз возвращался к карточкам, т.к. некоторые моменты порой были непонятны с первого раза, поэтому не думайте, что с вами что-то не так, если что-то непонятно, вернетесь потом и обнаружите, что уже понимаете это.
   Тут есть roadmap с темами и задачами, очень советую
   Тут можно создать понедельный план с применением различных фильтров
   Список из 150 популярных задач, разделенные на темы, сложность и компании
3. Третий совет – если не можете придумать оптимальное решение, начинайте с решения “в лоб”, как только получится, подумайте над тем, как это решение можно улучшить, может можно использовать какую-то структуру? может массив можно отсортировать? а что если использовать set или hashmap? можно ли использовать какой-то шаблон? Если ничего не помогает и вы уже потратили 20-40 минут, то смело открывайте решение задачи и изучайте это решение, как только вы это сделали, закройте решение и попробуйте заново решить(таких итераций может быть несколько, это нормально!), если после нескольких итераций не получилось, просто перепечатайте решение(я неоднократно так делал), НО не забудьте через время вернуться к этой задаче и попробовать решить заново(вполне вероятно, что не получится и это тоже нормально, просто повторяете все шаги заново, у меня бывали случаи, когда я одну и ту же задачу решал и по 10 раз, пока точно не буду уверен, что точно понял).
4. Четвертый совет – пройдитесь по этим 14 шаблонам, особенно уделите внимание two pointers, sliding window и fast & slow pointers, т.к. они чаще всего встречаются. Берете шаблон, находите задачи под этот шаблон(на странице с leetcode проблемами есть фильтр по тегам, нужно выбрать нужный тег, к примеру “Two pointers” или “Sliding window” и т.д.) и решаете столько задача, сколько нужно, чтоб закрепить эту тему.
5. Пятый и самый важный совет – практика, практика и еще раз практика, в начале мне хотелось каждый раз плакать от своей тупости, потому что не мог решать даже простые задачи и это не преувеличение, фраза – “какой же я тупой” не уходила из головы первые несколько месяцев и даже после решения 600 задач все еще бывают моменты, когда самооценка падает, если не получилось решить какую-то задачу, особенно если оказалось, что решается очень легко, но что важно – с каждой решенной задачей вы будете становиться лучше относительно себя.

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

FAQ

1. Что делать, если не получается решить задачу?Если после 30-40 минут у вас не получилось решить задачу, то посмотрите решение, попробуйте найти видео решение этой задачи, как только посмотрели и разобрали, попробуйте решить заново, если не получилось, еще раз посмотрите и так по кругу. Время от времени возвращайтесь к старым задачам и решайте их заново, особенно если решение какой-то задачи далось вам с трудом.Я порой одну и ту же задачу решал по 10-15 раз, а то и больше
2. Сколько задач нужно решить, чтобы начать откликаться на вакансии?Тут все индивидуально, я полгода каждый день решал(сам или с помощью видео) несколько задач, решил где-то 300 задач и только в этот момент почувствовал почву под ногами, а уверенность почувствовал только после решение где-то 400-500 задач. Некоторым достаточно и 100-200 задач, к сожалению я не из их числа.
3. Какой язык программирования выбрать для решения задач?Если коротко – Python.Я начинал решать на php, потом перешел на go, после начал решать на java и наконец после просмотра видео решил попробовать python и с тех пор решаю на этом ЯП. Java – тратишь время на большие конструкции, к примеру – List<Integer> items = new ArrayList<>();
   PHP – путался в аргументах функций, неудобно было в целом писать, хотя практически все время пишу на этом языкеGo – мало встроенных функций, даже min/max, теперь уже есть, но тогда не было, также нужно конвертировать int в float и обратно, тратишь лишнее время, хотя код и предсказуемыйPython – лаконичный код, много встроенных функций, которые помогают решать задачи (Counter, defaultdict, divmod, lambda и т.д.), время тратишь именно на решение задачи, а не на печатания и прочее, скорость на собеседовании очень важна.
4. Как найти время на задачи?
   В моем случае я старался решать по 2 задачи в день, одну задачу до начала работы и вторую задачу после работы. На выходных уделял больше времени, смотрел видео, читал статьи, старался решать больше задач, также старался повторно решать старые задачи, чтобы закрепить тему и задачу.
5. Нужно ли покупать leetcode premium?
   Самое полезное у premium – вы можете посмотреть в каких компаниях давали ту или иную задачу, если вы готовитесь к конкретной компании, то рекомендую, иначе достаточно бесплатной версии, т.к. видео объяснение задачи можно найти на канале Neetcode(ссылка ниже) и т.д.
6. Стоит ли покупать доступ к educative.io?
   Очень много видел рекомендаций курса Grokking Coding Interview Patterns от educative, но не нашел этот курс очень полезным, единственное понравилось визуальное объяснение, но на мой взгляд лучше посмотреть видео на ютуб
7. Стоит ли покупать доступ к algoexpert.io?
   На мой взгляд очень полезный ресурс, для каждой задачи есть подробное объяснение, чуть ли не каждое видео по 30-50 минут. На сайте постоянно проходят разные акции и можно ухватить все курсы на год за 99$, адекватная цена, приятный сайт, много тест кейсов для задач и сам редактор приятный и удобный

Результат

1. Достиг свою изначальную цель, ради которой и начинал решать алгоритмы – прохождение кодинг интервью, один из этапов, которые обязательны в FAANG компаниях, уже прошел в нескольких компаниях и что самое главное – теперь нет страха перед этим этапом.
2. Более глубоко начал понимать структуры данных, раньше понятия не имел, что такое heap, а сейчас имею полное представление об этой структуре, а также о других структурах.
3. В процессе работы начал чуть иначе смотреть на код, где-то видишь, что можешь использовать больше памяти и сократить time complexity, а где-то наоборот.
4. Последнее, но не по важности – фитнес для мозга, перешел из уровня – “не хочу – не буду”, до уровня – “хочу решать задачи каждый день”

Читайте также на Tproger: как подготовиться к техническому интервью в ИТ-компанию и алгоритмы и структуры данных для начинающих.

Полезные ссылки

1. Пожалуй самый полезный канал, где человек в доступной форме объясняет задачу и решение.
2. Тоже очень много полезных видео с объяснениями разных структур данных.
3. Объясняет на доске структуры данных, задачи.
4. insidecode
5. geekific
6. MichaelMuinos
7. NickWhite
8. Cracking FAANG

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

Как устроены грейды в IT

Грейды — разделение одной должности на несколько категорий в зависимости от знаний и умений сотрудника.

В IT-сфере у специалистов три грейда: Junior, Middle, Senior. Грейдирование позволяет привязать зарплату к компетенциям работника, мотивировать и стимулировать его. Чтобы расти в деньгах и работать над более интересными проектами, разработчики прокачивают компетенции и повышают грейд.

Нередко можно услышать, что грейды в IT условные:

• разные компании к одному и тому же уровню специалиста выдвигают разные требования
• в некоторых компаниях деления на джунов и мидлов вообще нет

Но практика доказывает обратное. Мы изучили 100 открытых вакансий на hh.ru и увидели: компании часто ищут разработчиков определённых уровней, а требования к хард- и софт-скилам у джуна и мидла отличаются.

Чем отличается джун от мидла

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

Фреймворки

• Джун знает популярные фреймворки, например React, Laravel, Sinatra, Django, Spring. Задачи решает по шаблону, с помощью опытных коллег.
• Мидл уверенно владеет одним или несколькими популярными фреймворками. Разбирается в асинхронном программировании. Решает нестандартные задачи.

Git и GitHub

• Джун знает о проектах на GitHub. Может к ним присоединиться, чтобы помочь исправить документацию или несложную ошибку. Пишет код и отправляет его опытным коллегам на ревью и публикацию.
• Мидл работает с Git: возвращается к исходным файлам, просматривает историю изменений, восстанавливает любые данные, работает с файлами вместе с коллегами. Размещает проекты на GitHub, ведёт ветки, делает коммиты.

Алгоритмы

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

Инструменты разработки и инженерные практики

• Джун навыком не владеет.
• Мидл умеет покрывать код тестами и правильно его организовывать.

Код

• Код джуна работает, но его трудно читать и поддерживать.
• Мидл пишет чистый простой код, который легко поймут другие члены команды. Понимает принципы контейнеризации приложений. Умеет работать с Docker.

Понимание бизнес-потребностей

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

Умение составлять план и работать по нему

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

Насмотренность

• Джун знает 1-2 способа, как решить задачу.
• Мидл знает современные тренды. Видел и отмечал хорошие решения других разработчиков, использует их в работе.

Самостоятельность

• Джун работает под руководством опытных коллег.
• Мидл самостоятельно справляется с задачами.

Форс-мажоры

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

Коммуникативные навыки

• Джун, если что-то не знает, задаёт абстрактные вопросы: «Как исправить?», «Что делать, чтобы работало?»
• Мидл, если возникла проблема, понимает, что нужно исправить. Задаёт коллегам конкретные вопросы. Анализирует работу менее опытных сотрудников. Подсказывает, как улучшить решение. Делится опытом и знаниями с новичками и стажёрами.

Как можно повысить свой грейд: 3 способа

Опытные разработчики утверждают: чтобы подрасти, джуну понадобится от года до трёх лет.

Сделать это можно несколькими способами.

Окончить курсы

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

Иногда курсы проводят и сами работодатели. Например, в школе «МТС.Тета» обучают Golang-разработчиков, аналитиков, фронтендеров и т. д. Так компании выращивают специалистов под свои задачи и приглашают их на работу.

Поработать стажёром

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

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

Например, в МТС сейчас набирают тестировщиков, разработчиков, аналитиков.

Самостоятельно

Прокачать скилы исключительно своими силами сложно по двум причинам:

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

Из-за этого на повышение грейда может уйти больше времени. Но обучение на курсах тоже не гарантирует ни быстрый и лёгкий вход в IT, ни мгновенное развитие карьеры.

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

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

Есть много способов повысить грейд бесплатно:

• смотреть видео на YouTube;
• читать книги и статьи;
• консультироваться с опытными разработчиками, которые помогут составить дорожную карту обучения;
• проходить бесплатные курсы, одобренные IT-сообществом (про них мы рассказывали в этой статье).

Конечно, на самостоятельное обучение потребуется больше времени: на учёбу придётся тратить 3–5 часов ежедневно. Можете ли вы себе это позволить, или работа, семья и домашняя рутина съедают каждую свободную минуту — это уже другой вопрос.

Пошаговый план: как джуну стать мидлом за год

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

Например, курс для ‎Python-разработчика выглядит примерно так.

В первый месяц студенты изучают и отрабатывают на практике:

• Понятие «Качество кода». Стандарты оформления кода.
• Работу с системой контроля версий Git.
• Создание схемы базы данных и определение необходимых ограничений целостности.
• Процесс вставки данных.
• Нереляционные базы данных на примере NoSQL.
• Выбор фреймворка. Базу данных Django.

Во второй месяц:

• Технологии ORM.
• Разработку серверной части Python с помощью Django.
• Платформу Docker.
• Фазы обработки запросов Nginx.

В третий месяц:

• Поисковую систему Elasticsearch.
• Полнотекстовый поиск и архитектуру ETL.
• Асинхронный подход, итераторы, генераторы и корутины.
• Асинхронные фреймворки: Twisted, AIOHTTP и FastAPI.

В четвёртый месяц:

• Код-ревью: понятие и общие требования.
• SOLID-принципы программирования.
• Этапы и виды функционального тестирования.
• Понятие API и плюсы работы с программным интерфейсом.

В пятый месяц:

• Сервис аутентификации и авторизации пользователя в проекте.
• Работу с чувствительной личной информацией: безопасность, шифрование, хеширование и управление доступом к ней.
• Flask и Redis.

В шестой месяц:

• OAuth 1.0, OAuth 2.0 и OpenID.
• Работу с капчей и двухфакторной авторизацией.
• Общение между микросервисами.
• Настройку устойчивости сервиса к нагрузкам и изменениям API.
• Внедрение в AsyncAPI авторизации, управление уровнем нагрузки и быстрое нахождение проблем.

В седьмой месяц:

• Работу и функции UGC. Планирование сервиса.
• Описание архитектуры и правила её проектирования.
• Выбор хранилища, событийную работу с данными и работу с Kafka.
• Подходы к хранению и обработке данных, которые не помещаются на один сервер.

В восьмой месяц:

• Ещё одно распределённое хранилище, хранение данных и оптимизацию хранения и обработки.
• CI/CD: построение непрерывной интеграции для приложения.
• Логирование в микросервисной архитектуре.

В девятый месяц:

• Сервис уведомлений.
• Механизм отправки сообщений пользователям и единую политику контактов.
• Проектирование системы коммуникаций.
• Устройство e-mail и шаблонизаторов электронной почты.
• Брокер сообщений RabbitMQ. Сервисы транзакционной рассылки писем и сокращённые ссылки.
• CI/CD-конвейеры.

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

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

Запомнить

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

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

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

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

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

Писать код на JavaScript с таким тезисом звучит как вызов и в какой-то степени абсурдно, не правда ли?

Вспомните, как часто вам приходилось писать подобный код в JSX, чтобы показать или скрыть компонент:

Давайте перепишем этот кусочек кода в более декларативной манере:

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

Наличие свойства `visible` будет подталкивать нас к написанию декларативного кода несмотря на то, что сам компонент частично реализован в императивном стиле.

Попробуем разобрать логический оператор `switch`, который является не только ближайшим родственником `if`, но и любимчиком многих разработчиков:

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

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

Основываясь на вышеупомянутую идею, перепишем JSX-код в виде наборов функций. Стоит учесть, что `switch/case` — это зарезервированные слова JavaScript, поэтому мы добавим к ним нижние подчеркивания:

Как вы можете заметить, декларативный код не обязательно означает HTML, JSX или SQL. В JavaScript мы можем представить синтаксис этих языков с помощью функций. Если нас учили, что функции должны представлять собой действия и их названия должны начинаться с глагола, например: `find`, `setTitle`, то в данном случае наши функции не всегда будут выражать действие и могут обозначать сущность. К примеру, SQL-запрос можно записать в следующем виде:

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

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

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

Предлагаю еще раз взглянуть на конструкции `switch/case` и представить их в виде обычной функции:

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

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

Для ясности, предлагаю развернуть функцию `selectComponent`, после вызова функций `when` мы получим следующий код:

Гибкость проявляется в том, что мы сможем создать множество других версий `when`, но главная функция `select` не потребует изменений. Ниже пример функции с поддержкой ленивой загрузки компонентов:

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

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

В следующей статье мы подробно рассмотрим данную технику на примере создания редьюсеров Redux. Узнаем, как заменить `try/catch` и продолжим обсуждение функционального программирования.

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

В такой ситуации немалую пользу принесет навык именования объектов кода.

Как назвать переменную — вопрос сложный и болезненный. Его обсуждают авторы на Хабре, за плохие попытки осуждают на Stack Overflow. Ситуацию высмеивают в мемах. Если назвать переменную неправильно — или просто странно — люди, которым впоследствии придётся читать и рефакторить ваш код, запутаются. А после придут узнавать, что вы имели в виду под uber_magic_cat и где расширенные комментарии.

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

Сперва вспомним базу: PEP 8

PEP (Python Enhancement Proposal) – руководство по улучшению кода, описывает рекомендации и стандарты, которые делают код более читаемым и понятным. Вот его основные принципы.

Отступы и пробелы

• Используйте четыре пробела для каждого уровня отступа. Не используйте табуляцию;
• Избегайте пробелов в конце строки;
• Добавляйте пустые строки между функциями и классами — и по обе стороны от операторов.

Максимальная длина строки

• Ограничивайте строки кода до 79 символов (это оптимальная длина для среднестатистического экрана);
• Если выражение длинное, делайте перенос как в примере ниже:

Импорты

• Группируйте импорты в следующем порядке: стандартные, сторонние библиотеки, самописные модули. Разделяйте группы пустыми строками;
• Импортируйте только необходимые компоненты.

Пробелы до и после операторов

• Используйте пробелы до, после операторов (= + — * / и проч.) и после запятых;
• Не добавляйте лишних пробелов: они могут ухудшить читаемость кода.

Имена переменных и функций

• Имена должны легко читаться, для разделения слов используйте нижние подчеркивания (например, record_count, calculate_total);
• Для констант используйте ЗАГЛАВНЫЕ_БУКВЫ_С_ПОДЧЕРКИВАНИЯМИ;
• Не начинайте название с цифры;
• Избегайте зарезервированных создателями ЯП слов (list, dict и так далее).

Комментарии

• Добавляйте пояснительные комментарии для сложных частей кода;
• Пишите комментарии с заглавной буквы, а текст отделяйте двумя пробелами от символа #.

Документация

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

Логические блоки

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

Лучше так:

Зайдем немного глубже

Теперь хочу обратить ваше внимание на пятый пункт — «Имена переменных и функций». Вы когда-нибудь задумывались, какими частями речи именовать тот или иной объект? Классу лучше быть существительным, функции – сказуемым, это, кажется логичным. Но как быть с остальными объектами?

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

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

Переменные

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

• Используйте аббревиатуры. Так в моём боте выглядит переменная, содержащая идентификатор пользователя Telegram:

• Оставляйте неизменными названия переменных, которые устоялись в документации. Порой проще дописать комментарий об объекте и найти подсказку в Stack Overflow, чем получить понятное название, содержимое которого спустя месяц не отладить:

• Опускайте гласные в существительных. В рунете этой практике только предстоит устояться. А зря. Даже частичное опущение подойдет:

Функции

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

Столбцы таблиц и столбцов

С этим сталкиваюсь на практике практически каждый день. Вот основные принципы, которые я определила (думаю, во многом рекомендации у специалистов с опытом совпадут):

• По умолчанию именуйте столбцы по-английски. Большая часть библиотек сегодня поддерживает обращение через квадратные скобки (для случаев, когда в названии не латиница). Но если название станет аргументом, передаваемым через командную строку, то придётся запоминать, как именно передавать кириллицу:

• Если решили именовать столбец по-русски, старайтесь использовать небольшое название (до 20 символов): такое при многократном обращении к столбцу не потребуется долго набирать:

Файлы

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

Однако если речь идет о регулярном использовании, лучше «вложиться»:

• Гуглите и используйте аббревиатуры. К примеру, датафрейм о пациентах, прошедший Предварительную обработку данных (Exploratory Data Analysis) и выгруженный в файл, можно назвать ‘patients_eda.csv’.
• Пишите в README пояснения к скриптам. Документация репозитория выручит, если придумать хорошее название не удастся.

Заключение

Работа с именованием переменных постепенно становится проще. Уже сегодня можно спросить у ИИ-расширения для VSCode Codeium, что делает тот или иной объект — и отталкиваться от ответа. Но порой ответы бывают малополезными:

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

Встречали странные имена в коде? Поделитесь в комментариях.

С первой статьей цикла вы можете познакомиться по ссылке.

1. Форматирование многострочного вывода

Если вы хотите, чтобы вывод напоминал табличку с одинаковым отступом, то при использовании F-строк добавьте интерполируемой переменной двоеточие и число, одинаковое для всех print(), например, 10. Это «резервирует» пространство из 10 символов:

Вывод будет приятным и опрятным:

2. Частичное совпадение пользовательского ввода

Эта замечательная фича позволяет справляться с ситуациями, когда пользователь вводит не все, что от него ожидается. Фишка работает в версиях Python не ниже 3.10:

3. Выборка простых чисел в списке любого размера

Выбирать простые числа приходилось мне на практике разве что во время учёбы, так что найти этому коду реальное применение непросто. Однако его легко переиначить для поиска любых других типов чисел – чётных / нечётных / делимых на определенное число:

4. Словарное включение

Многим из нас знакомо списковое включение (List Comprehension), которое позволяет за одну строку кода сгенерировать список:

Оказывается, Python поддерживает аналогичный функционал для словарей! Код ниже генерирует словарь, где у каждого имени определяется длина в символах:

5. Резервирование символов

С помощью операторов > / < / ^ вы можете добавлять выходному значению символы, к примеру, облегчающие поиск среди других выходных значений:

Как видно в сниппете выше, < добавит символы после, > – до, а ^ – окружит с двух сторон.

6. Splat-оператор

Splat (одна звездочка) расширяет коллекцию до позиционных аргументов, а splatty-splat (две звездочки) — словарь до именованных аргументов:

Этот код:

Равнозначен этому:

7. Фильтрация списка без цикла

Здесь неожиданно выделился модуль itertools. Если у нас есть два списка с именами и идентификаторами:

То вы можете выбрать из списка leaders только те, где значения selector равны единице:

8. Подсчёт числа элементов в списке

Помимо способности collections.Counter() понимать, что именно в строке нужно подсчитать:

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

9. Поиск отличий в списках

Допустим, у нас есть две длинные строки, и мы хотим найти отличия. seq1 и seq2 в сниппете ниже – это последовательности генов:

Можно использовать комбинацию zip() и enumerate(). Первая сопоставит символы с одинаковыми индексами, а вторая – присвоит каждой паре символов порядковый номер (всего 24). Чтобы найти отличающиеся символы, достаточно сравнить символы попарно в цикле for:

10. Перегонка кортежа в словарь

Допустим, у нас есть кортеж, где каждое значение – строка из двух символов:

Если «навесить» функцию dict(), то в результате мы получим словарь с разделенными на ключ – значение парами:

Заключение

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

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

ВРЕЗКА. Стоит отличать их от магических методов IPython, которые делают работу в Google Colaboratory / Jupyter Notebook удобнее. Если вы хотите познакомиться с последними поближе, прочитайте мою статью “Топ самых полезных магических команд для завсегдатаев Python”.

Например, когда вы выполняете операции, такие как сложение (+), вычитание (-), умножение (*), и деление (/), Python автоматически вызывает соответствующие “магические” методы (__add__, __sub__, __mul__, и __div__ соответственно).

Слово «dunder» здесь – не ругательство, оно отсылает к двойному подчеркиванию. Два underscore нужны только для того, чтобы предотвратить конфликт имен с другими методами, реализованными ничего не подозревающими программистами. И внедрил их, конечно, создатель языка Гвидо ван Россум.

Да кому нужны эти Dunder-методы?

Чтобы понять, зачем этот класс методов выделен в отдельную группу, рассмотрим пример из треда на Stack Overflow. Пользователь Greg Beech спрашивает, зачем вообще нужны такие усложнения, если вместо __len__ можно использовать просто len()? Замечательный сниппет от Mangu Singh Rajpurohit раз и навсегда отвечает на этот вопрос, на мой взгляд:

«Представьте, что у вас есть два словаря, и вы хотите их сложить:

При исполнении этого кода будет вызываться ошибка:

Ошибка TypeError гласит, что словари складывать нельзя. А ведь нам так надо! Так что давайте добавим классу “словарь” этот функционал. Точнее, инициируем дочерний класс AddableDict:

И вуаля! Словари складываются:

Некоторые интересные Dunder-методы

1. __init__:

Если у вас есть определенные классы в Python, вы обязательно встретитесь с методом __init__. Он отвечает за инициализацию экземпляра класса, поэтому именно в нем вы обычно устанавливаете его неотъемлемые атрибуты – например, длина ребра квадрата:

2. __call__:

Этот метод позволяет создать так называемые «вызываемые» объекты, то есть их можно вызывать как функции.

3. __getitem__ и __setitem__:

Методы позволяют обращения к объекту по индексу или ключу, как если бы это был список или словарь.

4. __iter__ и __next__:

Эти методы позволяют создавать итерируемые объекты, которые можно использовать в цикле for.

5. __enter__ и __exit__:

Эти методы используются для создания контекстных менеджеров (то есть объектов, которые можно использовать в блоке with), и позволяют управлять ресурсами, которые нужно освободить после использования.

При входе и выходе из блока with будут выведены соответствующие сообщения.

И небольшая шпаргалка

Вашему вниманию перечень несложных методов, которые могут пригодиться, если вы в целом готовы впустить Dunder’ы в свой код:

Заключение

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

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

Малый бизнес в борьбе за кадры

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

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

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

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

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

В поиске золотой середины: ау, мидлы!

Например, мы сильно споткнулись на вакансии full stack-разработчика, то есть человека с хорошим пониманием каждого уровня разработки. Суперкандидаты предпочитают уходить в крупные корпорации, другие же не дотягивают по компетенциям даже до среднего уровня. Не все при это думают о том, что в крупной компании – меньше свобода действий, больше бюрократии. Это традиционная «плата» для сотрудников корпораций. В итоге мы на какое-то время отказались от этой вакансии и вместо full-stack взяли еще одного backend-ера, усилив команду.

Примерно такая же история приключилась с разработчиком C++. Через 3 недели активных поисков по Москве мы переключились на другие регионы. Нужного кандидата нашли в Иркутске. Он приехал на две недели в Москву (билеты и проживание мы оплатили), познакомился с командой, задачами и сейчас работает удаленно. Конечно, мы опасались брать кандидата из другого города и часового пояса — с разницей в 5 часов. Но в конечном итоге мы получили опытного сотрудника с широким профессиональным кругозором. Сейчас он возглавляет отдел разработки.

Product-менеджера мы искали около полугода. Находили хороших специалистов уровней middle и senior, но они выбирали более крупных работодателей, у которых уже есть выстроенные процессы. Многих почему-то смущало быть первопроходцем. Поскольку ранее продакта в компании не было, очевидно, часть процессов нужно было выстраивать с нуля. Конечно, это объемная работа, но, на наш взгляд, идеальный путь для профессионального развития. И показательно, что часть кандидатов не стала брать на себя эти обязательства.

Как молодая ИТ-компания работает с кадрами

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

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

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

Как может сложиться карьера в стартапе

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

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

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

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

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

Шаг 1: Создание модуля

Создадим новый файл с именем mymodule.py и откроем его в любимом текстовом редакторе.

Кстати, если вы только начинаете писать код на Python и еще не знаете, в какой программе это делать, то вот моя подборка питонических IDE с хорошим UI / UX.

Здесь вы будете определять функции и классы для вашего модуля mymodule.py.

Так мы определяем:

• функцию greet(), которая принимает аргумент name и выводит приветствие;
• класс Person, который имеет конструктор __init__() для установки имени;
• метод say_hello(), который выводит приветствие с использованием имени объекта класса.

Шаг 2: Использование модуля

Теперь модуль можно использовать его в других программах. Создадим новый файл с именем main.py и импортируем mymodule следующим образом:

Здесь мы используем ключевое слово import и вызываем функцию greet().

API как следующая стадия развития модуля

Если ваш модуль разрастается, становится полноценным проектом и обретает, скажем, динамические данные, то самое время ему стать полноценным API (Application Programming Interface – программный интерфейс приложения). Выражаясь простыми словами, то это следующая стадия развития вашего модуля.

С разработкой полноценных API помогают сервисы вроде swagger.io, который ускоряет подгонку вашего модуля к стандартам RESTful, и создание документации. Но об этом – уже в следующей статье.

Когда в собственном модуле нет необходимости

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

Заключение

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

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

Структура книги

Обложка книги с подколом от издательства o’Reilly: на иллюстрации песчаная игуана Намакуа.

Издание разделено на несколько тем:

• модель данных;
• структуры данных;

• функции как объекты;

• объектно-ориентированные идиомы (устоявшиеся паттерны питонического ООП);

• поток управления (порядок усвоения компилятором того или иного компонента программы);

• метапрограммирование (способность программы использовать соседние скрипты).

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

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

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

Многие тезисы автор подкрепляет кодом. Посмотрите на простой пример — списковое включение (List Comprehension):

Максимально полезной для меня стала глава №5 — о функциях. Помимо необходимого минимума по теме и десятка-другого must-have терминов, вроде функций высшего порядка и анонимных функций, автор рассказывает и об аннотации ф., интроспекции и прочем.

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

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

Рамальо также прекрасно показывает протокольные свойства технологии. То есть обращает Python не в объектно-, а в протокольно-ориентированный язык (ПОП). Покажу на примере.

Разницу между ООП и ПОП можно вкратце описать так. Представьте, что вы создаёте игру, в которой есть транспортные средства. Есть классы «автомобиль», «мотоциклы», и их логично сделать подвидами базового класса «моторный транспорт». Всё выглядит замечательно, пока игра не переносится в XXII век, где есть летающие автомобили. Создавать ещё один базовый класс, в котором соединяются обе функциональности, не стоит. Здесь на помощь придёт протокол, он как раз позволит автомобилям летать во второй половине игры о будущем, но ездить в первой части про настоящее.

Если в Swift, где ПОП был впервые представлен как концепция, протоколы – это основа основ, то в Python за идею «отыгрывают» методы. Подробнее об этом прекрасно рассказывает пользователь StackOverflow claudio в этом треде.

Наконец, страсть Рамальо к Python проявляется в тексте. Это делает книгу не только образовательным ресурсом, но и источником удовольствия.

Недостатки

Глубина и темп книги могут не подойти абсолютным новичкам, поскольку:

• Сделано допущение о том, что 200–300 базовых терминов усвоены и не замедляют особо чтение.
• Несмотря на хороший перевод издательства ДМК, английского в коде всё равно очень много, так что знание языка считаю необходимым.
• Стоимость массивного издания на Ozon держится в районе 3,5 тысячи рублей, что автоматом наводит на мысль купить электронную версию. Пришлось останавливать себя, чтобы не спиратить.

Работа Рамальо рекомендуется тем, кто уже имеет базовое представление о Python и хочет глубже понять философию и принципы разработки. Новичкам же прекрасно подойдёт другой бестселлер – «Изучаем Python» Марка Лутца.

Заключение

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

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

Рассмотрим тему регулярных выражений от простого к сложному.

Что такое регулярные выражения

Регулярные выражения (ещё их называют Regular Expressions, сокращённо regex или regexp, регулярки) — специальные шаблоны, которые используют для поиска и обработки текста. Для поиска в них можно задавать дополнительные команды, например игнорирование регистра.

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

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

Например, этот шаблон ищет email-адреса:

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

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

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

Например, нам нужно проверить номер телефона в форме регистрации:

В этом примере мы создали функцию validatePhoneNumber, которая принимает номер телефона в качестве аргумента и возвращает true, если номер телефона является действительным номером для России, и false в противном случае.

В регулярном выражении phoneRegex мы использовали символ ^, чтобы указать, что номер телефона должен начинаться с «+7» или «8» (возможно, без плюса). Затем мы использовали символы \d для указания цифр и {10} для указания количества цифр в номере телефона (10 цифр).

В примере использования мы передали строку «+79123456789» функции validatePhoneNumber и проверили результат.

Как создать регулярное выражение в JavaScript

Есть два способа создания регулярок — разберём каждый.

1. Конструктор RegExp()

Конструктор RegExp() позволяет создавать регулярные выражения на основе строки, передаваемой ему в качестве аргумента. Формат конструктора RegExp() выглядит следующим образом:

const regex = new RegExp("pattern", "flags");

Где «pattern» — это строка, содержащая регулярное выражение, а «flags» — дополнительные флаги, определяющие, как будет работать регулярное выражение. Например, флаг i указывает, что регулярное выражение должно игнорировать регистр символов.

Вот пример использования конструктора RegExp() для создания регулярного выражения, которое ищет все цифры в строке:

const regex = new RegExp("\\d", "g");

Здесь мы передаём строку \d в качестве первого аргумента, что означает «любая цифра». Флаг g указывает, что регулярное выражение должно искать все совпадения в строке.

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

2. Литералы

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

Вот как он выглядит:

const regex = /pattern/flags;

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

const regex = /\d/g;

Здесь мы используем литерал /\d/g, который означает «любая цифра» с флагом g, указывающим, что регулярное выражение должно искать все совпадения в строке.

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

Оба эти способа создания регулярных выражений в JavaScript эквивалентны друг другу — выбирайте тот, который вам удобнее.

Базовый синтаксис регулярных выражений в JavaScript

Разберём основу синтаксиса регулярных выражений в JavaScript.

Шаблоны и метасимволы

Шаблоны — набор символов, которые используют для поиска определённых сочетаний символов в тексте. Метасимволы — специальные символы, которые используют для составления шаблонов.

Вот несколько примеров шаблонов и метасимволов:

. — соответствует любому одиночному символу, кроме символа новой строки.

* — соответствует нулю или более повторениям предыдущего символа.

+ — соответствует одному или более повторениям предыдущего символа.

? — соответствует нулю или одному повторению предыдущего символа.

^ — соответствует началу строки.

$ — соответствует концу строки.

() — определяет группу символов, которые могут быть повторены.

Квантификаторы и модификаторы

Квантификаторы — метасимволы, которые определяют количество повторений предыдущего символа.

Некоторые квантификаторы:

{n} — соответствует ровно n повторениям предыдущего символа.

{n,m} — соответствует от n до m повторений предыдущего символа.

{n,} — соответствует n или более повторениям предыдущего символа.

? — делает предыдущий квантификатор ленивым, т. е. соответствует наименьшему возможному количеству повторений.

Пример использования квантификатора:

const pattern = /a{3}/; // соответствует трём символам "a" подряд

В тексте, который будет обрабатываться с помощью этого регулярного выражения, будут найдены все вхождения трёх символов a подряд. Например, строка «baaaad» будет соответствовать шаблону, а строка «abaa» — нет.

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

Некоторые модификаторы:

g — глобальный поиск, ищет все совпадения в строке.

i — игнорирование регистра, игнорирует различия между верхним и нижним регистром.

m — многострочный поиск, позволяет искать совпадения в нескольких строках.

Пример использования модификатора:

const pattern = /test/gi; // соответствует строкам "test" или "Test" или "TEST" глобально и без учёта регистра

Группы и обратные ссылки

Группы — последовательности символов, заключённые в скобки (), которые могут повторяться с помощью квантификаторов. Группы также позволяют использовать обратные ссылки, которые ссылаются на результат совпадения группы в регулярном выражении. Обратная ссылка обозначается символом \ и номером группы, например, \1 ссылается на первую группу.

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

​​const pattern = /(\w+)\s\1/; // соответствует повторяющейся последовательности символов, разделённой пробелом

В этом примере группа (\w+) соответствует любой последовательности символов, состоящей из буквенно-цифровых символов и подчёркивания. Затем \s соответствует пробелу, а \1 обратно ссылается на первую группу (\w+), так что регулярное выражение соответствует только тем строкам, в которых последовательность символов повторяется через пробел.

Экранирование в регулярных выражениях

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

Для экранирования символа используется обратный слеш \.

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

Примеры:

• Поиск всех цифр в тексте.

• Замена всех пробелов на символ подчёркивания.

• Замена всех точек в тексте на запятые, кроме точек, которые находятся внутри чисел.

Как использовать регулярки с методами объекта RegExp и String

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

Метод test()

Метод test() проверяет, соответствует ли регулярное выражение заданной строке. Метод возвращает true, если строка соответствует регулярному выражению, и false, если не соответствует.

Пример использования метода test():

В этом примере мы используем метод test() для проверки, содержит ли строка str подстроку «Hello». Регулярное выражение /Hello/ соответствует строке «Hello», и метод test() вернёт true.

Метод exec()

Метод exec() используется для поиска совпадений регулярного выражения в заданной строке. Метод возвращает массив, содержащий найденное совпадение и дополнительную информацию о нём.

Пример использования метода exec():

В этом примере мы используем метод exec() для поиска совпадений регулярного выражения /Hello/ в строке str. Метод exec() возвращает массив, содержащий найденное совпадение «Hello», индекс первого символа совпадения в исходной строке и саму исходную строку.

Метод match()

Метод match() используется для поиска всех совпадений регулярного выражения в заданной строке. Метод возвращает массив, содержащий все найденные совпадения.

Пример использования метода match():

В этом примере мы используем метод match() для поиска всех совпадений регулярного выражения /the/gi в строке str. Метод match() возвращает массив, содержащий все найденные совпадения, включая повторения.

Метод replace()

Метод replace() принимает два аргумента: регулярное выражение и строку, на которую нужно заменить найденное совпадение. Этот метод ищет все совпадения с заданным регулярным выражением в исходной строке и заменяет их на указанную строку.

Пример использования метода replace():

В этом примере мы используем метод replace() для замены слова «мир» на «земля» в строке «Привет, мир!» Регулярное выражение /мир/ ищет все совпадения со словом «мир» в строке, и метод replace() заменяет их на слово «земля». Результатом работы метода является новая строка «Привет, земля!»

Метод search()

Метод search() принимает один аргумент — регулярное выражение. Он ищет первое совпадение с заданным регулярным выражением в исходной строке и возвращает индекс первого символа совпадения. Если совпадение не найдено, метод возвращает -1.

Например:

В этом примере мы используем метод search() для поиска первого совпадения со словом «текст» в строке «Это текст для примера». Регулярное выражение /текст/ ищет первое совпадение со словом «текст» в строке, и метод search() возвращает индекс первого символа этого совпадения, который равен 4.

Метод split()

Метод split() принимает один аргумент — регулярное выражение. Он разбивает исходную строку на массив подстрок, используя заданное регулярное выражение как разделитель.

Пример использования метода split():

В этом примере мы используем метод split() для разделения строки «Это текст для примера» на массив слов, используя регулярное выражение / / в качестве разделителя. Регулярное выражение / / ищет все пробелы в строке, и метод split() использует их в качестве разделителя для разделения строки на массив слов. Результатом работы метода является массив [«Это», «текст», «для», «примера»].

Когда и как использовать регулярки на практике

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

Разберём подробнее несколько вариантов использования.

Валидация email-адресов

Один из популярных примеров использования регулярных выражений — валидация email-адресов.

Шаблон будет выглядеть так:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/, где

^ — начало строки

@ — символ «@»

\. — символ «.» (экранированный с помощью слеша)

$ — конец строки

Таким образом, этот паттерн соответствует любому email-адресу, который состоит из локальной части (часть до символа «@») и доменной части (часть после символа «@» и до символа «.») с верным форматом.

Для проверки email-адреса на соответствие шаблону можно использовать метод test():

В этом примере функция validateEmail() принимает email-адрес в качестве аргумента и использует регулярное выражение для проверки его соответствия формату. Метод test() возвращает true, если email-адрес соответствует паттерну, и false в противном случае.

Форматирование текста

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

Рассмотрим пример форматирования даты с использованием регулярных выражений.

Допустим, у нас есть дата в формате «гггг-мм-дд» (например, «2023-03-29»), а мы хотим преобразовать её в формат «дд.мм.гггг» (например, «29.03.2023»). Для этого мы можем использовать регулярное выражение, чтобы разделить дату на отдельные части, а затем использовать эти части для создания новой строки в нужном формате.

Давайте разберём это регулярное выражение:

^ — начало строки

(\d{4}) — группа, соответствующая 4 цифрам (год)

— — символ «-«

(\d{2}) — группа, соответствующая 2 цифрам (месяц)

— — символ «-«

(\d{2}) — группа, соответствующая 2 цифрам (день)

$ — конец строки

В этом примере мы используем метод match() для поиска соответствия регулярному выражению в строке date. Если соответствие найдено, метод match() возвращает массив, содержащий соответствующие группы в порядке их появления в регулярном выражении. Затем мы используем эти группы для создания новой строки в нужном формате.

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

Извлечение номеров телефонов из строки

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

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

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

Для этого вы можете использовать следующий код:

В этом примере мы используем регулярное выражение /\+\d\s?\(\d{3}\)\s?\d{3}-\d{2}-\d{2}/g, чтобы извлечь номера телефонов из строки string.

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

Ещё несколько советов по использованию регулярок

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

• Тестируйте регулярные выражения перед использованием. Это позволит выявить возможные ошибки или проблемы в выражении и сделать необходимые исправления. Используйте онлайн-сервисы, такие как regex101.com, regexr.com, regexplanet.com и подобные.
• Не злоупотребляйте использованием регулярок. Иногда другие простые методы могут оказаться более эффективными и лёгкими в понимании.

• Используйте комментарии и форматирование кода, чтобы облегчить его чтение и обслуживание. Регулярные выражения могут быть очень сложными для понимания.
• Используйте библиотеки. Есть множество библиотек уже готовых шаблонов — часто этого достаточно для решения задачи.

Заключение

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

Декораторы — один из самых полезных инструментов в Python, однако новичкам они могут показаться непонятными. Возможно, вы уже встречались с ними, например, при работе с Flask, но не хотели особо вникать в суть их работы. Эта статья поможет вам понять, чем являются декораторы и как они работают. Эта статья — часть нашего полного путеводителя по Python.

Что такое декоратор?

Новичкам декораторы могут показаться неудобными и непонятными, потому что они выходят за рамки «обычного» процедурного программирования как в Си, где вы объявляете функции, содержащие блоки кода, и вызываете их. То же касается и объектно-ориентированного программирования, где вы определяете классы и создаёте на их основе объекты. Декораторы не принадлежат ни одной из этих парадигм и исходят из области функционального программирования. Однако не будем забегать вперёд, разберёмся со всем по порядку.

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

Как работают функции

Все мы знаем, что такое функции, не так ли? Не будьте столь уверены в этом. У функций Python есть определённые аспекты, с которыми мы нечасто имеем дело, и, как следствие, они забываются. Давайте проясним, что такое функции и как они представлены в Python.

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

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

Функции как объекты первого класса

В Python всё является объектом, а не только объекты, которые вы создаёте из классов. Подробнее об объектах и типах данных в Python читайте в отдельном гайде. В этом смысле он (Python) полностью соответствует идеям объектно-ориентированного программирования. Это значит, что в Python всё это — объекты:

• числа;
• строки;
• классы (да, даже классы!);
• функции (то, что нас интересует).

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

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

И тут в дело вступает функциональное программирование, а вместе с ним — декораторы.

Функциональное программирование — функции высших порядков

В Python используются некоторые концепции из функциональных языков вроде Haskell и OCaml. Пропустим формальное определение функционального языка и перейдём к двум его характеристикам, свойственным Python:

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

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

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

Если вы знакомы с основами высшей математики, то вы уже знаете некоторые математические функции высших порядков порядка вроде дифференциального оператора d/dx. Он принимает на входе функцию и возвращает другую функцию, производную от исходной. Функции высших порядков в программировании работают точно так же — они либо принимают функцию(и) на входе и/или возвращают функцию(и).

Пара примеров

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

Здесь мы определили простую функцию. Из фрагмента кода далее вы увидите, что эта функция, как и классы с числами, является объектом в Python:

Как вы заметили, функция hello_world принадлежит типу <class 'function'>. Это означает, что она является объектом класса function. Кроме того, класс, который мы определили, принадлежит классу type. От этого всего голова может пойти кругом, но чуть поигравшись с функцией type вы со всем разберётесь.

Теперь давайте посмотрим на функции в качестве объектов первого класса.

Мы можем хранить функции в переменных:

Определять функции внутри других функций:

Передавать функции в качестве аргументов и возвращать их из других функций:

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

Как работают декораторы

Повторим определение декоратора:

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

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

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

Магия, не иначе! Просто добавив @decorator_function перед определением функции hello_world(), мы модифицировали её поведение. Однако как вы уже могли догадаться, выражение с @ является всего лишь синтаксическим сахаром для hello_world = decorator_function(hello_world).

Иными словами, выражение @decorator_function вызывает decorator_function() с hello_world в качестве аргумента и присваивает имени hello_world возвращаемую функцию.

И хотя этот декоратор мог вызвать вау-эффект, он не очень полезный. Давайте взглянем на другие, более полезные (наверное):

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

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

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

Используем аргументы и возвращаем значения

В приведённых выше примерах декораторы ничего не принимали и не возвращали. Модифицируем наш декоратор для измерения времени выполнения:

Вывод после выполнения:

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

Декораторы с аргументами

Мы также можем создавать декораторы, которые принимают аргументы. Посмотрим на пример:

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

Функция benchmark() на первый взгляд может показаться декоратором, но на самом деле таковым не является. Это обычная функция, которая принимает аргумент iters, а затем возвращает декоратор. В свою очередь, он декорирует функцию fetch_webpage(). Поэтому мы использовали не выражение @benchmark, а @benchmark(iters=10) — это означает, что тут вызывается функция benchmark() (функция со скобками после неё обозначает вызов функции), после чего она возвращает сам декоратор.

Да, это может быть действительно сложно уместить в голове, поэтому держите правило:

Декоратор принимает функцию в качестве аргумента и возвращает функцию.

В нашем примере benchmark() не удовлетворяет этому условию, так как она не принимает функцию в качестве аргумента. В то время как функция actual_decorator(), которая возвращается benchmark(), является декоратором.

Объекты-декораторы

Напоследок стоит упомянуть, что не только функции, а любые вызываемые объекты могут быть декоратором. Экземпляры классов/объекты с методом __call__() тоже можно вызывать, поэтому их можно использовать в качестве декораторов. Эту функциональность можно использовать для создания декораторов, хранящих какое-то состояние. Например, вот декоратор для мемоизации:

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

P.S.

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

• Декораторы не обязательно должны быть функциями, это может быть любой вызываемый объект.
• Декораторы не обязаны возвращать функции, они могут возвращать что угодно. Но обычно мы хотим, чтобы декоратор вернул объект того же типа, что и декорируемый объект. Пример:>>> def decorator(func):... return 'sumit'...>>> @decorator... def hello_world():... print('hello world')...>>> hello_world'sumit'
• Также декораторы могут принимать в качестве аргументов не только функции. Здесь можно почитать об этом подробнее.
• Необходимость в декораторах может быть неочевидной до написания библиотеки. Поэтому, если декораторы кажутся вам бесполезными, посмотрите на них с точки зрения разработчика библиотеки. Хорошим примером является декоратор представления в Flask.
• Также стоит обратить внимание на functools.wraps() — функцию, которая помогает сделать декорируемую функцию похожей на исходную, делая такие вещи, как сохранение doctstring исходной функции.

Часто задаваемые вопросы

Чем декоратор отличается от обычной функции?

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

Можно ли применить несколько декораторов к одной функции?

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

Когда стоит использовать декораторы, а когда — нет?

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

Зачем нужен functools.wraps?

Без functools.wraps декорированная функция теряет своё имя, docstring и другие атрибуты — вместо них отображаются данные обёртки. Декоратор @functools.wraps(func) копирует метаданные исходной функции в обёртку, что упрощает отладку и делает help() полезным для декорированных функций.

Заключение

Надеемся, эта статья помогла вам понять, какая «магия» лежит в основе работы декораторов. Если нужно вспомнить основы — наш гайд по типам данных в Python.

Обязанности интеграционного системного аналитика
Хард скилы интеграционного системного аналитика
Инструменты системного аналитика
Софт скилы системного аналитика
Советы при подготовке к собеседованиям

Обязанности интеграционного системного аналитика

Системный аналитик — это переводчик с бизнес-языка на технический.

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

Чаще системный аналитик принимает требования от бизнес-аналитика. Наши системные аналитики изучают предоставленные документы (BRF, заключения бизнес-анализа), уточняют требования и согласуют их. Бывают случаи, когда требования даёт сразу заказчик, то есть бизнес. Тогда нужно в том числе провести небольшой бизнес-анализ.

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

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

Для части интеграций мы используем корпоративную шину (IBM ESB). В планах полностью отказаться от неё, однако этот процесс трудоёмкий и надо позаботиться о том, чтобы наши потребители не сильно страдали от перехода на новую архитектуру. Сейчас наше целевое решение в части интеграционных взаимодействий — это микросервисная архитектура с использованием REST API и брокеров сообщений (Kafka, IBM MQ, который потенциально будет заменён на ActiveMQ).

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

Во многих организациях подход code first. Аналитики объясняют, что должно приходить на вход и выход, и передают эту информацию разработке в виде оформленной спецификации, либо в виде ТЗ. Дальше разработчики реализуют модель данных на уровне кода, алгоритмов, и на её основе автоматически генерируется контракт сервиса. Это Swagger-контракт или API-спецификация.

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

Есть два способа описать Swagger-контракт: JSON-формат, либо YAML-разметка. Мы используем последнюю. В YAML-разметке мы описываем, что получится в ответ на обращение, все ограничения, и отдаём потребителям. Благодаря этому они понимают, как им работать с сервисом, и могут начать разработку. То есть им не надо ждать, пока мы напишем ТЗ и код, так как в code first контракта без кода не получится.

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

Описание сервиса дополняется UML-диаграммой последовательности. Мы визуализируем работу алгоритмов сервиса, включающих как внутренние вычисления, так и обращение к другим системам и сервисам. Это как раз удобно с композитными сервисами, потому что наглядно видно всех участников процесса.

Хард скилы интеграционного системного аналитика

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

Микросервисы

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

Наши микросервисы реализуются на Java Spring Boot, развёртываются в OpenShift и публикуются на платформе управления API под названием IBM API Connect.

Также важно уметь использовать средства просмотра логов. Мы используем Kibana, а также Zipkin для трассировки цепочки вызовов.

ESB

Это промежуточное ПО, которое представляет собой большой транспортный пересадочный узел для входящих и исходящих потоков. То есть такой хаб, на котором публикуются различные сервисы. Обращение к ним происходит через SOAP, MQ, JMS и т. п. В SOAP-протоколе, например, описывается строго типизированный формат интеграции, то, как должны выглядеть входные и выходные сообщения. Они валидируются по XSD-схеме, при этом используется XML-разметка.

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

Виды интеграций

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

— REST API. В чём отличие REST API от SOAP-сервисов. Как правило, все дают базовый ответ, что REST — это архитектурный стиль, а SOAP — это протокол.

Нужно знать, какие методы используются в REST-сервисе. Многие впадают в ступор, что подразумевается под ними. Это HTTP-глаголы, поскольку REST базируется на HTTP-протоколе. Многие ограничиваются двумя методами — GET и POST, но на деле их больше. Важно понимать, чем они отличаются, если не приходилось с ними работать. Также ожидаем, что кандидат представляет, что такое REST-запрос: где можно передать входные параметры, где техническую информацию, что такое статус-коды, какие категории у них бывают.

— SOAP-сервисы. У нас они остались на шине, но иногда приходится обращаться в мастер-системы по SOAP-протоколу. Важно понимать, из каких артефактов состоит сервис, например, XSD, WSDL.

Очереди и брокеры сообщений

У нас это IBM MQ и Kafka, но важен опыт работы с любым брокером сообщений, так как их концепции похожи. Если соискатель работал с этими инструментами, то спрашиваем, какая разница в построении очередей. Нужно описать, как выглядит взаимодействие — кто подписчик, кто поставщик сообщений. Как брокер себя ведёт: толкает сообщения, либо просто хранит, пока их сам не прочитает подписчик, сколько хранит, удаляет ли. Нам важно, чтобы человек понимал принцип работы системы. Предметно знать необязательно, потому что всё-таки аналитики не проверяют средство просмотра и администрирования очередей или топиков.

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

Инструменты системного аналитика

• Спецификации. YAML-разметка, Swagger и OpenAPI.
• Для документации мы используем не стандартные страницы в Confluence или документы Word, а разметку AsciiDoc. Она лежит рядом с кодом, и в Confluence мы её подтягиваем через плагин.

• Мы работаем в инструменте PlantUML, он позволяет текстом описывать UML-диаграммы, которые затем верстаются в картинку. Всю документацию мы кодим в различных разметках и храним рядом с кодом. В принципе, работа с документацией для интеграционного аналитика в Ренессансе — это скорее кодинг, чем работа в графических и текстовых редакторах.
• Gitlab и Jira.
• Средства для отладки тестирования: Postman, SoapUI для отладки сервисов или автоматизации вызовов. Иногда аналитику необходимо сымитировать вызов. Так он самостоятельно и быстро поймёт логику работы сервиса, входные и выходные параметры и сможет решить, нужны ли доработки. Если бы он лазил в документацию (которая не всегда может быть корректно составлена), то на это бы ушло больше времени, чем предметно что-то вызвать и смотреть на результат.
• Базы данных. Как правило, системный аналитик редко ходит в БД. Но, тем не менее нужно уметь составлять базовый SQL-запрос с выборкой.
• СМЭВ — это контурное взаимодействие с различными государственными ведомствами. С его помощью можно получить актуальную информацию, соответствующую законодательству, не спрашивая клиента.

Софт скилы системного аналитика

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

• Быть коммуникабельным. Регулярно участвовать во внутренних митингах с разработчиками. Также общаться с бизнес-аналитиками, архитекторами и отстаивать свою позицию. Поскольку не всегда те решения, которые предлагают общебанковские архитекторы, могут быть реализованы.
• Не стесняться задавать вопросы. Самый плохой вопрос — незаданный. Нужно включаться в диалог, чтобы собрать максимум требований и закрыть максимум вопросов.
• Участвовать в оценках. Мы оцениваем работу в человеко-днях, также у нас введён процент риска по ней. Чем больше неопределённости, например, непроработанных требований со стороны бизнес-анализа, отсутствие адекватной архитектуры, тем больше риска мы закладываем.

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

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

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

Советы при подготовке к собеседованиям

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

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

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

1. Как мы делали раньше.
2. Bower.
3. Версионирование.
4. Транзитивные зависимости.
5. Разрешение зависимостей.
6. Зависимости для локальной разработки.
7. Плоская модель установки.
8. Ручное разрешение конфликтов.
9. NPM.
10. Конфигурация NPM.
11. Авторизация в NPM.
12. Публикация пакетов.
13. Необязательные зависимости.
14. «Плагины» для пакетов.
15. Переопределение версий.
16. Воспроизводимость.
17. Yarn.
18. Собственный реестр пакетов.
19. Связывание пакетов локально.
20. Фантомные зависимости.
21. Структура зависимостей.
22. PNPM.
23. Будущее менеджмента зависимостей.

Как мы делали раньше

До появления Node.js и NPM подключение библиотек к сайту осуществлялось с помощью тега script прямо в HTML:

<script src=<URL-библиотеки>"></script>

Чтобы это работало, нужно, чтобы по адресу <URL-библиотеки> был размещён .js файл. Сделать это можно было двумя способами:

1. Воспользоваться CDN, на котором уже размещён код библиотеки: <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.1/jquery.min.js"></script>.
   В этом случае у нас не было контроля над тем, что на самом деле получал пользователь, мы делегируем всю работу провайдеру CDN и доверяем ему.
   В качестве бонуса пользователи получали кросс-доменный кеш и если, например, они уже загрузили jQuery на другом сайте, при открытии нашего сайта они получали её из кеша вместо того, чтобы загружать его с CDN заново, так как URL совпадал. К сожалению, этот механизм более не актуален.
2. Скачать код библиотеки и самостоятельно положить его, например, в директорию vendors: <script src="vendors/jquery-3.6.1.min.js"></script>.
   Так мы получали полный контроль над кодом библиотек и способом его получения пользователями. И, при необходимости, могли производить над ними дополнительные преобразования (например, минифицировать).

Второй способ становился всё более актуальным, но с ростом экосистемы JavaScript росло и количество библиотек, подключаемых к сайту. Скачивать все библиотеки вручную и хранить их в репозитории с кодом становилось накладно, поэтому появился инструмент, именуемый Bower.

Bower

Bower — пакетный менеджер. Его основная задача в автоматизации загрузки различных компонентов приложения со сторонних ресурсов. В репозитории с кодом мы в таком случае храним только информацию о том, что ему нужно скачать, в файле bower.json:

(Ничего не напоминает?)

При выполнении команды bower install Bower устанавливает зависимости, указанные в поле dependencies. У Bower есть свой реестр пакетов, из которого он их и скачивает.

Версионирование

В bower.json мы указываем не конкретный URL, по которому он должен загрузить библиотеку, а диапазон версий согласно SemVer. Фактически это — реализация принципа инверсии зависимостей: проект зависит не от конкретного кода, хранящегося на удалённом сервере, а от абстракции в виде диапазона версий. За выбор соответствующей версии и загрузку кода отвечает пакетный менеджер.

SemVer гарантирует, что при выборе любой версии из указанного диапазона проект будет работать.

Как это работает?

Например, мы хотим использовать в своём проекте библиотеку React. Открываем документацию и изучаем API библиотеки, обращая внимание на то, для какой версии библиотеки написана документация (например, 16.1.0).

Первый разряд версии означает изменения API, ломающие обратную совместимость (мажорные), второй — обратно совместимые изменения (минорные). Соответственно, минимальная версия, которая нам подойдёт для использования всего API из документации, — 16.1.0, максимальная, которую мы можем использовать, не опасаясь что проект перестанет работать, — 17.0.0.

Записать такой диапазон можно в виде >=16.1.0 <17.0.0. Для более краткой записи существуют модификаторы диапазона версий, с помощью которых мы можем обозначить тот же самый диапазон как ^16.1.0.

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

Транзитивные зависимости

Bower позволил формализовать и автоматизировать управление зависимостями во фронтенд-разработке. Это подтолкнуло экосистему JavaScript к закономерному росту и, соответственно, усложнению.

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

Зависимости зависимостей проекта называются транзитивными.

Разрешение зависимостей

Пакетный менеджер начинает установку с разрешения (resolution) зависимостей. На этом этапе он анализирует зависимости в поле dependencies и подбирает версии библиотек, соответствующие указанным в нём диапазонам.

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

Зависимости для локальной разработки

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

Но когда мы добавляем библиотеку в свой проект, мы не хотим вместе с исходным кодом загрузить ещё и тонну инструментов (которые, несомненно, полезны самой библиотеке, но нам могут быть не нужн). Поэтому для экономии дискового пространства пользователей библиотек в bower.json появилось поле devDependencies.

devDependencies — зависимости, которые пакетный менеджер установит, только если они являются прямыми зависимостями проекта. Транзитивные devDependencies пакетный менеджер игнорирует.

Плоская модель установки

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

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

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

Ручное разрешение конфликтов

Для разрешения подобных конфликтов в bower.json появилось поле resolutions, позволяющее вручную произвести разрешение транзитивной зависимости.

Тем не менее, выбор одной из нескольких мажорных версий зависимости — не самый лучший вариант. Одна из транзитивных зависимостей с высокой долей вероятности может сломаться. Более безопасно установить обе версии, чего Bower не позволяет.

Решение этой проблемы нашлось в смежной области — бэкенд-разработке на Node.js. Для платформы был разработан свой пакетный менеджер — NPM.

NPM

NPM имел nested-модель установки. Она подразумевает, что для каждой зависимости проекта создаётся своя директория node_modules, в которой изолированно хранятся её зависимости. Это позволяет избежать конфликтов версий.

Поскольку NPM изначально предназначался для Node.js, все пакеты в нём имели модульный формат CommonJS, который не поддерживается в браузере. Соответственно, использовать их для фронтенда было невозможно. Но с появлением Browserify (инструмента, собирающего все CommonJS модули в один файл), пост которого впоследствии занял Webpack, проблема была решена, и разработчики постепенно начали переходить с Bower на NPM.

Для безболезненной миграции с Bower в NPM появился флаг --flat, который меняет модель установки на плоскую.

Переход на nested-модель установки был не бесплатным. Директория node_modules представляла собой довольно глубокую иерархию пакетов, которая занимала колоссальное количество места на диске. А также могла приводить к проблемам из-за ограничения максимальной длины путей на Windows.

Для бэкенда это было приемлемо. Но тянуть на сайт так много библиотек, среди которых множество дубликатов, никому не хотелось. Поэтому в NPM 3 появилась новая hoisted-модель установки и механизм дедупликации пакетов.

Hoisted-модель установки представляет собой нечто среднее между плоской и nested-моделями. В ней пакеты по возможности хранятся в верхней директории node_modules, а вложенности возникают только в случае конфликтов версий.

Работа модели обеспечивается механизмом разрешения модулей в Node.js. При поиске пакета, указанного в require, Node.js проходит по всем директориям node_modules снизу вверх, то есть «всплывает» (аналогично всплытию переменных в JavaScript). Поэтому модель и называется hoisted.

Конфигурация NPM

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

В отличие от многих других конфигурационных файлов (например, .gitignore или .prettierrc), .npmrc не ищется рекурсивно. В общем случае NPM ожидает его только в двух местах: непосредственно в директории проекта и в домашней директории текущего пользователя (~/ для Linux и Mac OS или %homepath% для Windows). Оба файла будут объединены, при этом значения параметров проекта будут иметь приоритет над пользовательскими.

Чаще всего в .npmrc указывается параметр registry, который отвечает за выбор реестра пакетов. По умолчанию его значение равно https://registry.npmjs.com.

Можно указать отдельный registry для пакетов определённой организации. Предположим, компания, в которой вы работаете, публикует внутренние пакеты в приватном репозитории с префиксом @my-company/ (например, @my-company/awesome-library). В таком случае содержимое .npmrc будет выглядеть примерно так:

Авторизация в NPM

Чтобы публиковать пакеты или устанавливать их из приватного репозитория, необходимо авторизоваться в NPM. Это можно сделать с помощью команды npm login. Но я предпочитаю вручную указывать пакеты в .npmrc, так как это более явный способ — и это не сильно сложнее.

Авторизация с токеном <MY_TOKEN> для npmjs выглядит в .npmrc следующим образом:

//registry.npmjs.org/:_authToken=<MY_TOKEN>

Обратите внимание, что // в начале строки не обозначает комментарий. Это обычная часть URL, которая следует после протокола. Но в данном случае протокол не имеет значения, так как авторизация для http и https будет одинаковой.

Авторизационные данные для репозиториев лучше хранить в .npmrc, находящемся в домашней директории. Так они будут использоваться для всех проектов на вашей машине, и вы точно случайно не закоммитите их в GIT.

Публикация пакетов

Чтобы сделать свой NPM-пакет доступным для загрузки другими разработчиками, его надо опубликовать в реестре пакетов (registry). Глобальным реестром NPM-пакетов является https://registry.npmjs.com.

Существуют и другие зеркала: например, https://registry.yarnpkg.com. Но зачастую они просто проксируют npmjs, который на текущий момент является главным источником истины для JavaScript-пакетов.

Для публикации пакета существует команда npm publish. Она упаковывает всё содержимое в .tgz-архив — это можно сделать отдельно командой npm pack — и отправляет его в реестр пакетов. По умолчанию в архив попадает всё содержимое проекта. Поэтому размер пакета может оказаться неоправданно большим.

Если в package.json определено поле files, NPM упакует в архив только указанные в нём файлы и директории. Также можно указать исключения в файле .npmignore. Это работает аналогично тому, как работает .gitignore.

Предположим, вы собираете свою библиотеку с помощью компилятора Typescript в директорию lib. В этом случае в поле files следует указать ["/lib"]. Далее можно, например, исключить из публикации файлы тестов, добавив в .npmignore строчку *.test.*.

Некоторые критичные для пакета файлы — например, package.json и README.md — будут опубликованы в любом случае. А некоторые файлы и директории — например, .git или node_modules — никогда не попадут в публикуемый архив. Но с последним есть нюанс.

Публикация зависимостей вместе с пакетом

Если какие-то из зависимостей публикуемого пакета указаны в виде пути в файловой системе (например, file:../my-awesome-library, что не является хорошей практикой, но тем не менее случается), их можно опубликовать вместе с пакетом, указав их в поле bundledDependencies файла package.json. В таком случае директория node_modules всё же попадёт в публикуемый архив, но в ней останутся только пакеты, указанные в этом поле.

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

Основной сценарий использования bundledDependencies в настоящий момент — дать пользователям возможность загружать утилиты одним файлом. И снизить тем самым время загрузки, так как пакетный менеджер вместо нескольких последовательных запросов на сервер делает всего один. Так делает, например, сам NPM.

Необязательные зависимости

В package.json существует поле optionalDependencies. Оно работает аналогично dependencies, но подразумевает, что пакет в целом может работать и без них. Его можно использовать, например, для каких-либо пакетов, которые нужны не всегда.

Так, установка Cypress предполагает загрузку около 500 мегабайт, что может негативно сказаться на времени выполнения CI. Если cypress не используется в некоторых окружениях, можно перенести его в секцию optionalDependencies и выполнять установку с флагом --omit=optional (--no-optional в более ранних версиях NPM).

Ключевое отличие optionalDependencies от dependencies в том, что если установить указанные в этом поле пакеты невозможно, NPM не завершит процесс с ошибкой. А продолжит установку остальных зависимостей в штатном режиме.

Эта особенность используется авторами NPM-пакетов, содержащих бинарные файлы для разных операционных систем. Например, сборщик esbuild написан на языке Go. При установке его зависимостей пакетный менеджер обратит внимание на поля os (операционная система) и cpu (архитектура процессора) в их package.json и установит только те, что соответствуют текущей ОС.

«Плагины» для пакетов

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

Обратите внимание, что понятие «плагин» в данном случае довольно широкое и, например, библиотека React-компонентов будет фактически являться плагином для React.

React в приложении должен быть в единственном экземпляре. И если пакетный менеджер установит для библиотеки компонентов собственный React, то помимо засорения node_modules приложение может перестать работать.

При этом плагин может быть совместим только с определёнными версиями хост-пакета, поскольку использует его API. А значит — может перестать работать, если этот API будет удалён.

Реализацией вышеописанного механизма являются peerDependencies.

При разработке плагина стоит указать его хост-пакет в поле peerDependencies в package.json, чтобы подсказать пакетному менеджеру, как поступать в такой ситуации.

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

NPM 7 и выше автоматически установит недостающие peerDependencies.

В peerDependencies стоит указывать как можно более широкий диапазон версий, чтобы дать пользователю библиотеки возможность выбора. Если, например, библиотека будет ожидать React ^17.0.0, а пользователь использует React 18.0.0, то возникнет конфликт версий зависимостей. Это приведёт к ошибке установки при использовании NPM 7 и выше.

Пользователю эта ошибка может быть непонятна и он весьма вероятно попытается установить зависимости с флагом --force или --legacy-peer-deps, как подсказывает сам текст ошибки. Это заставит NPM работать по старинке (как до NPM 7), но может привести к проблемам с дубликатами.

Переопределение версий

Решить такие проблемы можно по старинке — вручную. Для этого в package.json появилось поле overrides, которое работает подобно полю resolutions из Bower, но поддерживает каскад, как в CSS.

Это не единственная для NPM аналогия с СSS, команда npm query поддерживает СSS-селекторы для анализа дерева зависимостей.

Похожее поле есть и в других пакетных менеджерах, но, поскольку для package.json нет никакой общей спецификации, работает и называется оно по-разному. Например, в Yarn есть поле resolutions.

Опциональный хост

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

Для решения этой задачи в package.json существует поле peerDependenciesMeta — оно позволяет предоставить пакетному менеджеру дополнительный контекст для установки зависимостей.

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

То есть peerDependenciesMeta.optional является аналогом optionalDependencies, но для peerDependencies.

Воспроизводимость

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

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

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

Проблему решил альтернативный пакетный менеджер — Yarn. По завершении установки он генерирует файл yarn.lock, в котором сохраняется результат процесса разрешения зависимостей. А именно — конкретные версии пакетов, которые подобрал пакетный менеджер. Если такой файл есть в проекте, при запуске установки пакетный менеджер проверит, что package.json и yarn.lock соответствуют друг другу и, полностью пропустив этап разрешения зависимостей, загрузит пакеты по списку.

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

Yarn подтолкнул NPM к развитию, и впоследствии тоже научился генерировать свои npm-shrinkwrap.json и package-lock.json файлы для реализации подобного механизма.

npm ci

Чтобы добиться действительно предсказуемой установки в автоматизированных средах, важно использовать команду npm ci вместо npm install.

Команда npm ci расшифровывается как clean install, поскольку при её выполнении NPM полностью удаляет директорию node_modules и загружает все зависимости с чистого листа, что также улучшает воспроизводимость.

Yarn

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

Давайте рассмотрим подробнее, в чём именно заключаются эти преимущества.

Простота использования

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

Часто используемые команды стали короче, а команды для CI — читабельнее:

• npm install —> yarn install/yarn;
• npm install --save react —> yarn add react;
• npm ci —> yarn install --frozen lockfile;

Безопасность

Помимо фиксированных версий зависимостей, в yarn.lock сохраняется также их контрольная сумма (Subresource Integrity) в поле integrity каждого пакета. Она позволяет при установке из локфайла убедиться, что его никто не подменил и инсталлируется то же, что и при генерации локфайла.

Позже эту информацию стал сохранять и NPM.

Скорость

Основная причина быстроты Yarn — кэш. Он позволяет создать на своей машине собственный реестр пакетов и в процессе установки заменять сетевой запрос на копирование папок в файловой системе. Меньше сетевых запросов — меньше времени занимает установка.

При этом кэш можно переиспользовать между всеми проектами, которые вы разрабатываете на своей машине.

Собственный реестр пакетов

Чтобы получить контроль над пакетами, которые используются в проектах, большие компании организуют собственные репозитории пакетов, которые могут проксировать глобальный реестр NPM. Обычно для этого используется Nexus.
Также собственный репозиторий может использоваться в качестве удалённого кэша, чтобы ускорять установку зависимостей — такой кэш будет находиться ближе к разработчикам.

Для этого можно воспользоваться более легковесным и опенсорсным аналогом Nexus — Verdaccio. Его, например, можно запустить в Docker на своей машине, что позволит организовать кэш, переиспользуемый между всеми проектами и доступный для любого пакетного менеджера. Либо установить на сервер, который находится недалеко от вас, чтобы не расходовать ресурсы своей машины.

Для этого необходимо будет указать в .npmrc адрес сервера с Verdaccio.

С Verdaccio можно и локально попрактиковаться в публикации пакетов, если у вас не было опыта.

Связывание пакетов локально

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

• Импортировать код из библиотеки или вложить библиотеки друг в друга. Пожалуй, это худшее, что можно придумать, поскольку связанность кода будет неконтролируема, и все преимущества разбиения на пакеты сойдут на нет. И проект превратится в один большой монолит.
• Указать в package.json одного пакета путь в файловой системе до другого (например, file:../my-library) вместо версии зависимости. В целом рабочий вариант, но нарушается инверсия зависимостей. Пакет перестаёт зависеть от абстракции и начинает зависеть от конкретного кода. Если его понадобится опубликовать, придётся включать в архив все его подобные зависимости с помощью поля bundledDependencies.
• Использовать npm link. Можно указать в package.json пакета последнюю опубликованную в NPM версию зависимости и заменить её симлинком на локальную версию командой npm link. Делать это придётся после каждой установки зависимостей, что довольно неудобно.
• Использовать Lerna. Lerna фактически была создана для автоматизации выполнения npm-link с целью организации монорепозитория.
• Использовать Workspaces. С появлением во всех актуальных пакетных менеджерах механизма Workspaces использование Lerna стало бесполезным, поскольку практически всё то же самое можно получить из коробки, создав в корне монорепозитория package.json с полем workspaces:

Фантомные зависимости

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

Например, мы используем библиотеку library-a версии 1.0.0, которая, в свою очередь, зависит от библиотеки library-b. Поскольку library-b всплывает на верхний уровень node_modules, мы сможем импортировать её в проект.

Может случиться так, что в следующей патч-версии library-a больше не будет зависеть от library-b. Это вполне валидная ситуация, поскольку внешний API библиотеки не изменился.

В таком случае library-b не установится, и мы больше не сможем использовать её в своём проекте. Но весьма вероятно мы узнаем это только перед продакшн сборкой в CI, поскольку производим чистую установку с npm ci там.

Использование транзитивной зависимости без явного указания её в package.json называется фантомной зависимостью.

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

Структура зависимостей

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

Самое важное отличие графа от дерева заключается в возможности возникновения ромбовидных зависимостей.

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

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

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

На основе этой идеи был разработан новый пакетный менеджер — PNPM.

PNPM

PNPM, в отличие от NPM и Yarn, не пытается сделать структуру node_modules как можно более плоской. Вместо этого он скорее нормализует граф зависимостей.

После установки PNPM создаёт в node_modules директорию .pnpm, которая концептуально представляет собой хранилище ключ-значений, в котором ключом является название пакета и его версия, а значением — содержимое этой версии пакета. Такая структура данных исключает возможность возникновения дубликатов.

Структура самой директории node_modules будет подобна nested-модели из NPM, но вместо физических файлов ней будут находиться симлинки, которые ведут в то самое хранилище пакетов.

В node_modules каждого пакета будут находиться только симлинки на те пакеты, которые указаны у него в package.json. Это полностью избавляет нас от проблемы фантомных зависимостей, и потребность в наличии ESLint-плагина отпадает.

В версии NPM 9 появился флаг install strategy. Значение linked в нём включает подобную PNPM модель установки с симликами, но на текущий момент, это экспериментальная фича.

Глобальное хранилище пакетов

PNPM может создать директорию .pnpm не только в node_modules проекта, но и глобально. В таком случае node_modules у проектов будут содержать только симлинки, за счёт чего ускоряется установка зависимостей (создание симлинка занимает меньше времени, чем копирование файлов). Это экономт колоссальное количество дискового пространства.

Переопределение зависимостей

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

В .pnpmfile.cjs можно написать JavaScript-код, который будет изменять package.json всех пакетов в дереве зависимостей на этапе разрешения. Это позволяет максимально точно исправлять ошибки, возникающие с транзитивными зависимостями.

Простота использования

PNPM имеет API, очень похожий на Yarn, так что можно не привыкать к новым командам в третий раз.

По всем вышеописанным причинам, я предпочитаю использовать PNPM во всех своих проектах.

Разработчики Yarn решили пойти по более революционному пути для решения​​ проблемы фантомных зависимостей, добавив режим Plug’n’Play. В этом режиме Yarn заменяет собой механизм разрешения модулей из Node.js и вместо директории node_modules создаёт файл .pnp.js, в котором сохраняет всю необходимую ему информацию для разрешения зависимостей. Не все пакеты в NPM совместимы с этим режимом, поэтому его внедрение может вызвать некоторые трудности. Но весьма вероятно, что для менеджмента зависимостей в JavaScript это большой шаг в будущее.

Будущее менеджмента зависимостей в JavaScript

По моим наблюдениям, управляющие зависимостями в JavaScript инструменты постепенно идут к полному избавлению от директории node_modules в проекте. И, возможно, к разрешению зависимостей прямо в рантайме благодаря ES-модулям, которые уже поддерживаются всеми современными браузерами, а также в Deno — альтернативе Node.js, в которой в принципе нет пакетного менеджера как такового.

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

Больше про JavaScript и всё, что с ним связано, можете почитать в канале. И пишите в комментариях, что бы ещё хотели узнать по этой теме!

Может показаться, что кодить здесь не нужно, но навыки разработки ПО особенно важны, когда Linux-инженер помогает с автоматизацией процесса разработки. Linux-инженер из компании КРОК Антон Селиверстов рассказывает, что именно нужно уметь делать.

Понимать процесс разработки ПО
Компилировать и читать код разработчика
Понимать основы тестирования
Автоматизировать установку сервисов
Настраивать мониторинг сервисов
Автоматизировать сбор логов
Владеть инструментами контейнеризации
Доставлять код в окружение

Понимать процесс разработки ПО

Чтобы понимать, когда и где нужна автоматизация, важно разобраться в базовых подходах к правильной разработке ПО. Для этого можно изучить манифест «Twelve-Factor App». Это методология, описывающая 12 факторов, которые важно учитывать при создании SaaS-сервисов: декларативность, масштабируемость, непрерывное развёртывание и т. д.

Компилировать и читать код разработчика

В компании может быть много команд разработки. Кто-то пишет на Python, кто-то разрабатывает на Java. Учить все языки, чтобы работать с любой командой, не самый оптимальный вариант. Да и выбор языка программирования зависит даже не от компании, а от проекта. Но инженеру нужно уметь компилировать код. Это пригодится и вне работы в команде, так как многие инфраструктурные сервисы, вроде Nginx или HAProxy можно скомпилировать из исходного кода и установить.

Вдаваться во все тонкости языка на уровне разработчика Linux-инженеру не нужно, поэтому можно выбрать курсы, которые заточены под конкретные инженерные задачи. Для этого, например, подойдут программы «Golang для инженеров» или «Python для инженеров» от «Слёрм».

Понимать основы тестирования

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

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

Автоматизировать установку сервисов

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

Познакомьтесь с этим инструментом, прочитав статью: Что такое Ansible и как его использовать

Настраивать мониторинг сервисов

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

Системы мониторинга собирают показатели с виртуальных машин и сервисов и на их основе строят информативные графики. По ним можно сделать вывод, насколько оптимально и корректно работает система, хватает ли ресурсов и т. д. Настраивать необходимые для анализа показатели можно с помощью Prometheus и Grafana.

Автоматизировать сбор логов

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

Владеть инструментами контейнеризации

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

Доставлять код в окружение

Также Linux-инженер занимается развёртыванием и управлением приложениями. Когда разработчик пушит свой код в Git-репозиторий, Linux-инженер помогает доставить код в нужное окружение: сначала в среду разработки, потом в тестовое окружение, потом уже на продакшн. Он создаёт пайплайн, который первым этапом тестирует код. Если тесты успешны, то пайплайн собирает Docker-образ и пушит в удалённый репозиторий, например, Nexus или GitLab Container Registry. После этого образ скачивается или запускается на нужном окружении: это может быть виртуальная машина или Kubernetes-кластер.

Навыки разработки ПО для Linux-инженера скорее вспомогательные, чем основные. Однако их знание даёт конкурентное преимущество на рынке — используя этот опыт, он может продолжить рост в качестве DevOps-инженера в команде разработки или стать SRE-инженером.

А чтобы вы могли ещё глубже прокачать навыки Linux-инженера, мы собрали для вас подборку книг: от азов до управления системами.

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

1. Специализации и задачи IT-архитектора
2. С какими областями знаний работает IT-архитектор
3. Что должен знать архитектор ПО
4. Софт-скилы ИТ-архитектора
5. Опыт — это проработка гипотез

Специализации и задачи IT-архитектора

В IT-архитектуре много направлений: enterprise, solution, system, data-архитектура. У каждой специализации свои особенности, которые в том числе зависят и от стека конкретной компании. Поэтому не так просто собрать универсальный пул навыков и технологий, подходящий любому IT-архитектору.

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

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

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

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

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

Что почитать: блог Мартина Фаулера про архитектуру ПО

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

С какими областями знаний работает IT-архитектор

Чтобы грамотно выстраивать проект, ИТ-архитектор в банке должен понимать, как устроены эти области знаний:

1. Реализация бэкенда. Где хранить данные, как к ним обеспечить доступ.
2. Реализация фронтенда. Работа с клиентом, интернетом, каналами.
3. Интеграционная архитектура. Возможности интеграции, как обеспечивать взаимодействие между системами, не положив ни одну из них.
4. Безопасная архитектура. Как правильно обеспечить взаимодействие клиентов, быстро проводить идентификацию, авторизацию клиента.
5. Использование MDM. Это системы, которые будут хранить мастер-данные по необходимым для проекта сущностям (данные клиентов, продуктов и т. д.).
6. Реализация справочников. Важно правильно распространять по своим сервисам справочную информацию.
7. Монолитная, сервисная и микросервисная архитектуры. Как они устроены, в чём разница, плюсы и минусы подходов.

Что должен знать архитектор ПО

Архитектурный фреймворк TOGAF

Важно понимать, как строится архитектура предприятий. Мы пользуемся фреймворком TOGAF: проект прорабатывается с точки зрения бизнес-требований, технологического стека, архитектуры данных. Эта методология позволяет реализовать устойчивую и высокопроизводительную систему.

Примечание 1Если при выходе из строя n-компонента система продолжает полноценно функционировать, то её можно считать устойчивой. N — величина динамическая и может изменяться в зависимости от критичности систем.

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

Бизнес-требования

IT-архитектор должен разработать технический сценарий реализации бизнес-задачи.

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

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

Важный момент, IT-архитектор также должен проанализировать и определить потенциальные изменения, чтобы при интеграции новой системы с другими системами не произошло сбоя. Нужно уточнять у бизнеса: «Если изменятся, например, фамилия клиента или поле в паспорте, это критично?». Если да, то всё заносится в бизнес-требования.

Техническая проработка

После того как все бизнес-требования утверждены, IT-архитектор начинает проектировать схемы, чтобы «посадить» задачу на стек проекта.

ИТ-архитектор указывает, какие технологии, фреймворки используются в задаче, на чём написано приложение. Мы в Газпромбанке пишем на Java. Но бывают коробочные решения, которые требуют дополнительного внимания. Например, сервис на REST придётся серьёзно переписывать, чтобы вызывать SOAP.

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

Архитектор учитывает требования безопасности. По сути, это контроль вызовов: кто вызывает сервис, а кто является вызываемым. Если компрометирующий сервис «А» знает, как вызвать сервис «Б» из защищённой системы, то вся система перестаёт быть защищённой. Тогда нужно прописать, что сервис «Б» должен вызывать сервис «А» из доверенной зоны и возвращать данные по своим каналам.

Также важно понимать, какие данные передаются в этом потоке: только общедоступная информация или ещё и персональная. Если уровень критичности этих данных высок, то нужно принять дополнительные меры по их сохранности, например, выстраивание DMZ (более защищённых зон) для работы с ними.

Архитектура данных

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

Базы данных

В начале 2000–х были две–три основных базы данных: Oracle, MySQL. Сейчас появляется множество новых реализаций: колоночные, документоориентированные, key-value БД. Их назначение примерно одинаковое — они хранят данные, но подходы к записи, чтению, масштабированию у них абсолютно разные.

Нужно понимать, какие существуют базы данных и какая между ними разница, что они позволяют делать, почему при использовании реляционных БД не всегда можно достичь большего профита. Например, если нет потребности в ACID (Atomicity, Consistency, Isolation, Durability), то можно рассмотреть NOSQL БД. Это даст возможность записывать большие объёмы данных в БД, к тому же масштабировать хранилище будет проще, чем при использовании реляционной БД.

Что почитать по теме:Как разобраться в видах СУБД
NoSQL базы данных
Популярные реляционные базы данных

Интеграция

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

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

Кого почитать: Максим Смирнов о сценариях интеграции приложений

Паттерны проектирования

Event-driven архитектура

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

Материалы по теме:
Что такое EDA и как для её построения использовать KafkaЧто такое Kafka и как начать с ним работу

Domain-driven design (DDD)

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

Подходы domain-driven design очень актуальны в больших компаниях. Если заранее не «нарезать» предметную область и не определить основные сущности этих доменов, то со временем данные могут задублироваться в разных частях системы, и синхронная актуализация этих данных вызовет трудности.

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

GitHub про DDD: книги, видео, комьюнити, обучающие курсы.

Onion-архитектура

При проектировании системы за основу берётся независимый Core-уровень, на который накладывается второй, уже зависимый от первого. На второй уровень накладывается третий, который зависит от второго и так далее. При таком подходе верхний UI-слой не сможет управлять Core-уровнем или ходить напрямую в бэкенд, обходя сервисный слой.

Подход CQRS

CQRS (Command and Query Responsibility Segregation) — это парадигма, при которой операции записи отделены от операций чтения. Она необходима, когда нагрузка на чтение и запись данных распределена несимметрично. Например, когда большая часть бизнес-логики и сложных проверок приходятся на write-систему, а чтение данных происходит чаще, чем вставка изменений.

Также почитайте о плюсах и минусах паттерна CQRS.

Инструменты визуализации решений

• Бизнес-вижн прописывается с помощью BPMN-подходов моделирования.
• Для построения архитектурных схем можно использовать UML или Archimate нотации. Мы используем Visio, либо аналог Visio (draw.io).

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

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

Софт-скилы ИТ-архитектора

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

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

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

Опыт — это проработка гипотез

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

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

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

1. Гарантии безопасности
2. Спецификации исключений в C++
3. Стоит ли избегать исключений
4. Как работают исключения
5. Заключение
6. Полезные ссылки

В первой части мы разобрали, как создавать исключения и работать с ними, а также какими они бывают. Разобрали ключевые слова try, catch и throw, синтаксис выбрасывания и обработки исключений, а ещё особые случаи, связанные с исключениями.

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

• гарантии безопасности;
• спецификации исключений;
• как исключения влияют на скорость выполнения;
• как устроены исключения в C++ и как они работают.

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

Углубить и систематизировать знания C++ поможет курс «Разработчик C++» в Яндекс Практикуме. Для тех, кто знает C++, но желает изучить работу по сети, Docker, Linux и множество вспомогательных инструментов, есть курс «C++ для бэкенда».

Гарантии безопасности

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

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

Выделяют четыре уровня безопасности исключений:

1. Гарантия отсутствия исключения. Самая сильная гарантия. Означает, что исключение возникнуть не может, а значит, ничего не сломает.
2. Строгая гарантия безопасности. Исключение может возникнуть, но в этом случае всё будет возвращено к тому, как было до вызова соответствующей функции. Иными словами, операция не удалась, но можно сделать вид, как будто её и не было.
3. Базовая гарантия безопасности. При возникновении ошибки мы не можем вернуть всё как было, но всё равно останемся в корректном состоянии. Все инварианты будут сохранены, все ненужные ресурсы освобождены, ничего не утечёт. С объектом, из-за которого возникло исключение, можно продолжать работать.
4. Отсутствие безопасности. Не можем гарантировать ничего. Если исключение произошло, лучше поскорее завершить работу программы.

Рассмотрим пример. Напишем собственную операцию push_back для вставки в вектор.

Гарантия отсутствия безопасности

Вызов new не опасен в отличие от перемещения элементов: мы ничего не знаем про конструктор перемещения неизвестного объекта T. Он может выбрасывать исключение.

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

В примере мы использовали new для простоты и наглядности. Реальный вектор должен выделять сырую память без инициализации.

Базовая гарантия безопасности

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

Уже лучше: размер вектора будет корректен, и мы не допустим утечки. Однако такая вставка может привести, например, к обнулению вектора, если исключение возникло в самом первом перемещении.

Строгая гарантия безопасности

Над строгой гарантией нужно потрудиться.

У строгой гарантии есть неприятный эффект: нам пришлось отказаться от перемещений в пользу копирований. Таким образом, она отрицательно влияет на эффективность.

Можно сделать всё эффективно, если есть уверенность, что перемещение объектов типа T не выбрасывает исключений. Стандартный std::vector так и делает.

Гарантия отсутствия исключения

И наконец, достигнем вершины — напишем метод без исключений:

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

Спецификации исключений в C++

Такой разный noexcept

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

Если же мы хотим явно сказать, что функция выбрасывает исключение, можно написать noexcept(false):

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

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

Вывод программы будет таким:

Заметьте, что мы пишем noexcept(g()), а не noexcept(g). Последнее выражение всегда false, поскольку само по себе выражение g ничего не делает, а значит, ничего не выбрасывает.

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

А нужен ли noexcept?

Вряд ли что-то может ответить на поставленный вопрос красноречивее бенчмарка. В этом бенчмарке, который мы провели в сервисе QuickBench, созданы три практически одинаковых класса:

F_except, у которого есть обычный конструктор перемещения;

• F_noexcept, у которого конструктор перемещения помечен как noexcept;
• F_noexcept2 — как F_noexcept, но с деструктором, помеченным как noexcept(false). Деструктор нужно явно помечать как noexcept(false), иначе он считается невыбрасывающим.

Объекты этих классов добавляются в std::vector. Его метод push_back обеспечивает строгую гарантию исключений. Как вы уже знаете, в этом случае перемещение вектора возможно только тогда, когда перемещение его элементов не выбрасывает исключений.

Отличие заметное, хотя не такое существенное из-за оптимизаций в std::vector. noexcept позволил выбрать более эффективный алгоритм, но только в том случае, когда он применялся и для конструктора перемещения, и для деструктора.

Волшебный default

Рассмотрим три класса:

Казалось бы, разницы между ними нет, но попробуем изучить конструкцию T*() на предмет выбрасывания исключений:

В этом примере мы также добавили четвёртый класс. Вывод программы такой:

Нас подвёл только один вариант, в котором конструктор объявлен как T2() {}. Такой конструктор будет считаться выбрасывающим, хотя на вид он аналогичен записи T2() = default.

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

Список исключений

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

У такого подхода есть преимущества:

• компилятор может убедиться, что все исключения обрабатываются;
• вы видите, что может, а что не может выбрасывать функция по её сигнатуре;
• обработчик можно искать в compile-time.

Однако на деле не всё так радужно. Всплыл ряд недостатков:

• Некоторые исключения, например, std::bad_alloc может выбрасывать почти любая функция. Везде писать throw(std::bad_alloc) утомительно.
• Непонятно, как быть с указателями на функции и std::function. Если мы хотим заранее всё знать об исключениях, то спецификации исключений должны быть в типе функции. Тогда неясно, как их преобразовывать.
• Можно сделать спецификации нестрогими, но тогда непонятно, что они дают.

С похожими недостатками сталкиваются и в других языках программирования. В C++ недостатки перевесили, и комитет по стандартизации решил от явных спецификаций отказаться, оставляя только noexcept. В Стандарте C++11 они объявлены устаревшими (deprecated), а позже вовсе исключены из языка.

Стоит ли избегать исключений

«Мы не используем исключения в C++», — cтайлгайд Google.

Не нужны или незаменимы

Исключения в C++ — удобный инструмент, не лишённый недостатков. Может быть, самый существенный из них — в том, что исключения прозрачны. Глядя на сигнатуру функции, нельзя понять, какие исключения она выбрасывает. Это можно понять, глядя в документацию. Но документация не проверяется автоматически, а значит, может ошибаться.

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

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

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

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

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

Без исключений только первая строка блока try записывалась бы так:

При этом мы опустили вывод диагностики о местоположении ошибки и её сути. Конечно, можно было придумать сложный прокси-объект, который ведёт себя как JSON, но на самом деле находится в ошибочном состоянии и не выполняет никаких действий, и тем самым сократить количество строк.

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

Строгий запрет

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

Для GCC и clang это опция -fno-exceptions. Её использование не значит, что исключений не возникнет. В частности, никто не может избавить вас от std::bad_alloc и других исключений, выбрасываемых из библиотек. Однако чаще всего исключение будет приводить к вызову std::terminate.

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

Назад в будущее

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

Чтобы компилятор проверял, что вызывающая функция точно обрабатывает ошибку, добавим [[nodiscard]]:

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

Когда функция должна сама по себе вернуть значение, такой способ не подходит. Решение есть — специальный тип std::expected, но он будет добавлен в язык только в 2023 году. Предполагается, что этот объект будет хранить либо возвращённое значение, либо код ошибки, когда операция не удалась.

Универсальный солдат

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

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

• std::filesystem. Функции работы с файловой системой часто могут завершаться с ошибкой. Например, вы хотите переименовать файл, но его только что удалили. В этом и подобных случаях выбрасывается std::filesystem::filesystem_error, подкласс std::system_error, который в свою очередь расширяет подкласс std::runtime_error и std::exception.
  Но если вы указали дополнительный параметр типа std::error_code&, то исключение не будет выброшено — вместо этого ошибка запишется в переданный объект:std::error_code ec;std::filesystem::rename(old_path, new_path, ec);if (!ec) { std::cerr << “Ошибка переименования” << std::endl;}
• Потоки ввода-вывода. Для них используется немного другой механизм. По умолчанию потоки не выбрасывают, и вы вынуждены проверять все операции на корректность.
  Если вызвать метод потока exceptions, то можно попросить поток сигнализировать при появлении флагов ошибок. Будет выбрасываться исключение std::ios_base::failure (также подвид std::system_error). У метода есть эффект, даже если он вызван уже после возникновения ошибки:#include #include int main(){ std::ifstream f(“abracadabra”); try { f.exceptions(f.failbit); } catch (const std::ios_base::failure& e) { std::cout << “Ошибка потока: ” << e.what() << ‘\n’ << “Код: ” << e.code() << ‘\n’; }}Передавать в метод exceptions флаг eofbit не рекомендуется. Достижение конца файла — штатная, а не исключительная ситуация. Последующие чтения всё равно установят флаг fail.

А что со скоростью?

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

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

• void f()  — не помечена как noexcept. Рекурсивно вызывает себя. После 10 миллионов вызовов выбрасывает исключение.
• bool g()  — помечена как noexcept. Рекурсивно вызывает себя. После 10 миллионов вызовов возвращает false, и цепочка вызовов прерывается.

Результат во многом зависит от компилятора, оптимизаций и наличия у функций атрибута noinline. Но в большинстве случаев версия с исключениями по крайней мере не хуже. Вот бенчмарк, где версия с исключениями работает в полтора раза быстрее. При использовании clang преимущество скромнее — всего 10%.

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

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

А вот начало функции с проверками. Не будем приводить код полностью:

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

Профессионалы советуют: везде, где можно, ставьте noexcept. Иначе производительность может сильно пострадать. Это причина, почему многие крупные компании вообще не используют исключения.

Как работают исключения

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

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

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

Посадочные площадки

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

Они могут прерваться в девяти местах:

• два раза — при конвертации const char* в std::string; возможное исключение bad_alloc;
• три раза — при сложении строк; возможное исключение bad_alloc;
• один раз — в std::to_string; возможное исключение bad_alloc;
• один раз — в std::vector::at; возможное исключение std::out_of_range;
• два раза — в std::ostream::operator <<; возможное исключение std::ios_base::failure. Даже если мы не устанавливали для потока флаг выброса исключений, компилятор всё равно должен быть готов к такому повороту событий — операция << не помечена как noexcept.

Для этих девяти мест компилятор должен предусмотреть пути отхода. А именно установить, какие временные объекты он должен удалить в каждом случае и что делать дальше. Для этого в бинарном коде программы создаётся посадочная площадка (landing pad). Процессор приземляется на ней только в случае исключения.

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

Таким образом для возможности обработки исключений каждый вызов требует максимум одну дополнительную инструкцию — запоминание адреса экстренной посадочной площадки. Сущая мелочь.

Выбор обработчика

Мы так увлеклись оверхедом, что совсем забыли: исключения нужны, чтобы их ловить. А ловят их обработчики. Чтобы исключение нашло свой обработчик, при выполнении raise нужно сохранить информацию о типе. Причём эта информация будет обрабатываться во время выполнения программы (run-time).

В C++ для этого есть свой механизм — динамическая идентификация типа данных, или RTTI. Чтобы мы могли поймать исключение по базовому типу, в run-time должна быть доступна информация обо всех предках выброшенного исключения.

Таким образом, raise делает следующее:

• сохраняет объект исключения;
• сохраняет информацию о типе;
• возможно, сохраняет что-то ещё (например, ссылку на деструктор объекта исключения);
• если надо, запускает terminate;
• если не надо, запускает раскрутку стека.

Раскрутка стека делает следующее:

• приземляется на посадочную площадку;
• удаляет временные и автоматические объекты;
• проверяет все доступные обработчики на соответствие типа;
• если надо, запускает terminate;
• если не надо (и обработчик не найден), продолжает раскрутку стека.

Обработчик делает следующее:

• выполняет пользовательский код;
• если исключение не переброшено, то деаллоцирует его.

И снова бенчмарк

Чтобы проверить, что информация о типе действительно обрабатывается в run-time, проведём ещё один любопытный бенчмарк. Создадим тип F очень простого вида:

А также шаблон template<int> struct G. Его особенность — в том, что у типа G<0> очень много потомков, 2048 штук. В функции f всё просто: будем бросать исключение типа F и затем ловить исключение типа F. В функции g будем бросать исключение типа G<0>, а ловить по типу одного из его многочисленных потомков — G<1111>.

Если наше предположение верно, то программе потребуется гораздо меньше времени для поиска обработчика исключения типа F. Напротив, чтобы убедиться, что обработчик типа G<1111> соответствует выброшенному исключению типа G<0>, придётся потрудиться.

Запустим бенчмарк и убедимся в своей правоте:

Поимка объекта по глубокому производному классу заняла в 32 раза больше времени. Таким образом мы убедились, что проверка исключения на соответствие типу действительно происходит в run-time.

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

Заключение

Мы проделали большую работу. Разобрались в тонкостях исключений в C++, гарантиях, спецификациях. Узнали, что, вопреки распространённому мнению, исключения — не всегда медленно.

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

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

Полезные ссылки

• Курс «Разработчик C++» в Яндекс Практикуме
• Дополнительный курс «C++ для бэкенда» в Яндекс Практикуме
• Блок try в энциклопедии cppreference
• Конструкция throw в энциклопедии cppreference
• Спецификации исключений в энциклопедии cppreference
• Стандартные типы исключений в энциклопедии cppreference
• Доклад «Исключения C++ через призму компиляторных оптимизаций» на конференции C++ Russia 2019 Piter
• Сервис микробенчмарков Quick C++ Benchmark
• Раздел «Исключения» стайлгайда Google

Что такое декораторы в Python

Декоратор — конструкция языка Python для расширения возможностей функций и классов без изменения их кода.

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

Один и тот же чехол подходит для всех смартфонов нужной модели. Универсальность — важное свойство декораторов.

Анатомия декоратора в Python

Создадим декоратор @hello_decorator:

Декоратор в Python — функция, которая принимает функцию/класс и возвращает функцию/класс. В примере выше декоратор hello_decorator() принимает функцию f(), и возвращает функцию wrapper().

Пояснения:

1. При объявлении функции wrapper() используем встроенный в Python декоратор @wraps. Этот декоратор копирует свойства __name__, __doc__ и другие из функции f() в функцию wrapper(), чтобы при отладке программы все выглядело так, будто wrapper() и есть функция f();
2. Аргументы функции wrapper(): *args и **kwargs. Аргумент *args собирает позиционные аргументы, а **kwargs — именованные. Например, в вызове: wrapper(1, ‘a’, x=5, y=None) значение args — кортеж (1, ‘a’), а kwargs — словарь {‘x’: 5, ‘y’: None}. Если позиционных аргументов при вызове функции нет, args — пустой, и если нет именованных аргументов, пустой — kwargs;
3. В первой строке тела функции wrapper() в консоль выводится «Hello from decorator!» — единственный «побочный эффект» декоратора. Далее вызывается декорируемая функция f();
4. Функция f() внутри wrapper() принимает параметры *args и **kwargs. Операторы * и ** перед именами параметров в вызове функции имеют противоположный эффект случаю, когда их используют при объявлении аргументов. Например, если args=(1, ‘a’) и kwargs={‘x’: 5, ‘y’: None}, вызов f(*args, **kwargs) равносилен: f(1, ‘a’, x=5, y=None). Комбинация «звездочных» аргументов и «звездочных» операторов позволяет универсально передать аргументы из функции wrapper() в f();
5. В последней строке функции hello_decorator() возвращаем функцию-обертку wrapper(). Так мы указываем, что нужно подставить на место декорируемой функции f(). Вызывать функцию wrapper() не нужно — возвращаем саму функцию.

Применим декоратор @hello_decorator к функции sum2():

Функция sum2() принимает два аргумента и возвращает их сумму. Декорированный sum2() дополнительно выводит на консоль «Hello from decorator!».

Синтаксис @hello_decorator введен в Python для удобства, и равносилен такой записи:

Настраиваемый логгер-декоратор

Наметим логирующий декоратор @Logger для функций с учетом следующих пожеланий:

1. Логи отправляются на консоль;
2. Вложенность: если логируемая функция вызывает другую логируемую функцию, делаем при выводе на консоль отступ для последней;
3. Уровни логов DEBUG, INFO, CRIT: при декорировании можно указать уровень лога функции, который работает в комбинации с настройкой детальности отображения логов. Если уровень лога функции выше или равен текущей детальности, отображаем лог, иначе — игнорируем;
4. Для логирования вызова декорированной функции используем шаблон: LOG_LEVEL [TIMESTAMP] FUNC_NAME(ARGS, KWARGS);
5. Логирование исключений: если функция выбрасывает исключение, логируем его с уровнем CRIT;
6. Внутренние логи: логгер должен работать и в режиме декоратора, и как функция для вывода в лог произвольных сообщений.

Начнем с примера использования. Так мы не перегружаем внимание внутренней сложностью и повышаем шансы создать удачный интерфейс модуля. На этом принципе основана разработка через тестирование — test-driven development (TTD).

Что хотим получить:

После вызова main() хотим увидеть в консоли:

Наблюдения по поводу декоратора @Logger:

1. Logger — не функция, а класс. Экземпляры этого класса можно вызвать. Результат вызова — декоратор;
2. У класса Logger есть вложенный класс-перечисление LogLevel с полями DEBUG, INFO, CRIT;
3. Детальность логирования verbosity определяется в конструкторе класса Logger, уровень логирования функции log_level задается при ее декорировании;

У класса Logger есть метод log_msg(), который можно использовать напрямую внутри функций.

Напишем скелет класса Logger:

Конструктор класса Logger:

Метод Logger.log_msg():

Вспомогательный метод Logger.log_func():

Ключевой метод-декоратор Logger.__call__():

Выводы

1. Проектировать проще сверху-вниз: сначала решите, как хотите пользоваться модулем, а потом реализуйте его;
2. Если декоратор требует централизованного контроля, используйте класс;
3. Если декоратору нужны дополнительные параметры, используйте замыкание — оберните функцию-декоратор во внешнюю функцию (см. Logger.__call__());
4. Экземпляры классов можно использовать как функции за счет __call__();
5. Менеджеры контекста удобны, когда нужно «подчищать» состояние.

Создание и удаление объектов

Любое описание объекта в объектно-ориентированном программировании начинается с создания объекта и его удаления. Давайте подробнее остановимся на каждом из них:

__new__(cls[, ...]) — метод создания типа класса. Он принимает первым аргументом тип класса, в котором он вызывается, и, как правило, возвращает этот же тип. В основном используется, чтобы настраивать создание экземпляра класса тех объектов, которые наследуются от неизменяемых типов (например, int, str, или tuple).

__init__(self[, ...]) — конструктор класса. Используется при определении объектов.

__init_subclass__(cls) — позволяет переопределить создание подклассов объекта. Например, добавлять дополнительные атрибуты:

__del__(self) — деструктор класса. Вызывается автоматически сборщиком мусора, практически никогда не используется, за исключением, когда пользователя необходимо предупредить о незакрытых дескрипторах.

Общие свойства объектов

Любой объект может содержать дополнительную информацию, полезную при отладке или приведении типов. Например:

__repr__(self) — информационная строка об объекте. Выводится при вызове функции repr(...) или в момент отладки. Для последнего этот метод и предназначен. Например:

__str__(self) — вызывается при вызове функции str(...), возвращает строковый объект. Например:

__bytes__(self) — аналогично __str__(self), только возвращается набор байт.

__format__(self, format_spec) — вызывается при вызове функции format(...) и используется для форматировании строки с использованием строковых литералов.

Методы сравнения объектов между собой

__lt__(self, other) — определяет поведение оператора сравнения «меньше», <.

__le__(self, other) — определяет поведение оператора сравнения «меньше или равно», <=.

__eq__(self, other) — определяет поведение оператора «равенства», ==.

__ne__(self, other) — определяет поведение оператора «неравенства», !=.

__gt__(self, other) — определяет поведение оператора сравнения «больше», >.

__ge__(self, other) — определяет поведение оператора сравнения «больше или равно», >=.

__hash__(self) — вызывается функцией hash(...) и используется для определения контрольной суммы объекта, чтобы доказать его уникальность. Например, чтобы добавить объект в set, frozenset, или использовать в качестве ключа в словаре dict.

__bool__(self) — вызывается функцией bool(...) и возвращает True или False в соответствии с реализацией. Если данный метод не реализован в объекте, и объект является какой-либо последовательностью (списком, кортежем и т.д.), вместо него вызывается метод __len__. Используется, в основном, в условиях if, например:

Доступ к атрибутам объекта

Доступ ко всем свойствам объекта также контролируются отдельными методами:

__getattr__(self, name) — вызывается методом getattr(...) или при обращении к атрибуту объекта через x.y, где x — объект, а y — атрибут.

__setattr__(self, name, value) — вызывается методом setattr(...)или при обращении к атрибуту объекта с последующим определением значения переданного атрибута. Например: x.y = 1, где x — объект, y — атрибут, а 1 — значение атрибута.

__delattr__(self, name) — вызывается методом delattr(...)или при ручном удалении атрибута у объекта с помощью del x.y, где  x — объект, а y — атрибут.

__dir__(self) — вызывается методом dir(...) и выводит список доступных атрибутов объекта.

Создание последовательностей

Любой объект может реализовать методы встроенных последовательностей (словари, кортежи, списки, строки и так далее). Доступ к значениям последовательности переопределяется следующими методами:

__len__(self) — вызывается методом len(...) и возвращает количество элементов в последовательности.

__getitem__(self, key) — вызывается при обращении к элементу в последовательности по его ключу (индексу). Метод должен выбрасывать исключение TypeError, если используется некорректный тип ключа, KeyError, если данному ключу не соответствует ни один элемент в последовательности. Например:

__setitem__(self, key, value) — вызывается при присваивании какого-либо значения элементу в последовательности. Также может выбрасывать исключения TypeError и KeyError. Например:

__delitem__(self, key) — вызывается при удалении значения в последовательности по его индексу (ключу) с помощью синтаксиса ключевого слова del.

__missing__(self, key) — вызывается в случаях, когда значения в последовательности не существует.

__iter__(self) — вызывается методом iter(...) и возвращает итератор последовательности, например, для использования объекта в цикле:

__reversed__(self) — вызывается методом reversed(...) и аналогично методу __iter__ возвращает тот же итератор, только в обратном порядке.

__contains__(self, item) — вызывается при проверке принадлежности элемента к последовательности с помощью in или not in.

Числовые магические методы

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

Унарные операторы

__neg__(self) — определяет поведение для отрицания (-a)

__pos__(self) — определяет поведение для унарного плюса (+a)

__abs__(self) — определяет поведение для встроенной функции abs(...)

__invert__(self) — определяет поведение для инвертирования оператором ~

Обычные арифметические операторы

__add__(self, other) — сложение, оператор +

__sub__(self, other) — вычитание, оператор -

__mul__(self, other) — умножение, оператор *

__matmul__(self, other) — умножение матриц, оператор @

__truediv__(self, other) — деление, оператор /

__floordiv__(self, other) — целочисленное деление, оператор //

__mod__(self, other) — остаток от деления, оператор %

__divmod__(self, other) — деление с остатком, определяет поведение для встроенной функции divmod(...)

__pow__(self, other[, modulo]) — возведение в степень, оператор **

__lshift__(self, other) — двоичный сдвиг влево, оператор <<

__rshift__(self, other) — двоичный сдвиг вправо, оператор >>

__and__(self, other) — двоичное И, оператор &

__xor__(self, other) — исключающее ИЛИ, оператор ^

__or__(self, other) — двоичное ИЛИ, оператор |

Отражённые арифметические операторы

Если в обычной арифметике между объектами a и b, объектом, который мы изменяем, является a, и объектом, с которым мы работаем, являетсяb, то в отражённой арифметике наоборот — b является изменяемым, a — объектом, с которым мы работаем, и который передается в качестве аргумента. Например:

Список методов похож на тот, что используется в обычной арифметике, за исключением того, что добавляется префикс «r» ко всем методам:

__radd__(self, other) — сложение, оператор +

__rsub__(self, other) — вычитание, оператор -

__rmul__(self, other) — умножение, оператор *

__rmatmul__(self, other) — умножение матриц, оператор @

__rtruediv__(self, other) — деление, оператор /

__rfloordiv__(self, other) — целочисленное деление, оператор //

__rmod__(self, other) — остаток от деления, оператор %

__rdivmod__(self, other) — деление с остатком

__rpow__(self, other[, modulo]) — возведение в степень, оператор **

__rlshift__(self, other) — двоичный сдвиг влево, оператор <<

__rrshift__(self, other) — двоичный сдвиг вправо, оператор >>

__rand__(self, other) — двоичное И, оператор &

__rxor__(self, other) — исключающее ИЛИ, оператор ^

__ror__(self, other) — двоичное ИЛИ, оператор |

Составное присваивание

Эти методы — комбинация «обычного» оператора и присваивания. Возвращают тот же тип объекта, который будет присвоен переменной слева. Например:

__iadd__(self, other) — сложение с присваиванием, оператор +=

__isub__(self, other) — вычитание с присваиванием, оператор -=

__imul__(self, other) — умножение с присваиванием, оператор *=

__imatmul__(self, other) — умножение матриц с присваиванием, оператор @=

__itruediv__(self, other) — деление с присваиванием, оператор /=

__ifloordiv__(self, other) — целочисленное деление с присваиванием, оператор //=

__imod__(self, other) — остаток от деления с присваиванием, оператор %=

__ipow__(self, other[, modulo]) — возведение в степень с присваиванием, оператор **=

__ilshift__(self, other) — двоичный сдвиг влево с присваиванием, оператор <<=

__irshift__(self, other) — двоичный сдвиг вправо с присваиванием, оператор >>=

__iand__(self, other) — двоичное И с присваиванием, оператор &=

__ixor__(self, other) — исключающее ИЛИ с присваиванием, оператор ^=

__ior__(self, other) — двоичное ИЛИ с присваиванием, оператор |=

Преобразования типов

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

__complex__(self) — преобразование типа в комплексное число

__int__(self) — преобразование типа к int

__float__(self) — преобразование типа к float

__index__(self) — преобразование типа к int, когда объект используется в срезах (выражения вида [start:stop:step])

__round__(self[, ndigits]) — округление числа с помощью функции round(...)

__trunc__(self) — вызывается методом math.trunc(...)

__floor__(self) — вызывается методом math.floor(...)

__ceil__(self) — вызывается методом math.ceil(...)

Вызываемые объекты

__call__(self[, args...]) — позволяет любому экземпляру класса вести себя как обычная функция. Например:

__await__(self) — возвращает итератор, превращая класс в корутину, результат выполнения которой можно получить с помощью await. Подробнее об этом можно узнать в PEP 492.

Контекстные менеджеры

Любой объект может быть представлен как контекстный менеджер, который вызывается с помощью with или async with. Данная конструкция позволяет выполнить какие-либо действия по настройке объекта и при выходе из контекстного менеджера, произвести какие-либо действия по очистке, не смотря на то, было ли вызвано исключение в блоке контекстного менеджера.

__enter__(self) — определяет начало блока контекстного менеджера, вызванного с помощью with

__exit__(self, exc_type, exc_value, traceback) — определяет конец блока контекстного менеджера. Может использоваться для контролирования исключений, очистки, или любых действий, которые должны быть выполнены после блока внутри with. Если блок выполнился успешно, то все три аргумента (exc_type, exc_value и traceback) будут установлены в значение None.

Например:

__aenter__(self) — аналогично __enter__, только функция возвращает корутину (результат которой можно получить с помощью await)

__aexit__(self, exc_type, exc_value, traceback) — аналогично __exit__, только функция возвращает корутину (результат которой можно получить с помощью await)

Например:

Неиспользуемые методы

Некоторые методы, после полного перехода с Python 2 на Python 3 стали устаревшими и больше не используются.

__unicode__ — полностью исчез в версии Python 3, вместо него используются отдельные методы __str__и __bytes__

__div__ — так как в Python 3 теперь по умолчанию «правильное деление», данного метода не существует

__cmp__ — более не существует, вместо него используются __lt__, __le__, __eq__, __ne__, __gt__и __ge__

__nonzero__ — переименован в __bool__

Упрощение работы с магическими методами

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

Пример таких библиотек:

• dataclasses
• attrs

Принципы и идеология этих (и других библиотек) схожи в одном – они позволяют реализовать всю необходимую логику работы с объектом, не дублируя код для каждого отдельного объекта.

Например:

Данный объект будет иметь в себе:

• Три атрибута first_name, last_name и age, которые также будут передаваться в конструктор класса;
• Будет реализован метод __repr__ для вывода информации для отладки;
• Будут реализованы все магические методы сравнения (такие как __lt__, __eq__ и так далее), а также метод __hash__.

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

Общее платформ и фреймворков

Для начала определимся с терминами.

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

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

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

В чем различия

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

Среди сервисов могут быть собственное NLU-ядро компании (Natural Language Understanding, понимание естественного языка), телефония, ASR (Automatic Speech Recognition, автоматическое распознавание речи) и TTS (Text-to-Speech, синтез речи), CRM- и BI-системы, текстовые каналы.

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

Например, если код бота написан на базе фреймворка JAICF, проект можно опубликовать в платформе JAICP, где есть необходимые интеграции.

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

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

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

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

Проекты на базе платформ и фреймворков

На базе фреймворка можно сделать бота любого уровня. С помощью платформ можно создавать ботов техподдержки, голосовых ассистентов с разветвленной логикой и чит-чатом, ИИ-операторов для входящей и исходящей телефонии. Многие считают платформы оптимальным инструментом для разработки умного IVR (Interactive Voice Response, интерактивное голосовое меню) и ботов для телефонных обзвонов, так как инфраструктура работы с телефонией уже реализована внутри инструмента.

Кроме того, платформы часто оснащены полезными фичами для естественного звучания робота в телефонного канале, такими как гибридный синтез, фоновый шум колл-центра, умные перебивания в зависимости от реплики абонента в случае JAICP.

Как выбирать инструмент

Примеры платформ: JAICP, SAP Conversational AI, Intelligent Virtual Assistants (iVa) Platform

Примеры фреймворков: Deep Pavlov — фреймворк для Python, JAICF — для Kotlin, Jovo — для TypeScript.

1. Какая команда выделена под проект? Если разработчики компании работают на Python или JavaScript, то целесообразно искать удобное для них решение. По платформам: есть ли внутри хороший SDK и грамотные абстракции?
2. Есть ли служба поддержки или сообщество, куда можно обратиться за советом и поддержкой? По фреймворку: обязательно зайдите на Github и найдите дату последнего обновления, оцените активность сообщества.
3. NLU. Хватит ли функционала платформы, чтобы научить бота понимать естественную речь, или обучение предлагается только с помощью простейших паттернов? Предусмотрена ли функция интеграции со сторонними NLU по API? По фреймворку: проверьте, что инструмент имеет собственное ядро NLU, так как это самый сложный и важный компонент для разработки в области разговорного ИИ.
4. Достаточно ли возможностей инструмента, чтобы бот соответствовал всем изначальным требованиям? Так, для определенных категорий бизнесов, таких как банки и медицинские учреждения, обязательной является установка в контур, а данную возможность предоставляют не все платформы.

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

Репозиторий проекта на GitHub

Предыдущие уроки:

Урок 1 — REST API и веб-сервер.

Урок 2 — REST API, логирование.

Урок 3 — REST API. Конфигурация.

Урок 4 — REST API, MongoDB, первая часть.

Урок 5 — REST API, MongoDB, вторая часть.

Репозиторий проекта на GitHub

Предыдущие уроки:

Урок 1 — REST API и веб-сервер.

Урок 2 — REST API, логирование.

Урок 3 — REST API. Конфигурация.

Урок 4 — REST API, MongoDB, первая часть.

Репозиторий с кодом уроков

Предыдущие уроки:

Урок 1 — REST API и веб-сервер.

Урок 2 — REST API, логирование.

Урок 3 — REST API. Конфигурация.

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

Используемая библиотека для конфигурации.

Ссылка на репозиторий с кодом уроков.

Предыдущие уроки:

Урок 1 — REST API и веб-сервер.

Урок 2 — REST API, логирование.

Существует много разных логгеров. Мне понравился logrus. Я написал для него обёртку, он справляется со своей задачей. Вы можете взять любой другой логгер. Это не важно. Важно использовать логирование и использовать его по назначению. Это позволяет понять, что сейчас происходит, что конкретно приложение делает.

Предыдущие уроки:

Урок 1 — REST API и веб-сервер.

Также я устроил конкурс. Разыгрываю 2 купона на IDE Goland.

Правила:

1. Подписаться на ютуб-канал.
2. Написать комментарий под этим видеоуроком по Golang.
3. Присоединиться к группе Telegram или VK (ссылки в описании к видео)
4. Написать реализацию функции замыкания (closure), выложить на github.com в виде репозитория или Gist.
5. Ссылку на Gist или репозиторий прислать в личку в VK или в Telegram.

Два победителя (выберет сайт random.org) получат купон на IDE Goland от компании JetBrains.

Приятного просмотра и желаю удачи в конкурсе!

Литерал объекта в JavaScript — это список пар ключ-значение, перечисленных через запятую и обёрнутый фигурными скобками.

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

Выглядит так себе. Этот код не только плохо читается, но и использует повторяющийся вызов функции toLowerCase().

Чтобы уменьшить количество кода, мы можем использовать дополнительную переменную или конструкцию switch.

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

Альтернатива

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

Мы используем объект, ключи которого выполняют роль условий, а значения — результатов. Затем, с помощью квадратных скобок, мы проверяем наличие нужной строки. Так как полученная строка может быть null или undefined, то мы используем оператор Nullish coalescing (??). Таким образом мы избавляемся от null-значения, но не исключаем случай, что результат может быть равен нулю или false.

Это немного надуманный пример, но он иллюстрирует то, как использование ?? помогает избежать багов.

Подробнее о способах обработки undefined в JavaScript.

Сложная логика

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

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

Вывод

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

1. Кто такой Senior программист?
2. Что должен знать и уметь сеньор разработчик?
3. Дополнительные материалы

Кто такой Senior программист?

Если не вдаваться в дебри специализаций, это одна из ступеней развития разработчика в цепочке Junior → Middle → Senior. Перед джуном также может указываться стажёр, а после сеньора — тимлид, но мы рассмотрим именно трёхэтапную схему.

Junior разработчик

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

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

Middle разработчик

По сути, это «подросший» Junior, который освоил необходимый стек технологий, уверенно обращается с Git, командной строкой, самостоятельно и в срок решает поставленные задачи.

Кроме того, Middle — это командный игрок, который может и чужой код прочесть, и дельное замечание по нему сделать, если требуется.

Где-то между джуном и мидлом есть ещё так называемые «уверенные джуны», но это, скорее, не промежуточный этап, а просто попытка компаний оставить уже обросшего опытом специалиста на позиции и зарплате Junior-разработчика. Как только почувствовали, что знаете и можете гораздо больше, чем джун, сразу же обсудите это с руководством.

Senior разработчик

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

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

Что должен знать и уметь сеньор разработчик?

Так как же стать Senior разработчиком? Не стойте на месте: осваивайте новые языки и технологии, записывайтесь на вебинары, бросайтесь в принципиально новые подходы, дабы не пасти задних, и развивайтесь всесторонне.

Довольно обобщённые советы, не правда ли? Что ж, попытаемся их структурировать и раскрыть подробнее.

1. Технические навыки

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

Перед началом работы всегда спрашивайте себя:

1. Можно ли разбить таск на подзадачи, и если да, то как?
2. Какой подход к решению этой задачи наиболее оптимален?
3. Смогу ли я подключить других сотрудников, и как в таком случае организовать рабочий процесс?

Если для решения проблемы нужно освоить новую СУБД, фреймворк или сторонний сервис, вы осваиваете это.

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

Кроме того, чтобы думать, как Senior, нужно расширять способы обработки информации. В этом поможет книга Иана Макдермотта и Джозефа О`Коннора «Искусство системного мышления». Также есть краткая выжимка основных мыслей в формате аудиокниги:

2. Коммуникативные навыки

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

Как вы уже поняли, сеньоры часто ведут проекты самостоятельно, поэтому очень важно уметь обрабатывать ТЗ заказчика, задавать правильные вопросы, которые выльются в исчерпывающие ответы, устанавливать сроки выполнения и выстраивать план работ. Разумеется, проджект-менеджеров никто не отменял, но в идеале старший разработчик может справляться и без их помощи.

А ещё программирование — это почти всегда работа в команде, поэтому нужно уметь организовать процесс, отталкиваясь от навыков и запросов других сотрудников. Вы должны быть на «ты» с гибкими методологиями разработки, и такие термины, как Agile, Scrum и Kanban, не должны вас пугать.

3. Навыки ментора и интервьюера

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

Нелишним будет прочесть книги «HBR Guide. Эмоциональный интеллект» и «Как разговаривать с кем угодно, когда угодно и где угодно».

4. Навыки профессионального роста

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

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

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

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

5. Навыки работы с сообществом

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

Иными словами, Senior разработчик не закрывается в своём рабочем пространстве, втихую накапливая знания и скрывая их от остальных. Скорее, это те самые гуру, раздающие дельные советы на Stack Overflow. Они любят делиться своим опытом, так как это:

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

Вместо эпилога

Всё сказанное уже сказано, поэтому просто держите несколько дополнительных материалов, чтобы лучше понять, как стать Senior разработчиком:

• Отличия junior, middle и senior разработчиков — объясняют эксперты
• Практическое руководство как стать Senior Frontend Developer

Задача #1

Ваша компания отправляет СМС с трекинговой ссылкой, но ссылка достаточно длинная и из-за этого СМС выходит за 70 символов (длина 1 СМС). Необходимо спроектировать сервис-«укорачиватель ссылок», чтобы сэкономить деньги компании. Интервьюер при этом выступает заказчиком со стороны бизнеса и ему можно задавать вопросы по сути задачи.

Задача #2

Загрузка из «плохого» API большого количества данных и их синхронизация с табличкой в БД (например, Postgres). Считаем, что на входе мы скачиваем JSON-массив из N (>100k) объектов (dict) заданной структуры (primary key поле + некоторое количество строковых полей). Считаем, что нам надо раз в некоторое время запускать функцию, которая создаст записи, которые есть в JSON, но их нет в базе, а далее обновит строковые поля там, где что-то поменялось, и пометить удаленными записи, которых нет в JSON, но они все еще есть в базе.

Задача #3

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

Задача #4

Что такое итераторы/генераторы/генераторные выражения, чем они отличаются и когда и как все это нужно использовать.

Задача #5

Серия вопросов по СУБД (в частности Postgres). По всем пунктам можно погрузиться в достаточно низкоуровневые детали реализации, но важно и в целом оценить осведомленность кандидата об основных принципах работы базы, достаточных для большинства задач.

Что такое транзакция? Приведите пример, где это может пригодиться. Расскажите про свойства транзакций и уровень изолированности.

Что такое server side cursor и зачем он нужен?

Что такое VACUUM и зачем он нужен в PostgreSQL?

Что такое EXPLAIN? Какая разница между ним и EXPLAIN ANALYZE?

Все советы написаны с расчетом на пользователей ОС семейства Linux, но если вы используете ОС Windows почти все рекомендации вам также пригодятся, особенно если вы знакомы с подсистемой WSL.

Попробуйте VSCode в качестве вашей новой IDE

Все еще используете Sublime Text, Emacs или IDEA? Попробуйте VSCode, написанный на веб-движке Electron. Огромное количество удобных расширений позволяет быстро и удобно работать с исходным кодом, вашим любимым языком программирования, git-репозиториями и т.п.

Запомните комбинации клавиш

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

Сдвинуть строчку влево или вправо? Легко!  Комбинация «Ctrl+]» сдвинет вправо, «Ctrl+[» — влево.

Закомментировать 3 строчки? Еще легче. Выделяем строки (необязательно полностью) и нажимаем «Ctrl+/».

Вот увидите, как уменьшится время, затрачиваемое на написание кода, работать станет гораздо комфортнее.

Прокачайте навыки использования Git

Чаще всего в качестве системы контроля версий используется Git. Если у вас нет опыта или вы знаете только git clone <repo>, то посоветую вам ресурс с довольно понятным и наглядным обучением.

Попробуйте Docker

Упаковка вашего приложения в Docker поможет cохранить вашу систему чистой, а рабочее окружение для приложения – одинаковым. Тем более, что есть множество публичных базовых образов именно с нужным вам окружением. А если, например, вам нужно поднять не только приложение, но и рядом стоящую инфраструктуру, то пригодится docker-compose.

Создайте свои собственные короткие команды (алиасы)

Если вы пользуетесь консолью для, например, запуска какого-нибудь контейнера Docker, то вам знакома команда docker run <opt1> <opt2> <image>. Зачем каждый раз набирать или искать эту команду в истории?

Создайте алиас для свой команды:

1. Откройте ~/.bash_profile.
2. Добавьте новую строчку с вашим алиасом <alias>=<your long command>.

К примеру, так можно запускать одноразовый контейнер в интерактивном режиме по команде docrun <image> (такой контейнер будет удален сразу же после остановки):

alias docrun="docker run -it --rm $@"

Для передачи дополнительных параметров, таких как имя образа и ключи запуска, используется bash-переменная «$@», в которую передается все, что идет после  алиаса.

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

alias fdir1="cd ~/mycoolproj1"

Далее используя наш алиас fdir1, мы сразу будем попадать в наш проект. Удобно? Удобно!

Попробуйте заменить интерактивную оболочку

Замените обычный bash на zsh с дополнением oh-my-zsh, которые позволят вам использовать различные плагины, упрощающие жизнь. Автодополнение команд и их ключей, напоминание об алиасах, умная история команд и настройка внешнего вида консоли по своему вкусу.

Используйте meld для сравнения файлов или даже директорий

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

Порекомендую программу Meld с графическим интерфейсом, которая интуитивно понятна в использовании. Есть дистрибутив как для Windows, так и для Linux.

На этом все, спасибо за внимание!

Ну, а если вам самим есть чем поделиться с сообществом – добро пожаловать в комментарии.

Какие знания понадобятся:

• JavaScript;
• базовые структуры данных;
• большое O.

Как подойти к решению задач:

• размышляйте вслух;
• не торопитесь и не сдавайтесь;
• работайте с энтузиазмом.

JavaScript

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

Ресурсы для изучения:

• «Современный учебник JavaScript» (перевод Ильи Кантора);
• Eloquent JavaScript («Красноречивый JavaScript») (автор Marijn Haverbeke);
• JavaScript Ninja (автор John Resig).

Структуры данных

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

• массивами;
• объектами/Хэш-мапами;
• связанными списками;
• стеками;
• очередями;
• деревьями;
• графами.

Большое О

О большое описывает эффективность выполнения кода — то есть то, насколько быстро выполняется алгоритм с учётом входных данных (time complexity).

После того, как вы напишете свое решение, важно назвать его сложность и время выполнения.

Большое О к задаче пишется комментарием над решением.

Пример:

// O(n) time | O(1) space

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

Размышляйте вслух

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

Не торопитесь и не сдавайтесь

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

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

Работайте с энтузиазмом

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

Задачи уровня Middle

Сумма двух чисел

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

Пример входных данных:

На выходе:

[-1, 11] или [11, -1], так как -1 + 11 = 10 = targetSum

Преобразование массива в объект с группировкой и фильтрацией элементов

Напишите функцию, которая на вход принимает массив из студентов, где студент — это объект с полями «имя», «возраст» и «номер группы» {name: string, age: number, groupId: number}, а на выходе возвращает объект, где ключ — это номер группы, а значение — массив из студентов старше 17 лет.

Проверка строки на палиндром

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

Палиндром — слово или текст, одинаково читающееся в обоих направлениях.

Найти ближайшее значение в бинарном дереве

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

Node = { value: number | null, left: Node | null, right: Node | null }

Итог

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

Поэтому дерзайте и удачи на собеседовании 🙂

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

Например, самый простой SQL-запрос читается как предложение на английском языке:

Написание простых запросов к базе данных, в основном, не требует от разработчика глубоких знаний о её внутренней работе. И когда дело доходит до производительности, разработчик всегда «тыкает пальцем» в базу данных, указывая на медленное выполнение запроса и снимая с себя ответственность. Однако, опыт говорит об обратном, разработчик должен иметь представление о внутренней работе SQL и индексировании данных. Только в этом случае он сможет написать правильный запрос и получить быстрый ответ от базы данных. Фактически решение о необходимости индексирования должно ложиться на плечи разработчика. Этот этап является одним из важнейших этапов при работе с SQL, так как только при индексировании база данных будет правильно понимать «как получить требуемую информацию».

На страницах книги «SQL Performance explained» автор рассказывает о том, что нужно знать разработчику об индексах, а точнее о B-tree индексах, как с ними работать и применять на практике.

Итак, подробнее о книге

Структура книги хорошо адаптирована для разработчиков, большинство глав соответствуют определённой части оператора SQL:

• Anatomy of an Index.
• The Where Clause.
• Performance and Scalability.
• The Join Operation.
• Clustering Data.
• Sorting and Grouping.
• Partial Results.
• Insert, Delete and Update.
• Execution Plans.

Это поможет быстро ориентироваться по содержанию книги, когда вы будете применять знания на практике.

Глава Anatomy of an Index не содержит в себе никаких примеров SQL-запросов, но описывает структуру индекса. Это понимание обязательно для последующих глав. Здесь вы найдёте что такое Slow Index.

Глава The Where Clause является самой объёмной и содержит максимум описания оператора WHERE. Прочтение этой главы помогло мне отойти от простых выборок по одной колонке таблицы. Применяю сложные запросы с выборкой по нескольким колонкам из нескольких таблиц, используя диапазоны (для выборки дат) и другие условия. После изучения данной главы я смог оптимизировать текущий код нагруженного интернет-магазина и повысить производительность поиска товаров в три раза. Первоначально сложная фильтрация товаров выполнялась в несколько запросов и влекла за собой проблему с паджинацией на странице. После добавления индексов и фильтрации товаров по одному SQL-запросу, скорость выдачи увеличилась в три раза.

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

Главы The Join Operation и Sorting and Grouping объясняют применение индексов для быстрого соединения таблиц, сортировки и группировки данных.

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

И тут на помощь приходят индексы, которые хранят данные предварительно отсортированным способом.

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

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

Глава Partial Results. В этой главе показано, как использовать конвейерный порядок для эффективного получения частичных результатов. Данный подход поможет повысить производительность запросов. Рассмотрим, например, кейс с социальной сетью и выдачей последних 10 сообщений пользователю. Применение обычной сортировки всех сообщений и ограничение по лимиту выдачи вызовет серьёзные проблемы с производительностью, так как объём таблицы с сообщениями может быть огромным.

В главе Insert, Delete and Update подробно объясняется, как влияет применение индексов на производительность запросов записи. Использование индексов должно быть продуманным, поскольку всё имеет свою цену.

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

Запрос INSERT — единственный запрос, который не получает никакой выгоды от использования индексов в базе, потому что не использует условие WHERE. Данное поведение показало мне «цену» большого количества индексов. Теперь я стараюсь не злоупотреблять индексами в таблицах.

Запрос DELETE очень похож на запрос выборки данных, но с дополнительным шагом для удаления строк. Шаг удаления аналогичен вставке новой строки. И тут нужно понимать, что есть шаг, который не «любит» индексы, но без них будет выполняться полное чтение таблицы для нахождения нужных строк. Таким образом, для запроса DELETE  индексы просто необходимы.

Запрос UPDATE содержит в себе как удаление старой записи, так и вставку новой. Но есть главное отличие: данный запрос затрагивает не все столбцы, соответственно, и не все индексы таблицы, что повышает производительность запроса по отношению к INSERT и DELETE

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

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

Выводы

Самые важные главы книги «SQL Performance explained» для меня:

• Anatomy of an Index.
• Performance and Scalability.
• Execution Plans.

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

Узнал много интересной информации о Slow indexes (да, бывают и такие!), Explain запросах и как с ним работать. И самое главное: как строить, развивать и улучшать БД для хранения и получения большого объёма данных.

В заключение хочу ещё раз отметить, что данная книга обязательна к прочтению всем разработчикам. Она поможет ответить на большинство вопросов, связанных с производительностью БД, «прокачает» вас как разработчика нагруженных систем и проектов и даст хорошее понимание о работе SQL.

• sorted() возвращает новый отсортированный список из любого итерируемого объекта, а list.sort() изменяет список на месте • Параметр key позволяет задать функцию сортировки — от простых lambda до operator.itemgetter() и attrgetter() • Сортировка в Python стабильна (Timsort) — элементы с одинаковыми ключами сохраняют исходный порядок • Параметр reverse=True сортирует по убыванию без потери стабильности • Для сложных сортировок можно комбинировать несколько последовательных вызовов sorted() благодаря стабильности алгоритма

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Основы сортировки

Так как отсортировать список Python? Для сортировки по возрастанию достаточно вызвать функцию сортировки Python sorted(), которая вернёт новый отсортированный список:

Для сортировки списка Python также можно использовать метод списков list.sort(), который изменяет исходный список (и возвращает None во избежание путаницы). Обычно Python sort list не так удобен, как использование sorted(), но если вам не нужен исходный список, то так будет немного эффективнее:

Прим.перев. В Python вернуть None и не вернуть ничего — одно и то же.

Ещё одно отличие заключается в том, что метод list.sort() определён только для списков, в то время как функция sorted Python работает со всеми итерируемыми объектами. Грубо говоря, функция sort Python сортирует список и сохраняет его в отсортированном виде, в то время как функция sorted Питон создаёт новый отсортированный список без изменения исходного.

Прим.перев. При итерировании по словарю Python возвращает его ключи. Если вам нужны их значения или пары «ключ-значение», используйте методы dict.values() и dict.items() соответственно.

Рассмотрим основные функции сортировки Python.

Функции-ключи

С версии Python 2.4 у list.sort() и sorted() появился параметр key для указания функции, которая будет вызываться на каждом элементе до сравнения. Вот регистронезависимое сравнение строк:

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

Часто можно встретить код, где сложный объект сортируется по одному из его индексов. Например:

Тот же метод работает для объектов с именованными атрибутами:

Функции модуля operator

Показанные выше примеры функций-ключей встречаются настолько часто, что Python предлагает удобные функции, чтобы сделать всё проще и быстрее. Модуль operator содержит функции itemgetter(), attrgetter() и, начиная с Python 2.6, methodcaller(). С ними всё ещё проще:

Функции operator дают возможность использовать множественные уровни сортировки массива Python. Отсортируем учеников сначала по оценке, а затем по возрасту:

Используем функцию methodcaller() для сортировки учеников по взвешенной оценке:

Сортировка по возрастанию и сортировка по убыванию в Python

list.sort() и sorted() есть параметр reverse, принимающий boolean-значение. Он нужен для обозначения сортировки по убыванию. Отсортируем учеников по убыванию возраста:

Стабильность сортировки и сложные сортировки в Python

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

Обратите внимание, что две записи с 'blue' сохранили начальный порядок. Это свойство позволяет составлять сложные сортировки путём постепенных сортировок. Далее мы сортируем данные учеников сначала по возрасту в порядке возрастания, а затем по оценкам в убывающем порядке, чтобы получить данные, отсортированные в первую очередь по оценке и во вторую — по возрасту:

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

Декорируем-сортируем-раздекорируем

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

Вот так можно отсортировать данные учеников по оценке:

Это работает из-за того, что кортежи сравниваются лексикографически, сравниваются первые элементы, а если они совпадают, то сравниваются вторые и так далее.

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

1. Сортировка стабильна — если у двух элементов одинаковый ключ, то их порядок не изменится.
2. У исходных элементов не обязательно должна быть возможность сравнения, так как порядок декорированных кортежей будет определяться максимум по первым двум элементам. Например, исходный список может содержать комплексные числа, которые нельзя сравнивать напрямую.

Ещё эта идиома называется преобразованием Шварца в честь Рэндела Шварца, который популяризировал её среди Perl-программистов.

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

Использование параметра cmp

Все версии Python 2.x поддерживали параметр cmp для обработки пользовательских функций сравнения. В Python 3.0 от этого параметра полностью избавились. В Python 2.x в sort() можно было передать функцию, которая использовалась бы для сравнения элементов. Она должна принимать два аргумента и возвращать отрицательное значение для случая «меньше чем», положительное — для «больше чем» и ноль, если они равны:

Можно сравнивать в обратном порядке:

При портировании кода с версии 2.x на 3.x может возникнуть ситуация, когда нужно преобразовать пользовательскую функцию для сравнения в функцию-ключ. Следующая обёртка упрощает эту задачу по Python:

Чтобы произвести преобразование, оберните старую функцию:

В Python 2.7 функция cmp_to_key() была добавлена в модуль functools.

Поддержание порядка сортировки

В стандартной библиотеке Python нет модулей, аналогичных типам данных C++ вроде set и map. Python делегирует эти задачи сторонним библиотекам, доступным в Python Package Index: они используют различные методы для сохранения типов list, dict и set в отсортированном порядке. Поддержание порядка с помощью специальной структуры данных может помочь избежать очень медленного поведения (квадратичного времени выполнения) при наивном подходе с редактированием и постоянной пересортировкой данных. Вот некоторые из модулей, реализующих эти типы данных:

• SortedContainers — реализация сортированных типов list, dict и set на чистом Python, по скорости не уступает реализациям на C. Тестирование включает 100% покрытие кода и многие часы стресс-тестирования. В документации можно найти полный справочник по API, сравнение производительности и руководства по внесению своего вклада.
• rbtree — быстрая реализация на C для типов dict и set. Реализация использует структуру данных, известную как красно-чёрное дерево.
• treap — сортированный dict. В реализации используется Декартово дерево, а производительность улучшена с помощью Cython.
• bintrees — несколько реализаций типов dict и set на основе деревьев на C. Самые быстрые основаны на АВЛ и красно-чёрных деревьях. Расширяет общепринятый API для предоставления операций множеств для словарей.
• banyan — быстрая реализация dict и set на C.
• skiplistcollections — реализация на чистом Python, основанная на списках с пропусками, предлагает ограниченный API для типов dict и set.
• blist — предоставляет сортированные типы list, dict и set, основанные на типе данных «blist», реализация на Б-деревьях. Написано на Python и C.

Прочее

Для сортировки с учётом языка используйте locale.strxfrm() в качестве ключевой функции или locale.strcoll() в качестве функции сравнения. Параметр reverse всё ещё сохраняет стабильность сортировки. Этот эффект можно сымитировать без параметра, использовав встроенную функцию reversed() дважды:

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

Для типов, сравнение которых работает обычным образом, рекомендуется определять все 6 операторов. Декоратор классов functools.total_ordering упрощает их реализацию. Функциям-ключам не нужен доступ к внутренним данным сортируемых объектов. Они также могут осуществлять доступ к внешним ресурсам. Например, если оценки ученика хранятся в словаре, их можно использовать для сортировки отдельного списка с именами учеников:

Часто задаваемые вопросы

Чем отличается sorted() от .sort() в Python?

Функция sorted() принимает любой итерируемый объект и возвращает новый отсортированный список, не изменяя исходные данные. Метод list.sort() работает только со списками и сортирует их на месте, возвращая None. Если исходный порядок элементов больше не нужен, .sort() работает немного быстрее за счёт отсутствия создания нового объекта.

Как отсортировать список словарей по ключу?

Используйте параметр key с lambda-функцией или operator.itemgetter(). Например, sorted(data, key=lambda x: x['age']) отсортирует список словарей по значению ключа 'age'. Для множественной сортировки передайте кортеж: key=lambda x: (x['grade'], x['age']).

Что такое стабильная сортировка в Python?

Стабильная сортировка гарантирует, что элементы с одинаковыми ключами сохраняют свой исходный порядок. Python использует алгоритм Timsort, который стабилен начиная с версии 2.2. Это позволяет строить сложные сортировки последовательными вызовами sorted() — сначала по вторичному ключу, затем по первичному.

Как отсортировать список в обратном порядке?

Передайте параметр reverse=True в sorted() или list.sort(). Например: sorted([3, 1, 2], reverse=True) вернёт [3, 2, 1]. Этот параметр сохраняет стабильность сортировки — элементы с одинаковыми ключами не поменяют взаимный порядок.

Надеемся, теория по Python list sort и соответствующие задачи по Питону с разбором были для вас полезны. Вас также может заинтересовать статьи:

• Хочу научиться программировать на Python. С чего начать?
• Хочу научиться программировать на Python: инструкция для продолжающих

Стоит отметить, что несмотря на то что в IT выработана шкала для оценки программистов (trainee, junior, middle, senior, lead), с которой более или менее все согласны, с точным определением каждого уровня общего мнения среди компаний пока нет. Поэтому каждая компания устанавливает внутренние требования к навыкам каждого уровня.

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

Позиция Middle-разработчика предполагает не только уверенное знание языка программирования, но и широчайшие познания в смежных технологиях. Позиция Middle накладывает на специалиста ответственность не только программировать «всё что угодно», но и обучать, оптимизировать код, разбирать и поддерживать чужой код, как будто родной. Фактически сейчас для вакансий Middle-разработчика предъявляются требования, как несколько лет назад для Senior.

Мы выяснили, что должен знать Middle-программист в 2020 году, и собрали общие вопросы с собеседований, по ответам на которые работодатели определяют, «дорос» кандидат до мидла или нет.

Hard skills

Каков ваш уровень владения языком программирования и сопутствующими инструментами?

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

В каких проектах вы участвовали? Сколько из них вели сами?

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

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

Каков ваш навык работы с базами данных?

Работаете с бэкендом? В таком случае вы должны свободно обращаться к базам данных, иметь навыки работы с одной или несколькими СУБД.

Знать и уметь строить оптимальную архитектуру БД. БД зачастую является самым узким местом производительности проекта. Менять архитектуру БД на живом проекте очень проблематично и дорого.

Это основное из того, что должен знать Middle-разработчик. Не стоит забывать и о нормализации, денормализации и характеристиках каждой нормальной формы.

Расскажите о своём уровне владения выбранной IDE

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

Другие технические навыки

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

Что касается технических навыков Middle-разработчика по frontend JavaScript, то специалист такого уровня должен:знать один из популярных JS-фреймворков (Vue, Angular), а также популярную библиотеку (React);знать SASS/SCSS/Less/PostCSS;уметь самостоятельно настроить систему сборки проекта Grunt/Gulp/Webpack, работать с голым JS (ES5, ES6, ES7);знать и понимать RESTful интерфейсы;уметь пользоваться средствами совместного использования кода (Git + GitFlow).
Также есть дополнительные навыки, которые дают преимущества. Большим плюсом в работе будут:опыт разработки серверного кода под Node.js, TypeScript;понимание SOLID, Dependency Injection, знание Linux (Debian-like);опыт работы с TDD/BDD, тест-фреймворки (Mocha, Should, Chai, Jest);знание Docker (большим плюсом будет Kubernetes/Docker Swarm);опыт в PostgreSQL/MySQL etc.

Самое важное для мидла, это знать, как изнутри работает используемая тобой технология, твой фреймворк. Не то, как он производит рендер (с помощью VDOM и т. п.), а как код написан, как происходит магия. Открой GitHub, посмотри исходники React, как, например, this.setState заставляет компонент делать рендер.

Какие методологии разработки вы знаете? По каким из них работали?

Одной теории недостаточно. Вы уже должны были участвовать в проектах «под ключ» и понять, как работает та или иная методология. Хорошо, если у вас был опыт работы по нескольким методологиям: если так, обязательно проведите сравнение плюсов и минусов, исходя из практики.

Что ещё должен знать Middle-разработчик

Знать и уметь писать оптимальные запросы по выборке данных (DML-запросы).Немного знать про ACID, понимать, что это такое и зачем нужно.Знать три столпа ООП (наследование, полиморфизм и инкапсуляция).Знать, что такое шаблоны проектирования и зачем они нужны. Понимать различия между ними.Понимать, что такое SOLID и когда он уместен.Знать и понимать, что такое тестирование кода и как оно реализуется.Желателен опыт в написании тестов. Это заставляет мозг разработчика генерировать совершенно другой код. Я специально поставил этот пункт ниже SOLID и шаблонов проектирования: сначала SOLID и шаблоны, а только потом тесты. Тогда будет получаться код, который будет легче покрываться тестами.

Soft skills

Насколько вы коммуникабельны?

Если в случае с Junior-программистом коммуникативные навыки просто важны, то для Middle-разработчика они обязательны.

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

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

Ваши навыки работы в команде

С точки зрения soft скиллов Middle-разработчику, конечно, нужно осваивать компетенции: ведение переговоров, общение с командой, иметь представление об управлении командой. Эти навыки пригодятся в дальнейшем карьерном росте.

Умеете ли вы разрешать конфликты?

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

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

Каков ваш уровень английского языка?

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

Способны ли вы доступно доносить свои идеи, убеждать в их правильности?

Что касается «софтскиллс», они необходимы для выполнения многочисленных ролей в команде — разработчик, ментор, докладчик, тимлид и другие. Что для этого понадобится специалисту? Убеждать коллег и клиентов. Иногда даже продавать — идеи, решения, преимущества. Презентовать свои идеи. Обучать. Планировать свою деятельность, ставить задачи перед подчинёнными, контролировать их выполнение. Для этого и много другого нужно развивать соответствующие навыки.

Можно ли вас охарактеризовать, как внимательного человека?

Очень хорошее качество, которое надо развивать разработчику, — это внимательность. Она позволит вовремя заметить, что с «канарейкой» что-то не то. Грамотный Middle-разработчик должен непрерывно отслеживать «жизненные показатели» проекта, чтобы вовремя понять, что «чирикает» после недавнего коммита он уже не так бодро.

Если возникла проблема, как вы будете её решать?

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

На первом месте здесь стоит умение искать информацию. Перед собеседованием вспомните основные источники информации, к которым вы обращаетесь в первую очередь (после документации, разумеется).

Можете ли вы оценить время выполнения задачи?

Это то, что должен уметь Middle-разработчик, особенно если речь идёт о работе в команде: в этом случае необходимо оценить время, исходя из знаний и навыков каждого участника проекта. Следует учиться правильно определять сроки выполнения работы.

Мидл уже имеет достаточный опыт работы, что позволяет ему декомпозировать задачи более-менее правильно. Мидл умеет декомпозировать, а значит он может точнее оценивать задачи. Он должен уметь соблюдать сроки. Это умение нельзя переоценить.

Планируете ли вы развиваться до сеньора или тимлида?

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

Выводы

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

Не завышены ли требования к мидлам? Возможно, кто-то из IT-специалистов сталкивался с тем, что, уже несколько лет будучи мидлом, на собеседовании в какой-либо компании его оценивают как джуниора. Связано это, как правило, с двумя факторами: первое — разные требования в разных компаниях. Второе — часто в уровень квалификации, кроме перечисленных выше hard и soft skills, ещё включают погружённость сотрудника в предметную область, знание специфики бизнеса. Эти знания делают сотрудника ценным для текущей организации, но могут значить меньше в новой для него организации.

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

Когда начинаешь исследовать какую-то обширную тему в программировании, количество скачанных проектов и созданных черновиков постепенно превышает все мыслимые и немыслимые пределы. А потом и вовсе всё перемешивается и теряется. Вроде помнил, что ты с этим работал, а где, когда? Я пробовал работать в Playground’ах, но они, на мой взгляд, не такие стабильные, как обычный проект, отваливается подсветка, нет возможности нормально делать Debug. С недавних пор я завел единый проект для исследования SwiftUI, и все небольшие вещи закидываю туда. Это помогает держать все в одном месте, к тому же поиск внутри проекта намного удобней. Хоть SwiftUI и предоставляет Preview для быстрого просмотра View и даже позволяет их отлаживать, все же этого не всегда хватает. Хочется и на устройстве проверить. А если держать все эти View внутри одного проекта, надо при создании новой вьюхи проставлять ее как основную в SceneDelegate, что довольно быстро начинает утомлять. Как было бы круто, если бы мы могли видеть все наши тестовые View при запуске приложения и имели возможность выбрать, с чем работать. Фантастика, скажете вы? Отнюдь ?

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

Итак, что из себя представляет View и её Preview:

Как мы видим, предпросмотр для View обеспечивается структурой, которая имплементирует PreviewProvider. Если кто не знал, можно даже внутри одного файла создавать сколько угодно структур/классов, которые будут имплементировать PreviewProvider, и все они отобразятся в зоне предпросмотра. Может пригодиться, если захотим разбить наш ContentView_Previews на несколько с разными настройками (хотя можно это же сделать и внутри одной структуры, имплементирующей PreviewProvider, но речь не об этом).

Что из себя представляет PreviewProvider? Это протокол

Главное, что можно извлечь из кода, — это не простой протокол, а PAT: Protocol with Associated Type, что сразу усложняет дело. Я перепробовал много вариантов, как обеспечить нужную функциональность с минимальными усилиями.

Начнем с того, как вообще можно подобные вещи делать в real time? В Objective-C мы могли делать все что угодно с помощью reflection — получать список всех классов, исследовать их свойства. В Swift это все дело сильно ограничили, и Mirror не даст нам всего необходимого. Поэтому пришлось смотреть в сторону objc_getClassList: это метод из рантайма Obj-C, который позволяет получить список всех классов. К сожалению, такого нет для Swift-структур, поэтому оставалось только обходится тем, что дали.

Разберем решение по частям.

Нормально работать с системным протоколом PreviewProvider не получится из-за того, что он PAT, поэтом создадим Erase-версию этого протокола:

1. Как видно, я стер тип у Previews, создав обертку anyPreviews, которая будет возвращать AnyView. Я не очень люблю такие штуки, потенциальная потеря производительности, но т.к. это не production-код, то на это можно закрыть глаза.
2. name — свойство, возвращающее имя нашей View, как оно будет отображатьcя в списке; учитывая, что все Preview имеют автоматом генерируемые имена ViewName_Previews, можно _Previews отрезать.
3. Я добавил свойство starred, т.к. число View будет все увеличиваться, а начиная работать с новым куском кода, хочется увидеть его сверху в списке. Это можно сделать, переопределив у превьюхи для новой View это свойство, возвращая true.

Сам список выглядит довольно просто.

Все View сортируются по имени и разбиваются на 2 списка, starred и обычные. Выглядеть все будет примерно так:

Ну, и в SceneDelegate просто меняем основную вьюху:

let contentView = PreviewsList()

Остался последний момент: как же сделать так, чтобы наши Preview попали в этот список.

• поменять struct на class;
• добавить поддержку PreviewHolder.

Т.е. вместо

станет

Опционально можно переопределять name и starred.

Это решение написано за пару часов, чтобы по-быстрому испытать идею. При желании его можно наворотить по полной, проставляя теги, дату создания для Preview, показывать список не основным, а в Debug-окне, что позволит использовать его даже на боевом проекте (не забываем отключать в Release-сборке). В общем, все зависит от вашей фантазии ?

Скачать проект с базовой реализацией можно здесь: Github

Подборка книг по NGINX

На русском

Разобрались с теорией и хотите больше практики? Тогда вам пригодится эта книга. Здесь вы сможете получить огромное количество практических примеров и рекомендаций по настройке и использованию серверов. Сервер NGINX обычно выбирают за эффективный механизм распределения нагрузки — в этой книге вы найдёте приёмы, которые позволят сделать этот механизм ещё эффективнее. Что ещё? A/B-тестирование, управление трафиком, интеграция с облачными платформами AWS, Azure и Google, отладка. Однако прежде чем браться за чтение, желательно ознакомиться с основными принципами работы системы.

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

На английском

Автор успел поработать в таких компаниях, как Яндекс, Booking.com и AVG, а сейчас владеет собственной консалтинговой фирмой. NGINX Essentials — 150 страниц полезной информации, без рассказов о том, что такое интернет и где находится Anykey. Чтобы продемонстрировать принципы, по которым действует система, автор использует реальный проект. Единственное, на что можно посетовать — недостаточно глубокое погружение в тонкости настроек сервера.

Монументальный труд, выдержавший четыре издания. В книге показано, как оптимизировать сетевую нагрузку, наладить взаимодействие между NGINX и Apache (или совсем отказаться от последнего) и в полной мере использовать возможности системы в веб-приложениях. Но если вы раньше не работали с NGINX, возможно, вам придётся обращаться к другим источникам.

Ещё одна книга не для новичков. Содержит пошаговые рекомендации по миграции с Apache и настройке максимальной производительности сервера NGINX. Помимо советов по настройке вы узнаете, как измерить производительность системы. Подача материала лаконичная, с практическими примерами.

Издание посвящено исключительно интеграции NGINX с фаерволлом ModSecurity 3.0. Вы узнаете, как установить и настроить наборы правил OWASP Core Rule Set и TrustWave SpiderLabs Commercial Rule Set. Возможно, благодаря узкой специализации авторам удалось максимально подробно осветить все аспекты настройки системы.

Книга поможет безболезненно перейти с Cisco ACE на сервер NGINX. Примеры настроек с детальным разбором прилагаются. Есть разделы, посвящённые установке Linux и поднятию x86 сервера.

Дополнительные ресурсы

Не нашли ответа на свой вопрос в книгах? Хотите попробовать новую систему, но не готовы настраивать собственный сервер? Не знаете, что предпочесть, NGINX или Apache? Вот подборка сайтов, которые вам помогут.

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

1. NGINX Project — сайт проекта. Отсюда стоит начать.
2. NGINX Documentation — полная документация по системе.
3. NGINX Pitfalls and Common Mistakes — учиться лучше на чужих ошибках, и здесь собраны самые распространённые.
4. NGINX Forum — не нашли ответа на свой вопрос? Спросите на форуме!
5. NGINX vs. Apache (Pro/Con Review, Uses, & Hosting for Each) — хорошая подробная статья, посвящённая сравнению NGINX и Apache.
6. NGINX Rate Limit, Burst and nodelay sandbox — песочница, в которой можно поиграть с настройками и оценить возможности сервера NGINX.

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

Обзор кэширования кода

Кэш оперативной памяти

У Chrome есть два уровня кэширования скомпилированного в V8 кода (классических скриптов и скриптов модулей): быстрый и «лучший из возможного» кэш в оперативной памяти, обеспечиваемый средствами V8 (кэш Isolate), а также полный сериализованный кэш на диске.

Кэш Isolate работает со скриптами, скомпилированными в том же V8 Isolate (т. е. тот же процесс, грубо говоря «одни и те же страницы сайта при навигации по одной и той же вкладке»). Это «лучшее из возможного» в том смысле, что кэш оперативной памяти, насколько это возможно, быстр и минимален: он использует уже имеющиеся данные за счёт потенциально более низкой частоты обращений и отсутствия кэширования между процессами.

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

Этот кэш быстрый и эффективный, но на практике у него лишь 80% частоты попаданий.

Кэш на диске

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

1. Когда JS-файл запрашивается впервые (т. е. выполняется «холодный» запуск), Chrome загружает его и даёт V8 для компиляции. Он также сохраняет файл в кэше браузера на диске.
2. Когда JS-файл запрашивается во второй раз (т. е. выполняется «тёплый» запуск), Chrome берёт файл из кэша браузера и снова передаёт его в V8 для компиляции. Однако на этот раз скомпилированный код сериализуется и прикрепляется к кэшированному файлу скрипта в качестве метаданных.
3. В третий раз (т. е. «горячий» запуск) Chrome извлекает как файл, так и метаданные файла из кэша и передаёт их в V8. Тот в свою очередь десериализует метаданные и может пропустить компиляцию.

В итоге:

Основываясь на этом описании, можно оптимизировать использование кэшей кода на вашем сайте.

Совет 1: не делайте ничего

Лучшее, что JS-разработчик может сделать для оптимизации кэширования кода, — ничего не делать. Но ничего не делать можно по-разному: пассивно и активно.

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

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

Не меняйте код

Всякий раз, когда вы отправляете новый код, он ещё не кэширован. Когда браузер делает HTTP-запрос для URL-адреса сценария, он может включать дату последней выборки этого URL-адреса. Если сервер знает, что файл не изменился, он может отправить ответ «304 Not Modified», который сохраняет кэш кода «горячим». В противном случае ответ «200 OK» обновляет кэшированный ресурс и очищает кэш кода, возвращая его обратно в «холодный» режим.

Всегда хочется сразу же отправить последние изменения кода, особенно если вы хотите измерить влияние конкретного изменения, но для кэша лучше позволить коду существовать как он есть, по крайней мере, обновлять его как можно реже. Подумайте о том, чтобы установить ограничение «≤ Х развёртываний в неделю», где Х — это слайдер, который вы можете регулировать для баланса между кэшированием и устареванием данных.

Не меняйте URL’ы

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

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

Не меняйте поведение выполнения

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

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

В этом случае только A() или B() компилируются и выполняются при «горячем» запуске и вводятся в кэш кода, но любой из них может быть выполнен и в последующих запусках. Вместо этого надо попытаться сохранить выполнение детерминированным, чтобы сохранить его в кэшированном пути.

Совет 2: сделайте что-нибудь

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

Отделите библиотеки от кода

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

Вместо этого вы можете отделить код стабильной библиотеки в самостоятельный скрипт и включить его отдельно. Затем код библиотеки может быть кэширован один раз и оставаться в кэше при изменении бизнес-логики.

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

Объедините библиотеки с кодом

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

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

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

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

Используйте преимущество эвристики IIFE

Только те функции, которые скомпилированы к моменту, когда завершится выполнение скрипта, учитываются в кэше, поэтому существует много видов функций, которые не будут кэшироваться, несмотря на выполнение в более поздний момент. Обработчики событий (даже onload()), цепочки промисов, неиспользуемые библиотечные функции и всё, что лениво компилируется без вызова к моменту, когда </script> виден — всё это остаётся ленивым и не кэшируется.

Один из способов сделать эти функции кэшированными — заставить их компилироваться. Распространённым способом принудительной компиляции является использование эвристики IIFE. IIFE (immediately-invoked function expressions) — это шаблон, в котором функция вызывается сразу после создания:

Так как IIFE вызываются немедленно, большинство движков JavaScript пытаются обнаружить их и немедленно скомпилировать, чтобы избежать затрат на ленивую компиляцию с последующей полной компиляцией. Существуют различные эвристики для раннего обнаружения IIFE (до анализа функции), наиболее распространённой из которых является символ «(» перед ключевым словом function.

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

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

Группируйте небольшие файлы вместе

В Chrome — минимальный размер для кэшей кода, сейчас это 1 КБ исходного кода. Сценарии меньше не кэшируются, так как затраты будут больше выгоды.

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

Избегайте встроенных скриптов

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

Простые сценарии не стоит встраивать в HTML, лучше выносить их в отдельные файлы.

Используйте кэши сервис-воркера

Сервис-воркер — это механизм, позволяющий вашему коду перехватывать сетевые запросы на ресурсы на вашей странице. Они позволяют вам создавать локальный кэш из некоторых ваших ресурсов и обслуживать ресурс из кэша всякий раз, когда их запрашивают. Это особенно полезно для страниц, которые продолжают работать в offline-режиме вроде PWA.

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

Воркер добавляет обработчики событий для установки (создание кэша) и извлечения (обслуживание ресурсов).

Эти кэши могут включать в себя кэшированные ресурсы JS. Но поскольку ожидается, что кэши воркеров будут преимущественно использоваться для PWA, для них используется немного другая эвристика по сравнению с обычным «автоматическим» кэшированием в Chrome. Во-первых, они сразу же создают кэш кода при каждом добавлении ресурса JS. Это означает, что кэш доступен уже при второй загрузке (а не только при третьей, как в обычном случае). Во-вторых, генерируется «полный» кэш для этих скриптов — функции больше не компилируются лениво. Всё компилируется и помещается в кэш. Преимущество заключается в быстрой и предсказуемой производительности, без каких-либо зависимостей порядка выполнения, хоть и за счёт увеличения использования памяти. Обратите внимание, что такая эвристика применяется только к кэшам сервисных воркеров, а не к другому использованию Cache API. В настоящее время Cache API вообще не выполняет кэширование кода, когда используется вне сервисных воркеров.

Трассировка

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

chrome://tracing записывает инструментальные трассировки Chrome в течение некоторого периода времени с такой визуализацией :

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

При записи вы должны выбрать, какие категории трассировать. В большинстве случаев вы можете просто выбрать набор категорий «Web developer» (Веб-разработчик), но категории можно выбрать и вручную. Важная категория для кэширования кода — v8.

После записи с категорией v8 найдите фрагменты v8.compile в трассировке (в качестве альтернативы вы можете ввести v8.compile в поле поиска интерфейса). Эти компоненты показывают компилируемый файл и некоторые метаданные о компиляции.

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

При тёплом запуске есть две записи v8.compile на сценарий: одна для фактической компиляции (как указано выше) и одна (после выполнения) для создания кэша. Вы можете узнать последнюю, так как она имеет поля метаданных cacheProduceOptions и producedCacheSize.

При горячем запуске вы увидите запись v8.compile для использования кэша с полями метаданных cacheConsumeOptions и consumedCacheSize. Все размеры выражены в байтах.

Для большинства разработчиков кэширование кода должно «просто работать». И работает это лучше всего (как и любой кэш), когда всё остаётся неизменным, и с использованием эвристики, которая может меняться между версиями. Тем не менее, кэширование кода имеет особенности, которые можно использовать, и ограничения, которых стоит избегать. Тщательный анализ с использованием chrome://tracing может помочь вам настроить и оптимизировать использование кэша вашим сайтом.

После C++ 17 это будет шестая редакция стандарта. Этот язык прошёл долгий путь от своего бытия «надмножеством C». Программирование на C++ включает в себя множество стилей: от простейшего «C с классами» до написания кода, который выглядит как произведение искусства. Список новых возможностей длинный, а объединённых предложений по спецификациям ещё больше. Каждого из этих дополнений хватит на свою собственную статью.

Для общего представления о том, что будет с C++ в следующем году, вкратце рассмотрим некоторые из новых функций, изменений и дополнений, которые ждут в C++ 20. От улучшенной проверки типов и сообщений об ошибках компилятора до Python-подобной обработки строк и планов по замене системы #include.

Делаем язык безопасней

Когда язык меньше ограничивает детали реализации, это обеспечивает большую гибкость для разработчиков. А также большой потенциал для «недоразумений», которые в будущем могут привести к ошибкам. По сей день это самая большая ценность и одновременно слабость C, и C++ всё ещё достаточно похож на него корнями. Ограничения — действенное, но непопулярное решение. Хорошо, что в C++ есть компромиссы, которые оставляют гибкость на уровне языка и добавляют ограничения на усмотрение разработчика.

Рекомендации компилятору: явные константы

Ещё в C++ 11 было введено ключевое слово constexpr как дополнение к обычному объявлению const, определяющему константное выражение, которое можно вычислять во время компиляции. Это открывает множество возможностей оптимизации для компилятора, например позволяет явно заявить, что функция будет возвращать постоянное значение. Это помогает более чётко показать намерение функции, избегая потенциальных проблем в будущем. Например:

Технически между этими двумя функциями выше нет разницы, и любая из них будет возвращать константное значение, допустимое для присваивания переменной типа const. Разница лишь в том, что функция bar() делает это в явном виде. В случае foo() это скорее побочный эффект и без полного контекста не очевидно, что возвращаемое значение функции должно быть константой. Использование constexpr устраняет любые сомнения и позволяет избежать возможных побочных эффектов, что сделает код более стабильным в долгосрочной перспективе.

constexpr подвергался нескольким переработкам ещё до релиза C++ 20. Особенно это касается снятия ранее существующих ограничений на использование этих переработок. Самое главное, новый стандарт позволяет использование функций типа virtual constexpr. Разработчики могут использовать try/catch внутри constexpr (при условии отсутствия исключений внутри) и менять члены внутри объединения.

Более того, std::string, std::vector, а также множество других ранее пропущенных в стандартной библиотеке функций будут полностью использовать constexpr. Если необходимо проверить, действительно ли фрагмент кода выполняется внутри определения константы, сделать это можно с помощью функции std::is_constant_evaluated(), которая возвращает соответствующее логическое значение.

Стоит обратить внимание, constexpr-код подразумевает, что он может быть вычислен во время компиляции и является допустимым константным выражением. Но это не обязательно, и нет гарантии, что вычисление произойдёт во время компиляции, оно может быть отложено на время выполнения. Это в основном важно для проведения оптимизации компилятором и не влияет на поведение программы, но также показывает, что constexpr — это в первую очередь отметка о намерении сделать функцию константной.

В коде выше first будет определяться во время компиляции, поскольку все задействованные выражения и значения являются константами и известны во время компиляции. А second будет определяться во время выполнения, поскольку сам non_const_factor не является константой. Это не меняет того факта, что foo() по-прежнему будет возвращать константное значение, только компилятор пока не может точно определить, какое именно. Чтобы компилятор знал значение, в C++ 20 вводится ключевое слово consteval, чтобы объявить функцию как непосредственную (immediate). Объявление foo() как consteval вместо constexpr теперь вызовет ошибку. Фактически, непосредственные функции действительно известны только во время компиляции и это превращает conteval-функции в альтернативу для макрофункций.

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

Константные выражения — не единственные изменения в C++ 20, призванные улучшить проверку времени компиляции и обеспечить стабильность.

Концепция концептов

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

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

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

Некоторые базовые концепты будут предоставлены в стандартной библиотеке, и если вы не хотите ждать обновлённых компиляторов, GCC имеет экспериментальные концепты, реализованные ещё с версии 6. Вы можете включить их с помощью параметра командной строки -fconcepts. Обратите внимание, что в первоначальном проекте и текущей справочной документации имена концептов были определены по типу CamelCase, но они будут изменены на snake_case, чтобы сохранить согласованность со всеми другими стандартными идентификаторами.

Диапазоны — новые итераторы

Диапазоны (Ranges) по сути являются итераторами, которые охватывают последовательность значений в коллекциях, таких как списки или векторы. Но вместо того, чтобы постоянно перемещать начало и конец итератора, диапазоны просто сохраняют их внутри.

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

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

Форматирование строк

Если говорить про сообщения об ошибках и про вывод в целом, библиотека libfmt в соответствии с предложением её автора будет интегрирована в языковой стандарт как std::format. Это обеспечит функциональность форматирования строк как в Python. По сравнению со всей неловкостью метода cout и тем фактом, что использование printf() в контексте C++ — это нечто неправильное, такое дополнение будет очень желанным.

Форматирование в стиле Python предлагает почти те же функции, что и printf(), только с другим синтаксисом формата строки. Оно устраняет избыточность и предлагает некоторые полезные дополнения, такие как двоичное целочисленное представление и центрированный вывод с или без символов заполнения. Самое большое преимущество — это возможность определять правила форматирования для пользовательских типов. На первый взгляд такой метод похож на __str__() в Python или toString() в Java, но при этом он также добавляет собственные типы форматирования.

В качестве примера рассмотрим strftime(). Хоть это и функция C, которая ведёт себя как snprintf(), отличие состоит в том, что она определяет пользовательские конкретные символы преобразования для своей строки формата и ожидает struct tm в качестве аргумента. Правильно реализованный std::format может быть расширен, чтобы вести себя так же, как грядущее дополнение к библиотеке std::chrono.

Расположение

В C++ 20 появилась ещё одна экспериментальная функция — source_location, обеспечивающая удобный доступ к имени файла, номеру строки или имени функции из текущего контекста вызова. В сочетании с std::format это основной кандидат для реализации пользовательской функции ведения журнала и практически современная альтернатива макросам препроцессора вроде __FILE__ и __LINE__.

Модули

Постепенное исключение препроцессора является долгосрочной целью в будущем C++ (consteval заменяет макрофункции, source_location заменяет один из наиболее часто используемых макросов). Модули — новый способ разделения исходного кода, который в конечном счёте призван заменить всю систему #include.

Пока одни разработчики говорят, что давно пора внести такие изменения, другие относятся к добавлению модулей достаточно критично​. Некоторые разработчики заявили о своей обеспокоенности по поводу их текущего состояния. Каково бы ни было ваше собственное мнение, можно с уверенностью сказать, что это серьёзное изменение всей сущности языка и в то же время достаточно сложное мероприятие, которое не произойдёт быстро. Если вы хотите познакомиться с модулями поближе, GCC и Clang уже в некоторой степени их поддерживают.

Многое другое

Это только малая часть всего списка, например Coroutines — ещё одна важная функция, которая будет добавлена в C++ 20. Но чтобы описать все изменения, потребуется ещё хотя бы одна статья. Поэтому просто перечислим их:

• новая библиотека синхронизации;
• кооперативное прерывание потоков;
• оператор <=> для трёхсторонних сравнений;
• using enum для уменьшения шума от разделении пространств имен;
• пакет дополнений к лямбда-выражениям;
• частичный отказ от volatile (части языка, важные для volatile, не изменятся).

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

В статье описаны трудности реализации правильного полифилла globalThis. Для него существуют следующие требования:

• должен работать в любой среде JavaScript, включая браузеры, воркеры и расширения браузеров. А также в Node.js, Deno и standalone бинарных файлах на движке JavaScript;
• должен поддерживать грязный и строгий (strict) режимы работы, а также модули JavaScript;
• должен работать независимо от контекста, в котором запущен код (т. е. полифилл должен выдавать правильный результат, даже если его на этапе сборки обернут упаковщиком в строгий режим работы).

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

TL;DR globalThis != глобальный объект, но globalThis == this из глобальной области видимости.

Альтернативы globalThis

Так сложилось, что для доступа к глобальному объекту в разных средах JavaScript требуется разный синтаксис. Например, в веб-среде можно использовать window, self или frames, при этом для веб-воркеров (и сервис-воркеров) работать будет только self.

Node.js не работает со всем вышеперечисленным, в его случае нужно использовать global.

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

Проблема выше решается использованием Function(‘return this’)(), но в средах с отключенной функцией eval() вроде CSP нельзя использовать Function подобным образом.

Примечание setTimeout(‘globalThis = this’, 0) не следует использовать по тем же причинам, что и eval() и Function. Кроме того, функция setTimeout не является частью ECMAScript, а следовательно, не будет доступна во всех средах выполнения JavaScript. Вдобавок к этому, setTimeout асинхронна, и даже если бы она везде поддерживалась, использовать её в полифилле, от которого зависит другой код, было бы неразумно.

Примитивный полифилл

Похоже, вышеперечисленные методы можно было бы объединить в один полифилл, как например этот:

Но, к сожалению, такой полифилл не будет работать в функциях во время исполнения кода в строгом режиме, в модулях JavaScript и в небраузерных средах (кроме поддерживающих GlobalThis).

Надёжный полифилл

А можно ли вообще написать надёжный полифилл globalThis? Возьмём в качестве примера среду, в которой:

1. Нельзя полагаться на значение globalThis, window, self, global или this.
2. Нельзя использовать конструктор Function или eval().
3. Можно полагаться на целостность остальной встроенной функциональности JavaScript.

В таком случае есть решение, но оно не идеально.

Если установить значение функции на globalThis и вызвать его как метод, то можно получить доступ к this используя следующую функцию:

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

Функция foo() больше не является методом, а поэтому в строгом режиме или в модулях JavaScript у ключевого слова this будет значение undefined. Однако, это не относится к геттерам и сеттерам.

Скрипт выше устанавливает геттер на полифилл globalThis, получает к нему доступ, чтобы в итоге ссылаться на globalThis, затем очищает полифилл, удаляя геттер. Таким образом у нас появляется доступ к globalThis при любых обстоятельствах, но этот метод опирается на глобальный this в первой строке (где написано globalThis). Можно ли как-то избавиться от этой зависимости? Как можно установить глобально доступный геттер без прямого доступа к globalThis?

Вместо установки геттера на globalThis, нужно установить его на то, что глобально наследует объект — Object.prototype.

Примечание В спецификации ECMAScript не указано, что глобальное this наследует именно Object.prototype — только указано, что это строго должен быть объект. Функция Object.create(null) создаёт объект, который не наследуется от Object.prototype. Движок JavaScript мог бы использовать такой объект как глобальное this, не нарушая требования спецификации, но в этом случае фрагмент кода выше всё равно не сработал бы. Однако, в современных движках разработчики, похоже, согласны с тем, что глобальное this должно включать Object.prototype в своей цепочке прототипов.

Во избежание проблем с Object.prototype в современных средах JavaScript, где полифилл globalThis уже доступен, изменим его следующим образом

Или можно использовать __defineGetter__ :

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

Не стоит играться с встроенными прототипами вообще — это объясняется в JavaScript Engine Fundamentals: optimizing prototypes.

С другой стороны, единственный способ сломать этот полифилл — изменить object, Object.defineProperty (или Object.prototype._ _defineGetter) перед его запуском.

Тестирование полифилла

Этот полифилл — интересный пример универсального JavaScript: чистый и независимый код, который не полагается на какие-либо встроенные компоненты той или иной среды выполнения, поэтому работает везде, где работает ECMAScript. Итак, одна цель достигнута, теперь посмотрим, как он будет работать.

Обратите внимание на пример HTML-страницы для полифилла, который журналирует globalThis, используя классический скрипт globalThis вместе с globalThis.mjs (с одинаковым исходным кодом). Этот пример может быть использован для проверки работы полифилла в браузерах. globalThis нативно поддерживается в Chrome 71, Firefox 65, Safari 12.1 (+iOS Safari 12.2). Чтобы протестировать нужные части полифилла, откройте демо-страницу в старых версиях браузеров.

Примечание Полифилл не поддерживается в Internet Explorer 10 и старше. В этих браузерах строка __magic__.globalThis = __magic__ по каким-то причинам не делает globalThis доступным глобально, несмотря на то, что __magic__ служит рабочей ссылкой на глобальное this. В итоге выясняется, что __magic__ !== window, хотя оба относятся к [object Window], что как бы намекает, что браузеры могут запутаться в определении глобального объекта и глобального this. Внесение правок в полифилл для отката к одной из альтернатив позволяет ему работать в IE 10 и 9. Для поддержки в IE 8 нужно обернуть Object.defineProperty в try-catch, подобным образом откатившись в блок catch (это также поможет избежать проблемы в IE 7 с глобальным кодом, который не наследуется от Object.Prototype). Попробуйте поиграть с демо-версией, поддерживающей старые версии IE.

Для тестирования полифилла в Node.js и отдельных движках JavaScript скачайте те же самые файлы с расширением .js/.mjs.

Теперь можно тестировать в Node.js.

Для тестирования полифилла в отдельной оболочке JavaScript-движка используйте jsvu для установки любого желаемого движка, а затем запустите скрипты напрямую. Например, протестируем в V8, v7.0 (без поддержки globalThis) и v7.1 (с поддержкой globalThis):

Таким же образом можно тестировать JavaScriptCore, SpiderMonkey, Chakra и другие JavaScript-движки. Ниже приведён пример использования JavaScriptCore:

Заключение

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

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

Ключевые выводы
— Оператор import ищет модули по списку путей в sys.path, который включает директорию запущенного скрипта
— Импортирование пакета равноценно выполнению его файла __init__.py
— В Python 3 все папки считаются пакетами (неявные пакеты пространств имён), файл __init__.py больше не обязателен
— Абсолютные импорты предпочтительнее относительных — они понятнее и работают одинаково при любом способе запуска

Содержание

• Ключевые моменты
• Основные определения
• Пример структуры директорий
• Что делает import
• Основы import и sys.path
• Чуть подробнее о sys.path
• Всё о __init__.py
• Использование объектов из импортированного модуля или пакета
• Используем dir() для исследования содержимого импортированного модуля
• Импортирование пакетов
• Абсолютный и относительный импорт
• Примеры
• Python 2 vs Python 3
• Прочие темы, не рассмотренные здесь, но достойные упоминания

Ключевые моменты

• Выражения import производят поиск по списку путей в sys.path.
• sys.path всегда включает в себя путь скрипта, запущенного из командной строки, и не зависит от текущей рабочей директории.
• Импортирование пакета по сути равноценно импортированию __init__.py этого пакета.

Основные определения

• Модуль: любой файл *.py. Имя модуля — имя этого файла.
• Встроенный модуль: «модуль», который был написан на Си, скомпилирован и встроен в интерпретатор Python, и потому не имеет файла *.py.
• Пакет: любая папка, которая содержит файл __init__.py. Имя пакета — имя папки.С версии Python 3.3 любая папка (даже без __init__.py) считается пакетом.
• Объект: в Python почти всё является объектом — функции, классы, переменные и т. д.

Пример структуры директорий

Обратите внимание, что в корневой папке test/ нет файла __init__.py.

Что делает import

При импорте модуля Python выполняет весь код в нём. При импорте пакета Python выполняет код в файле пакета __init__.py, если такой имеется. Все объекты, определённые в модуле или __init__.py, становятся доступны импортирующему.

Основы import и sys.path

Вот как оператор import производит поиск нужного модуля или пакета согласно документации Python:

При импорте модуля

интерпретатор сначала ищёт встроенный модуль с таким именем. Если такого модуля нет, то идёт поиск файла spam.py

в списке директорий, определённых в переменной sys.path .

sys.path инициализируется из следующих мест:

• директории, содержащей исходный скрипт (или текущей директории, если файл не указан);
• директории по умолчанию, которая зависит от дистрибутива Python;
• PYTHONPATH (список имён директорий; имеет синтаксис, аналогичный переменной окружения PATH).

Программы могут изменять переменную sys.path

после её инициализации. Директория, содержащая запускаемый скрипт, помещается в начало поиска перед путём к стандартной библиотеке. Это значит, что скрипты в этой директории будут импортированы вместо модулей с такими же именами в стандартной библиотеке.

Источник: Python 2 и Python 3

Технически документация не совсем полна. Интерпретатор будет искать не только файл (модуль) spam.py, но и папку (пакет) spam.

Обратите внимание, что Python сначала производит поиск среди встроенных модулей — тех, которые встроены непосредственно в интерпретатор. Список встроенных модулей зависит от дистрибутива Python, а найти этот список можно в sys.builtin_module_names (Python 2 и Python 3). Обычно в дистрибутивах есть модули sys (всегда включён в дистрибутив), math, itertools, time и прочие.

В отличие от встроенных модулей, которые при поиске проверяются первыми, остальные (не встроенные) модули стандартной библиотеки проверяются после директории запущенного скрипта. Это приводит к сбивающему с толку поведению: возможно «заменить» некоторые, но не все модули стандартной библиотеки. Допустим, модуль math является встроенным модулем, а random — нет. Таким образом, import math в start.py импортирует модуль из стандартной библиотеки, а не наш файл math.py из той же директории. В то же время, import random в start.py импортирует наш файл random.py.

Кроме того, импорты в Python регистрозависимы: import Spam и import spam — разные вещи.

Функцию pkgutil.iter_modules() (Python 2 и Python 3) можно использовать, чтобы получить список всех модулей, которые можно импортировать из заданного пути:

Чуть подробнее о sys.path

Чтобы увидеть содержимое sys.path, запустите этот код:

Документация Python описывает sys.path так:

Список строк, указывающих пути для поиска модулей. Инициализируется из переменной окружения PYTHONPATH и директории по умолчанию, которая зависит от дистрибутива Python.При запуске программы после инициализации первым элементом этого списка, path[0], будет директория, содержащая скрипт, который был использован для вызова интерпретатора Python. Если директория скрипта недоступна (например, если интерпретатор был вызван в интерактивном режиме или скрипт считывается из стандартного ввода), то path[0] является пустой строкой. Из-за этого Python сначала ищет модули в текущей директории. Обратите внимание, что директория скрипта вставляется перед путями, взятыми из PYTHONPATH.Источник: Python 2 и Python 3

Документация к интерфейсу командной строки Python добавляет информацию о запуске скриптов из командной строки. В частности, при запуске python <script>.py.

Если имя скрипта ссылается непосредственно на Python-файл, то директория, содержащая этот файл, добавляется в начало sys.path, а файл выполняется как модуль main.Источник: Python 2 и Python 3

Итак, повторим порядок, согласно которому Python ищет импортируемые модули:

1. Модули стандартной библиотеки (например, math, os).
2. Модули или пакеты, указанные в sys.path:Если интерпретатор Python запущен в интерактивном режиме:sys.path[0] — пустая строка "". Это значит, что Python будет искать в текущей рабочей директории, из которой вы запустили интерпретатор. В Unix-системах эту директорию можно узнать с помощью команды pwd.Если мы запускаем скрипт командой python

Обратите внимание, что при запуске скрипта для sys.path важна не директория, в которой вы находитесь, а путь к самому скрипту. Например, если в командной строке мы находимся в test/folder и запускаем команду python ./packA/subA/subA1.py, то sys.path будет включать в себя test/packA/subA/, но не test/.

Кроме того, sys.path общий для всех импортируемых модулей. Допустим, мы вызвали python start.py. Пусть start.py импортирует packA.a1, а a1.py выводит на экран sys.path. В таком случае sys.path будет включать test/ (путь к start.py), но не test/packA (путь к a1.py). Это значит, что a1.py может вызвать import other, так как other.py находится в test/.

Всё о __init__.py

У файла __init__.py есть две функции:

1. Превратить папку со скриптами в импортируемый пакет модулей (до Python 3.3).
2. Выполнить код инициализации пакета.

Превращение папки со скриптами в импортируемый пакет модулей

Чтобы импортировать модуль (или пакет) из директории, которая находится не в директории нашего скрипта (или не в директории, из которой мы запускаем интерактивный интерпретатор), этот модуль должен быть в пакете.

Как было сказано ранее, любая директория, содержащая файл __init__.py, является пакетом. Например, при работе с Python 2.7 start.py может импортировать пакет packA, но не packB, так как в директории test/packB/ нет файла __init__.py.

Это не относится к Python 3.3 и выше благодаря появлению неявных пакетов пространств имён. Проще говоря, в Python 3.3+ все папки считаются пакетами, поэтому пустые файлы __init__.py больше не нужны.

Допустим, packB — пакет пространства имён, так как в нём нет __init__.py. Если запустить интерактивную оболочку Python 3.6 в директории test/, то мы увидим следующее:

Выполнение кода инициализации пакета

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

Рассмотрим следующий пример:

test/packA/a1.py

test/packA/__init__.py

test/start.py

Вывод после запуска python start.py:

Примечание Если a1.py вызовет import a2, и мы запустим python a1.py, то test/packA/__init__.py не будет вызван, несмотря на то, что a2 рода бы является частью пакета packA. Это связано с тем, что когда Python выполняет скрипт (в данном случае a1.py), содержащая его папка не считается пакетом.

Использование объектов из импортированного модуля или пакета

Есть 4 разных вида импортов:

1. import <пакет>
2. import <модуль>
3. from <пакет> import <модуль или подпакет или объект>
4. from <модуль> import <объект>

Пусть X — имя того, что идёт после import:

• Если X — имя модуля или пакета, то для того, чтобы использовать объекты, определённые в X, придётся писать X.объект.
• Если X — имя переменной, то её можно использовать напрямую.
• Если X — имя функции, то её можно вызвать с помощью X().

Опционально после любого выражения import X можно добавить as Y. Это переименует X в Y в пределах скрипта. Учтите, что имя X с этого момента становится недействительным. Частым примером такой конструкции является import numpy as np.

Аргументом для import может быть как одно имя, так и их список. Каждое из имён можно переименовать с помощью as. Например, следующее выражение будет действительно в start.py: import packA as pA, packA.a1, packA.subA.sa1 as sa1.

Пример: нужно в start.py импортировать функцию helloWorld() из sa1.py.

• Решение 1: from packA.subA.sa1 import helloWorld. Мы можем вызвать функцию напрямую по имени: x = helloWorld().
• Решение 2: from packA.subA import sa1 или то же самое import packA.subA.sa1 as sa1. Для использования функции нам нужно добавить перед её именем имя модуля: x = sa1.helloWorld(). Иногда такой подход предпочтительнее первого, так как становится ясно, из какого модуля взялась та или иная функция.
• Решение 3: import packA.subA.sa1. Для использования функции перед её именем нужно добавить полный путь: x = packA.subA.sa1.helloWorld().

Прим. перев. После переименования с помощью as новое имя нельзя использовать в качестве имени пакета или модуля для последующих импортов. Иными словами, команда вроде следующей недействительна: import packA as pA, pA.a1.

Используем dir() для исследования содержимого импортированного модуля

После импортирования модуля можно использовать функцию dir() для получения списка доступных в модуле имён. Допустим, мы импортируем sa1. Если в sa1.py есть функция helloWorld(), то dir(sa1) будет включать helloWorld:

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

Импортирование пакета по сути равноценно импортированию его __init__.py. Вот как Python на самом деле видит пакет:

После импорта становятся доступны только те объекты, что определены в __init__.py пакета. Поскольку в packB нет такого файла, от import packB (в Python 3.3.+) будет мало толку, так как никакие объекты из этого пакета не становятся доступны. Последующий вызов модуля packB.b1 приведёт к ошибке, так как он ещё не был импортирован.

Абсолютный и относительный импорт

При абсолютном импорте используется полный путь (от начала корневой папки проекта) к желаемому модулю.

При относительном импорте используется относительный путь (начиная с пути текущего модуля) к желаемому модулю. Есть два типа относительных импортов:

1. При явном импорте используется формат from .<модуль/пакет> import X, где символы точки . показывают, на сколько директорий «вверх» нужно подняться. Одна точка . показывает текущую директорию, две точки .. — на одну директорию выше и т. д.
2. Неявный относительный импорт пишется так, как если бы текущая директория была частью sys.path. Такой тип импортов поддерживается только в Python 2.

В документации Python об относительных импортах в Python 3 написано следующее:

Единственный приемлемый синтаксис для относительных импортов — from .[модуль] import [имя]. Все импорты, которые начинаются не с точки ., считаются абсолютными.Источник: What's New in Python 3.0

В качестве примера допустим, что мы запускаем start.py, который импортирует a1, который импортирует other, a2 и sa1. Тогда импорты в a1.py будут выглядеть следующим образом:

Абсолютные импорты:

Явные относительные импорты:

Неявные относительные импорты (не поддерживаются в Python 3):

Учтите, что в относительных импортах с помощью точек . можно дойти только до директории, содержащей запущенный из командной строки скрипт (не включительно). Таким образом, from .. import other не сработает в a1.py. В результате мы получим ошибку ValueError: attempted relative import beyond top-level package.

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

Имейте в виду, что относительные импорты основаны на имени текущего модуля. Так как имя главного модуля всегда "__main__", модули, которые должны использоваться как главный модуль приложения, должны всегда использовать абсолютные импорты.Источник: Python 2 и Python 3

Примеры

Пример 1: sys.path известен заранее

Если вы собираетесь вызывать только python start.py или python other.py, то прописать импорты всем модулям не составит труда. В данном случае sys.path всегда будет включать папку test/. Таким образом, все импорты можно писать относительно этой папки.

Пример: файлу в проекте test нужно импортировать функцию helloWorld() из sa1.py.

Решение: from packA.subA.sa1 import helloWorld (или любой другой эквивалентный синтаксис импорта).

Пример 2: sys.path мог измениться

Зачастую нам требуется как запускать скрипт напрямую из командной строки, так и импортировать его как модуль в другом скрипте. Как вы увидите далее, здесь могут возникнуть проблемы, особенно в Python 3.

Пример: пусть start.py нужно импортировать a2, которому нужно импортировать sa2. Предположим, что start.py всегда запускается напрямую, а не импортируется. Также мы хотим иметь возможность запускать a2 напрямую.

Звучит просто, не так ли? Нам всего лишь нужно выполнить два импорта: один в start.py и другой в a2.py.

Проблема: это один из тех случаев, когда sys.path меняется. Когда мы выполняем start.py, sys.path содержит test/, а при выполнении a2.py sys.path содержит test/packA/.

С импортом в start.py нет никаких проблем. Так как этот модуль всегда запускается напрямую, мы знаем, что при его выполнении в sys.path всегда будет test/. Тогда импортировать a2 можно просто с помощью import packA.a2.

С импортом в a2.py немного сложнее. Когда мы запускаем start.py напрямую, sys.path содержит test/, поэтому в a2.py импорт будет выглядеть как from packA.subA import sa2. Однако если запустить a2.py напрямую, то в sys.path уже будет test/packA/. Теперь импорт вызовет ошибку, так как packA не является папкой внутри test/packA/.

Вместо этого мы могли бы попробовать from subA import sa2. Это решает проблему при запуске a2.py напрямую, однако теперь создаёт проблему при запуске start.py. В Python 3 это приведёт к ошибке, потому что subA не находится в sys.path (в Python 2 это не вызовет проблемы из-за поддержки неявных относительных импортов).

Обобщим информацию:

Использование относительного импорта from .subA import sa2 будет иметь тот же эффект, что и from packA.subA import sa2.

Вряд ли для этой проблемы есть чистое решение, поэтому вот несколько обходных путей:

1. Использовать абсолютные импорты относительно директории test/ (т. е. средняя колонка в таблице выше). Это гарантирует, что запуск start.py напрямую всегда сработает. Чтобы запустить a2.py напрямую, запустите его как импортируемый модуль, а не как скрипт:

1. В консоли смените директорию на test/.
2. Запустите python -m packA.a2.

2. Использовать абсолютные импорты относительно директории test/ (средняя колонка в таблице). Это гарантирует, что запуск start.py напрямую всегда сработает. Чтобы запустить a2.py напрямую, можно изменить sys.path в a2.py, чтобы включить test/packA/ перед импортом sa2.

Примечание Обычно этот метод работает, однако в некоторых случаях переменная __file__ может быть неправильной. В таком случае нужно использовать встроенный пакет inspect. Подробнее в этом ответе на StackOverflow.

3. Использовать только Python 2 и неявные относительные импорты (последняя колонка в таблице).

4. Использовать абсолютные импорты относительно директории test/ и добавить её в переменную среды PYTHONPATH. Это решение не переносимо, поэтому лучше не использовать его. О том, как добавить директорию в PYTHONPATH, читайте в этом ответе.

Пример 3: sys.path мог измениться (вариант 2)

А вот ещё одна проблема посложнее. Допустим, модуль a2.py никогда не надо запускать напрямую, но он импортируется start.py и a1.py, которые запускаются напрямую.

В этом случае первое решение из примера выше не сработает. Тем не менее, всё ещё можно использовать остальные решения.

Пример 4: импорт из родительской директории

Если мы не изменяем PYTHONPATH и стараемся не изменять sys.path программно, то сталкиваемся со следующим основным ограничением импортов в Python: при запуске скрипта напрямую невозможно импортировать что-либо из его родительской директории.

Например, если бы нам пришлось запустить python sa1.py, то этот модуль не смог бы ничего импортировать из a1.py без вмешательства в PYTHONPATH или sys.path.

На первый взгляд может показаться, что относительные импорты (например from .. import a1) помогут решить эту проблему. Однако запускаемый скрипт (в данном случае sa1.py) считается «модулем верхнего уровня». Попытка импортировать что-либо из директории над этим скриптом приведёт к ошибке ValueError: attempted relative import beyond top-level package.

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

Python 2 vs Python 3

Мы разобрали основные отличия импортов в Python 2 и Python 3. Они ещё раз изложены здесь наряду с менее важными отличиями:

1. Python 2 поддерживает неявные относительные импорты, Python 3 — нет.
2. В Python 2, чтобы папка считалась пакетом и её можно было импортировать, она должна содержать файл __init__.py. С версии Python 3.3 благодаря введению неявных пакетов пространств имён все папки считаются пакетами вне зависимости от наличия __init__.py.
3. В Python 2 можно написать from <модуль> import * внутри функции, а в Python 3 — только на уровне модуля.

Ещё немного полезной информации по импортам

• Можно использовать переменную __all__ в __init__.py, чтобы указать, что будет импортировано выражением from <модуль> import *. Смотрите документацию для Python 2 и Python 3.
• Можно использовать if __name__ == '__main__' для проверки, был ли скрипт импортирован или запущен напрямую. Документация для Python 2 и Python 3.
• Можно установить проект в качестве пакета (в режиме разработчика) с помощью pip install -e <проект>, чтобы добавить корень проекта в sys.path. Подробнее в этом ответе на StackOverflow.
• from <модуль> import * не импортирует имена из модуля, которые начинаются с нижнего подчеркивания _. Подробнее читайте в документации Python 2 и Python 3.
• Смотрите также: типы данных в Python, словари Python, а также полное руководство по изучению Python.

Часто задаваемые вопросы

Чем отличается import от from ... import в Python?

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

Почему возникает ошибка ModuleNotFoundError при импорте?

Ошибка ModuleNotFoundError означает, что Python не нашёл указанный модуль ни в одном из путей sys.path. Чаще всего причина в том, что модуль не установлен (pip install), скрипт запущен из неправильной директории, или структура пакетов нарушена (нет __init__.py в Python 2).

Нужен ли файл __init__.py в Python 3?

Начиная с Python 3.3, файл __init__.py не обязателен для того, чтобы папка считалась пакетом (неявные пакеты пространств имён). Однако он по-прежнему полезен для выполнения кода инициализации, определения переменной __all__ и экспорта объектов на уровне пакета.

Как избежать циклических импортов в Python?

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

Ниже приведён пример асинхронного чтения файла на Node.js:

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

• Выполняется запрос в БД на некого пользователя Arfat. Нужно считать его поле profile_img_url и загрузить соответствующее изображение с сервера someServer.ru.
• После загрузки изображения необходимо его конвертировать, допустим из PNG в JPEG.
• В случае успешной конвертации нужно отправить письмо на почту пользователя.
• Это событие нужно занести в файл transformations.log и указать дату.

Обратите внимание на вложенность обратных вызовов и пирамиду из }) в конце. Подобные случаи принято называть Callback Hell или Pyramid of Doom. Вот основные недостатки:

• Такой код сложно читать.
• В таком коде сложно обрабатывать ошибки и одновременно сохранять его «качество».

Для решения этой проблемы в JavaScript были придуманы промисы (англ. promises). Теперь глубокую вложенность коллбэков можно заменить ключевым словом then:

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

• Всё ещё нужно работать с кучей .then.
• Вместо обычного try/catch нужно использовать .catch для обработки всех ошибок.
• Работа с несколькими промисами в цикле не всегда интуитивно понятна и местами сложна.

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

Предположим, что у вас есть цикл for, который выводит последовательность чисел от 0 до 10 со случайным интервалом (от 0 до n секунд). Используя промисы нужно изменить цикл так, чтобы числа выводились в строгой последовательности от 0 до 10. К примеру, если вывод нуля занимает 6 секунд, а единицы 2 секунды, то единица должна дождаться вывода нуля и только потом начать свой отсчёт (чтобы соблюдать последовательность).

Стоит ли говорить, что в решении этой задачи нельзя использовать конструкцию async/await либо .sort функцию? Решение будет в конце.

Async функции

Добавление async-функций в ES2017 (ES8) сделало работу с промисами легче.

• Важно отметить, что async-функции работают поверх промисов.
• Эти функции не являются принципиально другими концепциями.
• Async-функции были задуманы как альтернатива коду, использующему промисы.
• Используя конструкцию async/await, можно полностью избежать использование цепочек промисов.
• С помощью async-функций возможно организовать работу с асинхронным кодом в синхронном стиле.

Как видите, знание промисов всё же необходимо для понимания работы async/await.

Синтаксис

Синтаксис состоит из двух ключевых слов: async и await. Первое делает функцию асинхронной. Именно в таких функциях разрешается использование await. Использование await в любом другом случае вызовет ошибку.

Обратите внимание, что async вставляется в начале объявления функции, а в случае стрелочной функции — между знаком = и скобками.

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

Примечание Конструкторы класса и геттеры/сеттеры не могут быть асинхронными.

Семантика и правила выполнения

Async-функции похожи на обычные функции в JavaScript, за исключением нескольких вещей:

Async-функции всегда возвращают промисы

Функция fn возвращает строку 'hello'. Т. к. это асинхронная функция, значение строки обёртывается в промис (с помощью конструктора).

Код выше можно переписать и без использования async:

В таком случае, вместо async, код вручную возвращает промис.

Тело асинхронной функции всегда обёртывается в новый промис

Если возвращаемое значение является примитивом, async-функция возвращает это значение, обёрнутое в промис. Но если возвращаемое значение и есть объект промиса, его решение возвращается в новом промисе.

Что происходит, когда внутри асинхронной функции возникает какая-нибудь ошибка?

Если ошибка не будет обработана, foo() вернёт промис с реджектом. В таком случае вместо Promise.resolve вернётся Promise.reject, содержащий ошибку.

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

Асинхронные функции приостанавливаются при каждом await выражении

await сказывается на выражениях. Если выражение является промисом, то async-функция будет приостановлена до тех пор, пока промис не выполнится. Если же выражение не является промисом, то оно конвертируется в промис через Promise.resolve и потом завершается.

Как работает fn функция?

1. После вызова fn функции первая строка конвертируется из const a = await 9; в const a = await Promise.resolve(9);.
2. После использования await, выполнение функции приостанавливается, пока a не получит своё значение (в данном случае это 9).
3. delayAndGetRandom(1000) приостанавливает выполнение fn функции, пока не завершится сама (после 1 секунды). Это, фактически, можно назвать остановкой fn функции на 1 секунду.
4. Также delayAndGetRandom(1000) через resolve возвращает случайное значение, которое присваивается переменной b.
5. Случай с переменной c идентичен случаю переменной a. После этого опять происходит пауза на 1 секунду, но теперь delayAndGetRandom(1000) ничего не возвращает, т. к. этого не требуется.
6. Под конец эти значения считаются по формуле a + b * c. Результат обёртывается в промис с помощью Promise.resolve и возвращается функцией.

Примечание Если такие паузы напоминают вам генераторы в ES6, то на это есть свои причины.

Решение задачи

Вот решение задачи, поставленной в начале статьи, с использованием async/await.

В функции finishMyTask используется await для ожидания результатов таких операций, как queryDatabase, sendEmail, logTaskInFile и т. д. Если сравнить это решение с решением, использовавшим промисы, то вы обратите внимание на их сходство. Однако версия с async/await упрощает синтаксические сложности. В этом способе нет кучи коллбэков и цепочек .then/.catch.

Вот то решение с выводом чисел. Тут есть два способа:

С использованием async-функций решение поставленной задачи упрощается до безобразия:

Обработка ошибок

Как было сказано выше, необработанные ошибки обёртываются в неудачный (rejected) промис. Но в async-функциях всё ещё можно использовать конструкцию try-catch для синхронной обработки ошибок.

canRejectOrReturn() — это асинхронная функция, которая будет удачно завершатся с 'Число подошло', либо неудачно завершаться с Error('Простите, число больше, чем нужно.').

Поскольку в коде выше ожидается выполнение canRejectOrReturn, то его собственное неудачное завершение вызовет исполнение блока catch. Поэтому функция foo завершится либо с undefined (т. к. в блоке try ничего не возвращается), либо с 'Ошибка обработана'. Поэтому у этой функции не будет неудачного завершения, т. к. try-catch блок будет обрабатывать ошибку самой функции foo.

Вот другой пример:

Обратите внимание, что в коде выше из foo возвращается (без ожидания) canRejectOrReturn. foo завершится либо с 'число подошло', либо с реджектом Простите, число больше, чем нужно.‘). Блок catch никогда не будет исполняться.

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

Вот что получится, если использовать await и return разом:

В коде выше foo будет удачно завершаться и с 'число подошло', и с 'Ошибка обработана'. В таком коде реджектов не будет. Но в отличие от одного из примеров выше, foo завершится со значением canRejectOrReturn, а не с undefined.

Вы можете убедиться в этом сами, убрав строку return await canRejectOrReturn():

Популярные ошибки и подводные камни

Из-за сложных манипуляций с промисами и async/await концепциями вы можете встретиться с различными тонкостями, что может привести к ошибкам.

Не забывайте await

Частая ошибка заключается в том, что перед промисом забывается ключевое слово await:

Обратите внимание, здесь не используется ни await, ни return. Функция foo всегда будет завершаться с undefined (без задержки в 1 секунду). Тем не менее, промис будет выполняться. Если промис будет выдавать ошибку либо реджект, то будет вызываться UnhandledPromiseRejectionWarning.

async-функции в обратных вызовах

async-функции часто используются в .map или .filter в качестве коллбэков. Вот пример — допустим, существует функция fetchPublicReposCount(username), которая возвращает количество открытых репозиториев на GitHub. Есть 3 пользователя, чьи показатели нужно взять. Используется такой код:

И для того, чтобы получить количество репозиториев пользователей (['ArfatSalman', 'octocat', 'norvig']), код должен выглядеть как-то так:

Обратите внимание на слово await в обратном вызове функции .map. Можно было бы ожидать, что переменная counts будет содержать число — количество репозиториев. Но как было сказано ранее, все async-функции возвращают промисы. Следовательно, counts будет массивом промисов. .map вызывает анонимной коллбэк для каждого пользователя.

Слишком последовательное использование await

Допустим, есть такой код:

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

Если на обработку одного пользователя будет уходить 300 мс, то на всех пользователей уйдёт почти секунда. В этом случае затрачиваемое время будет линейно зависеть от количества пользователей. Поскольку получение количества репозиториев не зависит друг от друга, то можно распараллелить эти процессы. Тогда пользователи будут обрабатываться одновременно, а не последовательно. Для этого понадобятся .map и Promise.all.

Promise.all на входе получает массив промисов и возвращает промис. Возвращаемый промис завершается после окончания всех промисов в массиве либо при первом реджекте. Возможно, все эти промисы не запустятся строго одновременно. Чтобы добиться строгого параллелизма, взгляните на p-map. А если нужно, чтобы async-функции были более адаптивными, посмотрите на Async Iterators.

С 2011 года язык стал более динамичным и постоянно развивается. Не поймите неправильно, C++ — всё ещё один из самых сложных языков. Но с того времени он стал для программиста удобнее, чем в предыдущих версиях.

В статье мы рассмотрим некоторые интересные функциональные возможности языка.

Ключевое слово auto

Когда в 11 версии C++ только появилось auto, жизнь стала намного легче.

Идея auto состояла в том, чтобы заставить компилятор C++ определять тип ваших данных во время компиляции, вместо того чтобы заставлять вас каждый раз объявлять тип. Это было удобно, если у вас были типы данных вроде map<string, vector <pair <int, int>>> ?

Посмотрите на строку номер 5. Вы не можете объявить что-либо без инициализатора. Строка 5 не сообщает компилятору, каким может быть тип данных.

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

В строках 7 и 8 была использована инициализация в скобках. Эта функция также была добавлена в 11 версии C++.

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

Теперь встаёт хороший вопрос, что произойдёт, если мы напишем auto a = {1, 2, 3}? Это ошибка компиляции? Это вектор?

На самом деле, в 11 версии C++ был представлен std::initializer_list<type>. Инициализированный список в скобках будет считаться легковесным контейнером, если объявлен как auto.

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

Не забудьте проверить строку 25! Выражение auto [v1, v2] = itr.second — новая функция в 17 версии C++. Это называется структурным связыванием. В предыдущих версиях приходилось извлекать каждую переменную отдельно. Но структурное связывание сделало этот процесс более удобным.

Более того, если вы хотите получить данные, используя ссылку, то просто добавьте символ — auto &[v1, v2] = itr.second.

Лямбда-выражение

В 11 версии C++ появились лямбда-выражения. Это что-то вроде анонимных функций в JavaScript. Они являются безымянными функциональными объектами и захватывают переменные в различных областях на основе некоторого краткого синтаксиса. Они также могут быть присвоены переменным.

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

Приведённый выше пример может многое сказать.

Во-первых, обратите внимание, как фигурные скобки упрощают вам жизнь. Затем следуют универсальные begin(), end(), которые тоже были добавлены в 11 версии. После идёт лямбда-выражение в качестве компаратора ваших данных. Параметры лямбда-выражения объявлены с помощью auto, что было добавлено в 14 версии С++. До этого auto нельзя было использовать в качестве параметров функции.

Обратите внимание, мы начинаем лямбда-выражение с квадратных скобок [ ]. Они определяют область действия лямбды — сколько у неё полномочий над локальными переменными и объектами.

Как определено в этом потрясающем репозитории по современному C++:

• [ ] — ничего не захватывает. Таким образом, вы не можете использовать любую локальную переменную внешней области видимости в лямбда-выражении. Вы можете использовать только параметры.
• [=] — захватывает локальные объекты (локальные переменные, параметры) в области видимости по значению. Вы можете использовать, но не изменять их.
• [&] — захватывает локальные объекты (локальные переменные, параметры) в области видимости по ссылке. Вы можете изменить их, как в примере, приведённом ниже.
• [this] — захватывает этот указатель по значению.
• [a, &b] — захватывает объект a по значению, объект b по ссылке.

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

В приведённом выше примере, если вы захватили локальные переменные по значению ([factor]) в лямбда-выражении, то вы не можете изменить factor в 5 строке. Вы просто не имеете права делать это. Не злоупотребляйте своими правами!

Наконец, обратите внимание, что мы берём переменную val в качестве ссылки. Это гарантирует, что любое изменение внутри лямбда-функции фактически изменяет vector.

Инициализатор в if и switch

Вам точно понравится эта возможность в С++ 17.

Очевидно, теперь вы можете выполнять инициализацию переменных и проверять условие сразу внутри блоков if или switch. Это поможет сделать код лаконичным и чистым. Общая форма:

Компиляция и constexpr

Скажем, у вас есть какое-то выражение для оценки, и его значение не изменится после инициализации. Вы можете предварительно рассчитать значение, а затем использовать его в качестве макроса. Или, как предложил C++ 11, можно использовать constexpr.

Программисты стремятся максимально сократить время выполнения программ. Поэтому если некоторые операции можно отдать на выполнение компилятору, это стоит сделать.

Приведённый выше код — распространённый пример использования constexpr.

Поскольку мы объявили функцию вычисления Фибоначчи как constexpr, компилятор может предварительно вычислить fib(20) во время компиляции. Так что после неё он может заменить строку с

на

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

Переменные также могут быть constexpr. В этом случае, как вы можете догадаться, эти переменные должны вычисляться во время компиляции. Иначе вы получите ошибку компиляции.

Интересно, что позже в C++ 17 были представлены constexpr-if и constexpr-lambda.

Кортежи

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

Иногда удобнее использовать std::array вместо кортежа. Такой массив подобен обычному массиву в C вместе с несколькими функциями стандартной библиотеки C++. Эта структура данных была добавлена в 11 версии C++.

Вывод типов шаблонных параметров для классов

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

Прим. перев. В этом примере для первого элемента кортежа будет выведен тип const char *, а не std::string.

Выводимый тип задаётся неявно. Это становится ещё удобнее для кортежей.

Эта функция не имеет никакого смысла, если вы слабо знакомы с шаблонами в C++.

Умные указатели

Указатели могут быть адскими.

Из-за свободы, которую предоставляют такие языки, как C++, иногда становится очень легко выстрелить себе в ногу. И во многих случаях именно указатели ответственны за вред, нанесённый компьютеру.

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

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

Изначально свойство flex не подходит для обёртки элементов — его работа во многом схожа с работой overflow:hidden.

Первое, с чего стоит начать работу с flex, — это flex-wrap.

Flex Wrap

Добавьте свойство flex-wrap: wrap и посмотрите на поведение flex-элементов.

По умолчанию оно должно растягивать контейнер по высоте и спускать элементы вниз.

Примечание Высота не указана (auto/unset), но контейнер может растягиваться.

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

Направление элементов можно отзеркалить свойством flex-direction: row-reverse:

Возможно, такое свойство подойдёт для чтения справа налево. Ещё можно использовать float:right для всех элементов, которые находятся на одной линии с flex-end. Это свойство отличается от row-reverse, т. к. в нём сохраняется корректный порядок элементов.

Justify Content

Свойство justify-content определяет горизонтальное положение элементов. Это свойство похоже на Flex Wrap, но в justify сохраняется первоначальный порядок элементов.

В следующем примере (justify-content: center) все элементы вне зависимости от их ширины имеют горизонтальное позиционирование по центру родительского контейнера. Это похоже на свойства position: relative; margin: auto.

Значение space-between добавляет пробелы между всеми inner-элементами, тем самым растягивая строку на всю ширину контейнера:

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

Пример выше со значением space-between не имеет отступов на угловых элементах. Пример ниже со значением space-around делает равные внешние отступы на всех элементах.

Идентичный прошлому пример с растянутым элементом middle:

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

Align Content

Все примеры выше имели свойство justify-content. Но элементы также можно позиционировать по вертикали. Свойство justify-content (выше) и свойство align-content (ниже) похожи. Разница только в их направлении — вертикальном или горизонтальном.

Вот пример flex-элементов при вертикальном позиционировании:

У space-evenly есть несколько особенностей значения:

• Свойство выделяет достаточно высоты для корректного отображения элементов.
• Вертикальные отступы у строк одинаковы.

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

На практике

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

Комбинация vertical align и justify content

В этом случае контент будет отцентрирован во всех направлениях.

Space evenly

Используя значение space-evenly сразу для align-content и justify-content, можно получить следующий результат:

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

К тому же, если количество элементов будет чётным, то масштабирование будет более чистым и чувствительным без сеток на CSS и танцев с бубном на JS.

Центрирование элементов по вертикали внутри других элементов создаёт проблемы последние десять лет. Flex может их решить. Если использовать свойство space-evenly в двух направлениях, отступы будут появляться автоматически даже при разной высоте элемента:

Если вы посмотрите на flex в целом, то заметите, что это, наверное, самое полезное сочетание flex-свойств.

Размер элементов

Убедитесь, что вы явно указываете размер элементов. Если этого не сделать, некоторые свойства увеличения во flex попросту не будут работать. Используйте min-width, max-width, и width/height соответственно. Эти свойства могут кардинально повлиять на масштабируемость вашего контента.

Примеры комбинаций свойств в одной анимации

• flex-direction: row; justify-content: [value];

• flex-direction: column; justify-content: [value];

Хотя рекомендуется использовать flex внутри CSS-сеток, это совсем не обязательно. Flex хорош и сам по себе.

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

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

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

Что за проблему в Python решает GIL?

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

Вот небольшой пример кода, демонстрирующий работу переменных подсчёта ссылок:

В этом примере количество ссылок на пустой массив равно 3. На этот массив ссылаются: переменная a, переменная b и аргумент, переданный функции sys.getrefcount().

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

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

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

GIL — эта одиночный блокиратор самого интерпретатора Python. Он добавляет правило: любое выполнение байткода в Python требует блокировки интерпретатора. В таком случае можно исключить взаимоблокировку, т. к. GIL будет единственной блокировкой в приложении. К тому же его влияние на производительность процессора совсем не критично. Однако стоит помнить, что GIL уверенно делает любую программу однопоточной.

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

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

Почему для решения проблемы был выбран именно GIL?

Итак, почему же это не очень «хорошее» решение используется в Python? Насколько для разработчиков это решение критично?

По словам Larry Hastings, архитектурное решение GIL — это одна из тех вещей, которые сделали Python популярным.

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

Много расширений, в которых нуждался Python, было написано для уже существующих библиотек на C. Для предотвращения несогласованных изменений, язык C требовал потокобезопасного управления памятью, которое смог предоставить GIL.

GIL можно было легко реализовать и интегрировать в Python. Он увеличивал производительность однопоточных приложений, поскольку управление велось только одним блокиратором.

Те библиотеки на C, которые не были потокобезопасными, стало легче интегрировать. Эти расширения на C стали одной из причин, почему Python-сообщество стало расширяться.

Как можно понять, GIL — фактическое решение проблемы, с которой столкнулись разработчики CPython в начале жизни Python.

Влияние GIL на многопоточные приложения

Если смотреть на типичную программу (не обязательно написанную на Python) — есть разница, ограничена ли эта программа производительностью процессора или же I/O.

Операции, ограниченные производительностью процессора (англ. CPU-bound) — это все вычислительные операции: перемножение матриц, поиск, обработка изображений и т. д.

Операции, ограниченные производительностью I/O (англ. I/O-bound) — это те операции, которые часто находятся в ожидании чего-либо от источников ввода/вывода (пользователь, файл, БД, сеть). Такие программы и операции иногда могут ждать долгое время, пока не получат от источника то, что им нужно. Это связано с тем, что источник может проводить собственные (внутренние) операции, прежде чем он будет готов выдать результат. Например, пользователь может думать над тем, что именно ввести в поисковую строку или же какой запрос отправить в БД.

Ниже приведена простая CPU-bound программа, которая попросту ведёт обратный отсчёт:

Запустив это на 4х-ядерном компьютере получим такой результат:

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

И вот результат:

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

GIL не сильно влияет на производительность I/O-операций в многопоточных программах, т. к. в процессе ожидания от I/O блокировка распространяется по потокам.

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

Такое увеличение времени — это результат появления и реализации блокировки.

Почему GIL всё ещё используют?

Разработчики языка получили уйму жалоб касательно GIL. Но такой популярный язык как Python не может провести такое радикальное изменение, как удаление GIL, ведь это, естественно, повлечёт за собой кучу проблем несовместимости.

В прошлом разработчиками были предприняты попытки удаления GIL. Но все эти попытки разрушались существующими расширениями на C, которые плотно зависели от существующих GIL-решений. Естественно, есть и другие варианты, схожие с GIL. Однако они либо снижают производительность однопоточных и многопоточных I/O-приложений, либо попросту сложны в реализации. Вам бы не хотелось, чтобы в новых версиях ваша программа работала медленней, чем сейчас, ведь так?

Создатель Python, Guido van Rossum, в сентябре 2007 года высказался по поводу этого в статье «It isn’t Easy to remove the GIL»:

«Я был бы рад патчам в Py3k только в том случае, если бы производительность однопоточных приложений или многопоточных I/O-приложений не уменьшалась.»

С тех пор ни одна из предпринятых попыток не удовлетворяла это условие.

Почему GIL не был удалён в Python 3?

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

Но почему бы параллельно с обновлением Python 3 не удалить GIL?

Его удаление сделает однопоточность в Python 3 медленней по сравнению с Python 2 и просто представьте, во что это выльется. Нельзя не заметить преимущества однопоточности в GIL. Именно поэтому он всё ещё не удалён.

Но в Python 3 действительно появились улучшения для существующего GIL. До этого момента в статье рассказывалось о влиянии GIL на многопоточные программы, которые затрагивают только процессор или только I/O. А что насчёт тех программ, у которых часть потоков идут на процессор, а часть на I/O?

В таких программах I/O-потоки «страдают» из-за того, что у них нет доступа к GIL от процессорных потоков. Это связано со встроенным в Python механизмом, который принуждал потоки освобождать GIL после определённого интервала непрерывного использования. В случае, если никто другой не используют GIL, эти потоки могли продолжать работу.

Но тут есть одна проблема. Почти всегда GIL занимается процессорными потоками и остальные потоки не успевают занять место. Этот факт был изучен David Beazley, визуализацию этого можно увидеть здесь.

Проблема была решена в Python 3.2 в 2009 разработчиком Antoine Pitrou. Он добавил механизм подсчёта потоков, которые нуждаются в GIL. И если есть другие потоки, нуждающиеся в GIL, текущий поток не занимал бы их место.

Как справиться GIL?

Если GIL у вас вызывает проблемы, вот несколько решений, которые вы можете попробовать:

Многопроцессность против многопоточности. Довольно популярное решение, поскольку у каждого Python-процесса есть собственный интерпретатор с выделенной под него памятью, поэтому с GIL проблем не будет. В Python уже есть модуль multiprocessing, который упрощает создание процессов к такому виду:

После запуска получаем такой результат:

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

Альтернативные интерпретаторы Python. У Python есть много разных реализаций интерпретаторов. CPython, Jyton, IronPython и PyPy, написанные на C, Java, C# и Python соответственно. GIL существует только на оригинальном интерпретаторе — на CPython.

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

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

На этом этапе вы должны понимать все аспекты, необходимые при работе с GIL. Если же вам интересна низкоуровневая структура GIL — посмотрите  Understanding the Python GIL от David Beazley.

Принцип единственной ответственности (SRP)

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

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

Курс по теме From 0 to 1: Design Patterns — 24 That Matter.

Принцип открытости/закрытости (OCP)

Соответствует букве O акронима SOLID. Принцип можно выразить так: «Классы, методы или функции должны быть открыты для расширения (добавления новой функциональности) и закрыты для модификации». Такой подход запрещает кому-либо изменять уже опробованный и протестированный код, а значит, он не ломается. В этом и состоит основное преимущество такого подхода.

Ниже приведён пример кода на Java, который нарушает этот принцип:

А вот пример после рефакторинга. Теперь соблюдается принцип открытости/закрытости: при добавлении новой реализации Shape не нужно менять код GraphicEditor.

Курс по теме SOLID Principles of Object-Oriented Design and Architecture.

Принцип подстановки Барбары Лисков (LSP)

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

LSP тесно связан с принципом единственной ответственности и принципом разделения интерфейса.

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

Ниже приведён пример такого кода на Java:

Функция resize() провоцирует неявную ошибку при работе с экземпляром класса Square, потому что позволяет устанавливать отличные друг от друга значения ширины и высоты. Согласно принципу LSP, функции, использующие ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом. Поэтому для корректной работы функция resize() должна проверять, является ли передаваемый объект экземпляром класса Square, и в этом случае не позволять установить разные значения ширины и высоты. Отсюда идёт нарушение принципа.

Курс по теме SOLID Principles of Object-Oriented Design.

Принцип разделения интерфейса (ISP)

Соответствует букве I акронима SOLID. Этот принцип подразумевает, что интерфейс, который не используется, не должен быть реализован.

В основном это происходит, когда один интерфейс содержит несколько функциональностей, и клиенту нужна только одна из них, а другие — нет.

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

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

Принцип инверсии зависимостей (DIP)

Соответствует букве D акронима SOLID. Прелесть этого принципа проектирования в том, что любой класс легко тестируется с помощью фиктивного объекта и проще в обслуживании, потому что код создания объекта централизован, а клиентский код не перегружен им.

Ниже приведён пример кода Java, который нарушает принцип инверсии зависимости:

Пример демонстрирует, что AppManager зависит от EventLogWriter. Если вам нужно использовать другой способ уведомления клиента (например push-уведомления, SMS или электронную почту), необходимо изменить класс AppManager.

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

Курс по теме Using SOLID Principles to Write Better Code — A Crash Course.

Теперь перейдём к принципам, которые не входят в пятёрку SOLID, но не менее важны.

DRY (Don’t Repeat Yourself)

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

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

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

Курс по теме Basics of Software Architecture & Design Patterns для Java на Udemy.

Инкапсуляция изменяющегося кода

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

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

Воспользуйтесь алгоритмом, по которому переменные и методы по умолчанию имеют спецификатор private. Затем шаг за шагом увеличиваете доступ при необходимости (с private на protected, с protected на public).

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

Курс по теме Design Pattern Library.

Композиция вместо наследования

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

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

«Effective Java» Джошуа Блоха также советует отдавать предпочтение композиции вместо наследования. Если вы всё ещё не уверены, вы также можете посмотреть здесь, чтобы узнать, почему композиция лучше, чем наследование для повторного использования кода и его функциональности.

Курс по теме Object-Oriented Programming in Java.

Программирование для интерфейса

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

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

Имеется в виду

вместо

Это также рекомендовано во многих книгах по Java, в том числе в Effective Java и Head First design pattern.

Ниже приведён пример для интерфейса в Java:

Курс по теме  Refactoring to Design Patterns».

Принцип делегирования

Не делайте всё самостоятельно, делегируйте это в соответствующий класс. Классическим примером этого принципа являются методы equals() и hashCode() в Java. Если нужно сравнить два объекта, это действие поручается соответствующему классу вместо клиентского.

Основным преимуществом этого принципа является отсутствие дублирования кода и довольно простое изменение поведения. Этот принцип относится также к делегированию событий (событие делегируется соответствующему обработчику).

Курс по теме  5 Free Object-Oriented Programming Online Courses for Programmers.

Заключение

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

Курс по теме Шаблоны проектирования.

Google любит Kotlin: готова не только назвать его первым языком для Android-разработки, но и что-то сделать по этому поводу.

Кому подойдёт курс?

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

Чему научит?

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

Обучение рассчитано на два месяца. Но жёсткого расписания нет: уроки можно проходить в удобное время и в удобном темпе.

Примечание В этой статье не будут рассмотрены практические примеры применения ESP8266. Речь пойдёт об основных преимуществах и возможностях этого МК.

Содержание:

1. Разновидности МК серии ESP и их платХарактеристикиКак работать с микроконтроллером ESP8266?ПрошивкаВ чём прошивается?ОсновыРаспределение памяти

Микроконтроллер ESP8266 работает с внешней flash-памятью по интерфейсу SPI. Её объём варьируется от 512 Кбайт до 4 Мбайт. При желании и умении микросхему памяти можно будет перепаять на версию до 32 Мбайт.

Разновидности МК серии ESP и их плат

Существует около полутора десятка версий МК серии ESP и огромное количество плат с ними. Рассмотрим самые популярные из них.

Микроконтроллеры ESP8266

ESP-01

• Имеет 8 разведённых контактов (VCC, GND, UTXD, URXD, CH_PD, GPIO0, GPIO2, GPIO6) и PCB-антенну (печатный проводник на самой плате).
• Из разведённых выводов тут присутствуют только 3 GPIO, но не стоит видеть в этом одни минусы. Если нужно будет управлять одним реле или получать данные с датчика температуры, вам не понадобятся все выводы МК, достаточно будет лишь пары. К тому же, существуют платы и шилды с возможностью простой коммутации именно к этой версии МК. Например такая:

ESP-03

• Здесь появляется керамическая антенна. Она считается немного эффективней своего печатного собрата.
• Также на плате разведены все доступные выводы GPIO. В этой статье описана разница между типами антенн для микроконтроллеров ESP8266.

ESP-07

• В этой версии в глаза сразу бросается металлический экран (который перед этим появляется на ESP-06).
• На борту керамическая антенна и разъём для внешней антенны.

ESP-12

В свою очередь, существует несколько вариантов этой версии: ESP-12S, ESP-12F, ESP-12E. Вторая и третья версии имеют на торце дополнительно 6 разведённых контактов.

Платы

WeMos D1 mini

• Имеет распайку девяти GPIO-контактов.
• На плате имеется небезызвестный мост CH34x (такие часто ставят на клоны Arduino).
• Установлен МК с 4 Мбайт flash-памяти.
• Недостаток для некоторых — придётся самому паять контакты на плату (идут в комплекте).
• Конструкционно совместима с различными выпускаемыми шилдами реле/датчиками.

NodeMCU v0.9/v1

Первое поколение плат серии NodeMCU. На ней распаяны все 11 GPIO-портов. Некоторые из них обладают дополнительными функциями (UART, I2C, SPI, PWM, ADC). Хотя на плате впаяны контакты, она занимает всю ширину беспаечной макетной платы, что затрудняет работу на ней. МК имеет 4 Мбайт flash-памяти. Также имеется мост CH340.

NodeMCU v3

Финальная версия платы этой серии. Существует и v2 «Amica», которая меньше по габаритам. v3 носит название «LoLin» и отличается от предыдущей версии только размерами и незначительными деталями (например дополнительной распайкой шины питания). Кроме традиционного моста CH340/CH341 на платы ставят чип CP2102, так что внимательней с выбором драйвера на них.

Характеристики

Все эти (и не только эти) платы выполнены на чипсете микроконтроллера ESP8266EX, а следовательно, характеристики у них одинаковые:

• Протоколы: 802.11 b/g/n/e/i.
• Диапазон частот: 2.4 ГГц – 2.5 ГГц.
• Процессорное ядро: Tensilica L106 32 разряда.
• Диапазон напряжений питания: 2.5 В – 3.6 В.
• Среднее потребление тока: 80 мA.
• Режимы WiFi: Station/SoftAP/SoftAP+Station.
• Безопасность: WPA/WPA2.
• Шифрование: WEP/TKIP/AES.
• Обновление прошивки: через UART, по радиоканалу (OTA — Over The Air).
• Сетевые протоколы: IPv4, TCP/UDP/HTTP/FTP.
• Поддержка WiFi Direct (P2P), P2P Discovery, P2P GO (Group Owner) mode, GC (Group Client) mode, P2P Power Management.
• Встроенные аппаратные ускорители: CCMP (CBC-MAC, режим счётчика), TKIP (MIC, RC4), WAPI (SMS4), WEP (RC4), CRC.
• Поддержка LUA-скриптов.

Как работать с микроконтроллером ESP8266?

Есть два способа работы с ним:

• управление через AT-команды и автономная работа со своей прошивкой. В первом случае ESP8266 работает только в паре с другими МК, во втором — может работать независимо (хотя никто не запрещает присоединить её к другому МК).
• «Из коробки» МК поставляется с прошивкой для работы через AT-команды. Для этого ESP8266 подключается к любому другому МК по UART-интерфейсу. Для демонстрации работы AT-команд ESP8266 можно подключить к компьютеру через USB-UART переходник и запустить монитор последовательного порта (например из Arduino IDE). Про то, как работать с этими командами, можно прочитать в этой статье.

Прошивка

В большинстве случаев намного удобней прошивать МК и работать с ним со своей прошивкой. Однако тут тоже есть свои нюансы. Вот 3 варианта событий:

• У вас «голый» ESP8266, например ESP-01. Вам потребуется USB-UART переходник, который нужно подключить к МК. Этот переходник обязательно должен быть на 3-вольтовой логике, т. к. иначе можно легко отправить ваш МК в кибер-Вальхаллу. Про процесс подключения можно прочитать здесь.
• Второй случай идентичен первому, кроме того, что вместо переходника можно использовать любую плату Arduino. Достаточно специальным образом подключить ESP8266 к UART-контактам Arduino, а её саму «отключить», замкнув контакт аппаратного сброса (RESET) на землю. Естественно, питать ESP8266 нужно будет от шины питания 3.3 В. В этом случае в качестве переходника USB-UART будет выступать мост (чаще всего CH340) на самой плате Arduino. Этот процесс также описан в статье выше.
• Лучший вариант — это плата с USB-UART мостом на борту (как NodeMCU, WeMos и прочие). В этом случае ничего дополнительного делать не нужно — просто подключайте плату через USB.

В чём прошивается?

Например NodeMCU Flasher (которая подходит не только для плат NodeMCU) или ESPTool (необходим Python).

Однако в этой статье работа с МК и процесс прошивки будут рассмотрены в Arduino IDE.

Изначально среда Arduino IDE не предназначена для работы с МК серии ESP. Чтобы это исправить, идём в Файл → Настройки и в поле Дополнительные ссылки для Менеджера плат вставляем эту ссылку:

Потом открываем Инструменты → Плата → Менеджер плат и в открывшемся списке в самом низу находим плату «esp8266 by ESP8266 Community» (если с этим возникли трудности — используем поиск вверху окна). Устанавливаем последнюю версию платы (около 150 Мбайт).

После установки в списке плат появится немалое количество плат. Если не нашли свою плату или не знаете её названия — выбирайте Generic ESP8266 Module. Теперь можно выбрать свой МК в списке COM-портов.

У ESP8266 две скорости передачи: основная — её вы указываете при инициализации последовательного порта, и скорость, на которой передаётся отладочная информация. Она передаётся сразу после подачи питания на МК. Обычно это скорости 115200 бод и 74800 бод 0 соответственно.

Основы

Если вы не владеете базовыми знаниями работы с платформой Arduino, наверстать упущенное можно в нашей статье про основы использования Arduino.

После скачивания платы ESP8266 с помощью менеджера, в примерах появится большое количество скетчей. Рассмотрим один из них (Файл → Примеры → ESP8266WebServer → HelloServer):

Что делает этот скетч? МК подключается к вашей WiFi-сети и запускает сервер. В монитор последовательного порта выведется локальный IP-адрес (к примеру, 192.168.0.105). Вбиваем этот IP в адресную строку браузера, после чего в нём должна отобразиться строка «Привет от ESP8266!». Таким же образом можно проверить адрес /inline.

Ознакомиться с API МК можно в их официальном репозитории.

Распределение памяти

Внешняя память распределена на следующие разделы:

• скетчи (память для прошивки);
• файловая система SPIFFS;
• OTA-Update (прошивка, переданная «по воздуху»);
• EEPROM (да-да, её у МК тоже нет, поэтому она имитируется на flash-памяти);
• конфигурация WiFi.

Файловая система SPIFFS

Один из плюсов внешней flash-памяти — файловая система. В неё можно с лёгкостью записать файлы (веб-странички, медиа-файлы и прочее) на микроконтроллеры ESP8266. На аппаратном уровне это можно было бы реализовать подключив к МК модуль SD-карт. Однако это решение требует свободных портов.

Размер файловой системы (от 32 Кбайт до 15 Мбайт) зависит от самого объема flash-памяти и от конфигурации, выставленной в Инстурменты → Flash size. Например, конфигурация 4M (2M SPIFFS) предназначена для МК с общим объёмом flash-памяти 4 Мбайт, 2 Мбайт из которых будут выделены под файловую систему.

SPIFFS не работает с папками — она содержит только список файлов. Соответственно, если загрузить в неё папку style, в которой будет файл header.css, то в файловую систему систему запишется файл с именем /style/header.css. Об этом стоит помнить, потому что длина файлового имени не должна превышать 31 символ (читается 32, но символ с кодом 0 отведён под завершение строки).

Для загрузки файлов потребуется инструмент ESP8266FS, интегрирующийся в Arduino IDE. Инструкция по установке:

1. Качаем инструмент по ссылке выше.
2. В папке Arduino IDE создайте папку tools (если её там ещё нет).
3. В папку tools распакуйте скачанный архив. Должно быть так:
   …/Arduino/tools/ESP8266FS/tool/esp8266fs.jar.
4. После запуска среды в папке скетча (Скетч → Показать папку скетча) нужно создать папку data. Её содержимое будет загружаться в файловую систему.
5. После кликаем в Инструменты → ESP8266 Sketch Data Upload, чтобы загрузить данные в файловую систему. После загрузки в панели статуса высветится «SPIFFS Image Uploaded». Перед процессом загрузки в файловую систему обратите внимание: если открыт монитор последовательного порта — закрываем его.

Как работать с SPIFFS и файлами в ней, можно узнать в этой статье.

Энергонезависимая память EEPROM

Работа с внешней памятью немного отличается от стандартной.

• Перед считыванием или записью данных нужно инициализировать EEPROM, указав при этом выделяемую под неё память (от 4 до 4096 байт) функцией EEPROM.begin(size).
• Привычная функция EEPROM.write(addr, value) записывает данные не на саму энергонезависимую память, а в оперативную.
• Чтобы внесённые данные записались в память, нужна функция EEPROM.commit() (или же EEPROM.end(), чтобы заодно очистить данные из оперативной памяти).
• Метод EEPROM.read(addr) возвращает байт из памяти по адресу.

Прошивка «по воздуху» OTA-Update

Для этого вам потребуется установленный Python.

В скетч нужно добавить файл: #include <ArduinoOTA.h>. Инициализируем и настраиваем OTA следующими строками:

После этого достаточно в метод loop() добавить строку: ArduinoOTA.handle().

Прошиваем МК по проводу. В случае успешной загрузки в списке портов появится новый хост с именем «esp8266-xxxxxx», где esp8266 — указанное выше имя хоста, а xxxxxx — локальный IP-адрес МК. Выбираем его.

Теперь микроконтроллер ESP8266 можно прошивать «по воздуху».

Присвоения примитивных и ссылочных типов

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

JavaScript всегда использует присвоение по значению. И это очень важно: когда присваиваемое значение является одним из 5 JavaScript’овых примитивов (Boolean, null, undefined, String и Number) — присваивается фактическое значение. Однако, когда присваиваемое значение является типом Array, Function или Object, присваивается ссылка на объект в памяти.

Например, в коде ниже переменной var2 присваивается значение var1. Т. к. var1 является примитивом (String), то переменной var2 присваивается строковое значение var1, и она может рассматриваться как отдельная (независимая) переменная. Соответственно, изменения var2 никак не отразятся на var1.

А теперь попробуем то же самое с типом Object.

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

Замыкания

Замыкания — важный паттерн для приватизации переменной. В примере ниже createGreeter возвращает анонимную функцию, которой доступна переданная переменная greeting со значением «Hello». После эта переменная будет доступна для sayHello.

Или же более «правдоподобный» пример. У вас может быть некая функция apiConnect(apiKey), которая возвращает некоторые методы с использованием API ключа. В таком случае этот ключ нужно передать только один раз.

Деструктуризация

Деструктуризация — это просто способ извлечения свойств из объектов.

Если вам нужно извлечь свойство, дав ему другое имя, — делайте так:

В следующем примере деструктуризация применяется для «чистой» передачи объекта person в функцию introduce. Иначе говоря, деструктуризация может использоваться для непосредственного извлечения передаваемых параметров. Для тех, кто разрабатывает на React, это может показаться знакомым.

Spread

Нельзя не сказать об этой концепции. Spread — это специальный оператор JavaScript, который позволяет расширять выражения в тех местах, где предусмотрено использование нескольких аргументов.

В следующем примере Math.max() не может принять массив arr, т. к. функции с таким аргументом не существует. Math.max() принимает числа отдельными аргументами. Оператор spread(три точки — ...) используется для извлечения отдельных элементов из массива.

Rest-параметры

Rest-параметры позволяют передавать произвольное количество аргументов, принимая их в виде массива.

Методы массивов

С помощью методов массива в JavaScript можно добиться крутых (а порой и элегантных) способов трансформации данных. На StackOverflow часто можно наткнуться на вопросы о том, как работать с массивом объектов.

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

map, filter, reduce

В методах map(), filter() и reduce() иногда можно запутаться. Они полезны для трансформации массива или возвращения его агрегатного значения.

• map(): возвращает массив, в котором каждый элемент изменяется с помощью переданной функции.const arr = [1, 2, 3, 4, 5, 6];const mapped = arr.map(el => el + 20);console.log(mapped);// [21, 22, 23, 24, 25, 26]
• filter(): возвращает массив с теми элементами, в которых переданная функция возвращает true.const arr = [1, 2, 3, 4, 5, 6];const filtered = arr.filter(el => el === 2 || el === 4);console.log(filtered);// [2, 4]
• reduce(): работа с элементами с сохранением промежуточного результата.const arr = [1, 2, 3, 4, 5, 6];const reduced = arr.reduce((total, current) => total + current);console.log(reduced);// 21

find, findIndex, indexOf

Эти методы очень похожи. Используйте их следующим образом:

• find(): возвращает первый элемент массива, удовлетворяющий определенному условию.const arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];const found = arr.find(el => el > 5);console.log(found);// 6Опять же, обратите внимание, что все числа после 5 удовлетворяют условию, но возвращаться будет только первое значение. Это полезно в случаях, когда вы используете break при первом совпадении.
• findIndex(): метод идентичен find(), но вместо возвращаемого значения здесь возвращается индекс первого подходящего элемента.const arr = ['Nick', 'Frank', 'Joe', 'Frank'];const foundIndex = arr.findIndex(el => el === 'Frank');console.log(foundIndex);// 1
• indexOf(): метод идентичен findIndex(), но вместо функции он принимает искомое значение. Используйте этот метод в тех случаях, когда вам не нужна функция для проверки элемента на совпадение.const arr = ['Nick', 'Frank', 'Joe', 'Frank'];const foundIndex = arr.indexOf('Frank');console.log(foundIndex);// 1

push, pop, shift, unshift

Вот отличные методы, которые позволяют добавлять или убирать элементы в массиве.

• push(): этот метод относительно простой. Он добавляет элемент в конец массива. Метод модифицирует массив и одновременно возвращает добавленный элемент.let arr = [1, 2, 3, 4];const pushed = arr.push(5);console.log(arr);// [1, 2, 3, 4, 5]console.log(pushed);// 5
• pop(): метод удаляет последний элемент массива. Как и в прошлом случае, метод изменяет массив и одновременно возвращает удалённый элемент.let arr = [1, 2, 3, 4];const popped = arr.pop();console.log(arr);// [1, 2, 3]console.log(popped);// 4
• shift(): этот метод удаляет первый элемент массива. Метод изменяет массив и возвращает удалённый элемент.let arr = [1, 2, 3, 4];const shifted = arr.shift();console.log(arr);// [2, 3, 4]console.log(shifted);// 1
• unshift(): добавляет один или несколько элементов в начало массива. Как и прошлые методы, он изменяет массив, но возвращает новую длину массива.let arr = [1, 2, 3, 4];const unshifted = arr.unshift(5, 6, 7);console.log(arr);// [5, 6, 7, 1, 2, 3, 4]console.log(unshifted);// 7

splice, slice

Эти методы либо изменяют, либо возвращают подмассив элементов.

• splice(): метод изменяет массив, удаляя или заменяя существующий элемент, и/или добавляет новый. Метод только изменяет массив. Код ниже можно объяснить так: в позиции 1 массива удалить 0 элементов и вставить b.let arr = ['a', 'c', 'd', 'e'];arr.splice(1, 0, 'b')
• slice(): возвращает подмассив элементов массива, начиная и заканчивая на определённой позиции. Если конечная позиция не указана, возвращается остаток массива. Важно понимать, что этот метод не модифицирует массив, а только возвращает подмассив.let arr = ['a', 'b', 'c', 'd', 'e'];const sliced = arr.slice(2, 4);console.log(sliced);// ['c', 'd']console.log(arr);// ['a', 'b', 'c', 'd', 'e']

sort

Метод сортирует массив, основываясь на функции, которая принимает первый и второй элемент. Этот метод изменяет сам массив. Если в массиве порядок элементов не был изменен, метод возвращает 0, если изменён — 1.

Генераторы

Не забываем и про них. Генератор определяет, какое значение будет возвращено при следующем вызове next().

А вот пример использования генератора для бесконечных значений:

Разница операторов сравнения (===) и (==)

Не стоит пренебрегать разницей этих операторов. Оператор (==) перед операцией сравнения будет выполнять преобразование типов, а (===) делать преобразования не будет.

Сравнение объектов

Частая ошибка у новичков в JavaScript — это неправильное сравнение объектов. Дело в том, что переменные объектов хранят  в памяти ссылку на объект, а не сам объект. Один из способов сравнения двух объектов — предварительное преобразование их в JSON строку. Однако у этого способа есть недостаток: не факт, что порядок в объекте сохранится. Более безопасный способ сравнения объектов — использование специальной библиотеки, которая сравнивает объекты на более глубоком уровне (к примеру isEqual от loadash)

Хоть следующие объекты кажутся одинаковыми, они ссылаются на разные объекты в памяти.

А вот в следующем примере сравнение возвращает true, потому что второй объект приравнивается к первому и они оба ссылаются на один объект.

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

Callback-функции

Многие избегают callback-функции (функции обратного вызова). А зря — ведь это довольно просто! В следующем примере console.log() будет передан в myFunc() в качестве callback-функции.

Промисы

Как только вы начнёте понимать работу callback’ов в JavaScript, возможно, совсем скоро вы окажетесь в «аду обратных вызовов». На помощь приходят промисы (англ. Promises). Оберните свою асинхронную логику в промисы: resolve — для успехов, reject — для фейлов. Используйте then для обработки успеха и catch — для обработки фейлов.

Async Await

Как только вы разберётесь в промисах, вам может понравиться async await — это«синтаксический сахар» поверх промисов. Ниже пример async функции с await и промисом.

Заключение

Если вы не знали ни об одной из этих 12 концепций — не стоит откладывать их изучение в долгий ящик. А если знали — практика лишней никогда не будет.