Блог компании maxilect

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

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

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

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

Эксперимент с передачей ТЗ

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

Отличный у нас получится проект, если мы будем следовать финишному ТЗ! (шутка).

Но давайте разбираться. Из истории постепенно исчезли подробности:

• Изначально говорилось, что пришелец прилетал и оставлял ТЗ. В итоговой версии оказалось, что он не посещал нас, а прилетит только в конце, чтобы посмотреть результат.

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

• Исказились детали: изменился состав сплава как по веществам, так и по их пропорции. Проценты в первоначальной истории превратились в граммы. 10 Кельвинов превратилось в -1000 градусов.

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

Поговорим о том, как вопросами восстановить первоначальную информацию.

Метамодель

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

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

• Неконкретные глаголы (править, получать, наплевать, любить, хватать, помнить, выходить). Это не просто объект, а какое-то продолжительное действие, которое каждый может воспринимать по-своему.

• Сравнительные обобщения (больше, меньше, ровнее, успешнее, свои, чужие, качественный). В основном это прилагательные. Критерии для сравнения человек выбирает в соответствии со своим жизненным опытом. Нам они неизвестны.

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

• Модальные операторы невозможности и необходимости (следует , должен, обязан, нельзя, нужно). В русском языке модальные операторы не выделяются, а вот в английском они есть (Must, Have).

• Сверхобобщения (все, постоянно, никто, всех). Это объединение всего в одну кучу, опять же на основе личного опыта человека.

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

• Неконкретные существительные. Возьмем стол. Он может быть разным - высоким или низким, разной формы и назначения. Задача уточнения - определить важнейшие для нас параметры стола, чтобы восстановить картинку, которая была в голове у человека. Вопросы: Кто/что именно? Какой конкретно? Чей?

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

• Сравнительные обобщения. Цель вопросов к такому обобщению - выяснить, с чем человек сравнивает, выявить более осязаемые критерии, приближенные к физическому миру. Вопросы: По отношению к чему? Насколько? В чем?

• Номинализации. Раскрывая существительные, не представленные в физическом мире, наша задача понять, что именно человек подразумевает. Что это был за процесс, как он взаимодействовал с другими объектами. Вопросы: Кто? Когда? Где? С кем? Как именно?

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

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

Как это работает на практике

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

Нам важно понять, насколько низкими? Для этого нам надо:

• Увидеть паттерны метамодели. Начинать лучше с наиболее общих.

• Придумать существенные вопросы, разобобщающие этот паттерн. Надо стараться не уйти в более крупное обобщение. Например, вопрос почему зачастую ведет как раз к обобщению. А что заставляет сделать именно так? - к разобобщению.

• Корректно задать этот вопрос.

Будьте экологичны

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

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

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

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

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

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

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

И удачи с практикой!

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

Автор статьи: Владимир Бушманов, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

В этой части статьи мы перейдем к самому интересному - будем разбирать музыкальный модуль Dizzy IV по винтиками и воспроизводить мелодию сначала на Windows, а потом и на Arduino Nano. За подробностями добро пожаловать под кат.

О чем идет речь, я подробно объяснял в первой части статьи.

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

Музыкальную тему для игры Dizzy 4 создавал David Whittaker - достаточно известный композитор музыки для игр (пруф: ссылка 1 и ссылка 2).

Мне не удалось точно установить, в каком музыкальном редакторе была сделана эта музыка. В 1987 году композитор в одном из интервью сообщал, что пишет музыку в софте, специально разработанном им самим, как сказано в заметке драйвере, на компьютере Tatung Einstein (тоже имевшем AY-3-8910) и передает ее по RS-232 в спектрум. Но игра была выпущена в 1989 году и способ создания музыки к тому времени мог поменяться. Из кода плеера видно, что в него заложена кроссплатформенность - в нем используется буфер для регистров звукогенератора. Вместо прямого доступа через порты ввода-вывода, значения для регистров звукогенератора сначала записываются в буфер в памяти, что кажется оверхедом. Данные из буфера в регистры переносятся в простом цикле. Процесс создания музыки на другой платформе, а также существование игры с той же музыкой для Amstrad CPC, объясняет наличие такого буфера.

Разбираем музыкальный модуль

Я извлек музыкальный модуль из tap-файла и подверг анализу в эмуляторе Unreal Speccy и в дизассемблере IDA Pro. Полный листинг модуля с моими комментариями можно найти тут.

Если вкратце, это модуль длиной 0x4000 (или 16384, ах, какие числа) байт. Он загружается по адресу 0xC000 и имеет две мелодии с адресами 0xC000 и 0xD300. Обе мелодии укомплектованы идентичным плеером, так что сначала идет код плеера, а сразу за ним располагаются данные позиций, паттерны и инструменты. Думаю, так поступали в большинстве случаев - один плеер на несколько мелодий делали редко, несмотря на возможную экономию.

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

Модуль состоит из следующих блоков (где это возможно, будет указан и адрес окончания блока):

• 0xC000 - 0xC01B - (init) - блок инициализации, здесь происходит установка начальной скорости, адресов позиций и инструментов.

• 0xC01C - 0xC032 - (play_loop) - главный цикл. В нем благодаря команде 'halt' осуществляется задержка в 20 мс, т.е. тело цикла выполняется 50 раз в секунду. Здесь же осуществляется управление мелодией и проверка, не нажали ли в данный момент клавишу пробел, чтобы выйти из плеера. Этот код нужен был, чтобы можно было прослушать мелодию без дополнительного кода, но в играх он был бесполезен, потому что там был свой код, выполняющийся по прерыванию каждые 20 мс и вызывающий код плеера, чтобы тот сменил состояние мелодии. Так мелодии можно было проигрывать в фоне, не блокируя выполнение кода игры.

• 0xC033 - (play_frame) - именно это место должно вызываться 50 раз в секунду, чтобы звучала мелодия. Здесь идет подсчет количества вызовов. Если оно превышает скорость, заданную автором композиции, происходит смена нот. В этих мелодиях скорость всегда постоянна, а переход к следующей ноте происходит каждое седьмое прерывание, т.е. скорость всех мелодий в модуле - 7. Современную музыку для AY-3-8912 стараются писать со скоростью 3, так можно уместить больше деталей. Очевидно, чем меньше число, задающее скорость, тем чаще происходит смена нот.

• 0xC043 - (init_next_note) - код вызывается при каждой смене нот.

• 0xC051 - (init_next_position) - если ноты в паттерне заканчивается, то надо перейти к следующей позиции или начать мелодию сначала.

• 0xC06C - (init_pattern) - код инициализации следующего паттерна.

• 0xC082 - (init_next_note_in_current_pattern) - большой кусок кода по инициализации следующей ноты в паттерне. Здесь четырежды вызывается подпрограмма init_note_in_channel, которая читает управляющие команды и высоту нот, которые надо проиграть из данных паттерна, и сохраняет эти данные в оперативной памяти. Замечу, что четвертый канал отсутствует в звукогенераторе. Очевидно, этот псевдо канал задумывался для специальных команд управления состоянием. Не ясно, почему эти команды нельзя было помещать в оставшиеся три канала, сэкономив память. Кстати, здесь широко используются индексные регистры ix и iy, которые выгодно отличали процессор Z80 от его прародителя Intel 8080. При должном использовании они являлись своего рода контекстом исполнения, эдакий this, если угодно. Использование iy также указывает, что плеер не старались сделать универсальным, потому что этот регистр использовался во встроенном бейсике и изменять его в прерываниях (а плеер мог вызываться и через прерывания) не рекомендовалось.

• 0xC0B4 - (manage_current_note) - если сменять ноты надо было не каждые 20 мс, а в соответствии с заданной скоростью, то текущие проигрываемые ноты нуждались в обслуживании постоянно. Этот код трижды вызывает подпрограмму manage_current_note_in_channel, обслуживающую инструменты, - по одному разу для каждого канала. Напомним, что инструменты могут динамически менять частоту ноты (сэмпл) или высоту тона ноты (орнамент).

• 0xC0F5 - 0xC1E2 - (manage_current_note_in_channel) - обслуживание инструмента для данной ноты в канале. Наряду с инструментом, здесь же обрабатываются и шумовые эффекты. По результатам вычисления нового состояния для инструментов в этой процедуре заполняется буфер регистров, который позже передается в регистры звукогенератора.

• 0xC1E3 - (ay_out) - перенос данных из буфера в регистры звукогенератора.

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

По адресу 0xC043 в регистр 'A' загружается значение 0x3A. Казалось бы, это бесполезное действие, потому что следующая команда уменьшает это значение на единицу. Почему бы сразу не загрузить в регистр 'A' значение 0x39?

Идея заключается в том, что команда по адресу 0xC048 записывает уменьшенное (и, кстати, защищенное от переполнения благодаря инструкции 'AND 3Fh') значение по адресу операнда первой команды (0xC043), прямо в код программы, так что в следующий раз команда 'LD A, ...' считает значение на единицу меньше, через раз - еще меньше и так далее. Другими словами, по адресу 0xC044 хранится счетчик, который уменьшается на единицу, каждый раз при выполнении данного кода.

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

Реализация на Windows

Я начал с того, что написал бОльшую часть кода сначала для Windows, чтобы было легче производить отладку. Борьбу с Arduino оставил на момент адаптации кода к аппаратным возможностям платы. Мою реализацию для Windows можно собрать самостоятельно (каталог win-implementation у меня на GitHub; понадобится компилятор от Visual Studio 2017) или запустить готовые сборки: мелодия 1, мелодия 2.

Пара комментариев о том, как все реализовано.

Чтобы не возникло потом проблем с переносом, я старался писать код, ориентируясь на восьмибитную природу микроконтроллеров ATMega. Поэтому он изобилует типами 'uint8_t' и 'uint16_t'.

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

• адрес начала данных мелодии (без учета плеера),

• адрес таблицы позиций,

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

В оригинальном спектруме звукогенератор AY-3-8912 производил сигналы прямоугольной формы, которые раньше мне казались грубоватыми. Изначально цели добиться аутентичного звучания передо мной не стояло, поэтому в первой версии я пробовал генерировать синусоидальные сигналы, вместо меандра. Оказалось, что вместе с прямоугольной формой сигнала ушли и все гармоники, из-за чего звук стал очень глухой. Так что от синусоидальной формы сигнала пришлось отказаться. Также в реализацию была добавлена таблица маппинга громкости. Напомню, что амплитуда выходного сигнала звукогенератора имеет 15 градаций. Энтузиасты, разрабатывающие эмуляторы AY-3-8912, установили, что зависимость между значением в регистре громкости и напряжением на выходе вовсе не линейная. Так появились таблицы для соответствующего преобразования. В больших эмуляторах такие таблицы 16-битные, в нашем же эмуляторе для быстроты расчетов используется 4 бита. Поэтому если заглянуть в исходники, можно увидеть, что уровни громкости от 0 до 3 вообще не воспроизводятся, а уровни от 4 до 9 имеют незначительную громкость на выходе. Действительно, субъективно я это почувствовал еще во время моих экспериментов по написанию музыки. Думаю, что инженеры, разрабатывающие звукогенератор, сделали это намеренно, в соответствии с законом Вебера-Фехнера (интенсивность ощущения пропорциональна логарифму интенсивности раздражителя).

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

Реализация на Arduino

Поскольку проект делался исключительно для веселья, я выбрал плату Arduino Nano. У нее широко распространенный микроконтроллер, но он менее всего подходит для решения этой задачи. Можно было бы выбрать, например STM32, но там есть даже ЦАП, поэтому было бы совсем неинтересно, тем более на STM32 удалось запустить эмуляцию ZX Spectrum, включая генерацию видеосигнала. Что уж говорить о Raspberry Pi и аналогах, ведь на них можно эмулировать спектрум, не написав ни строчки кода.

Генерация ШИМ сигнала обеспечивается TIMER2, вывод OC2B или PD3 (или вывод D3 в терминологии Arduino). Частота ШИМ сигнала выбрана достаточно высокой - 31373 Гц, поэтому выход Arduino удалось подключить напрямую к портативной колонке без каких-либо фильтрующих цепей, посторонние призвуки отсутствовали.

На плате Arduino Nano можно управлять только двумя светодиодами. Я сделал так, что интенсивность одного из них зависит от громкости мелодии. Для простоты реализации, ШИМ-сигнал для этого светодиода формируется из прерывания второго таймера. Это происходит достаточно часто, но до тех пор пока нет цели сэкономить процессорное время, можно оставить так. Другой светодиод управляется через преобразователь uart -> usb, тут удалось вывести на него индикацию канала шума.

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

Проект можно собрать из каталога arduino-sketch и послушать мелодии на своем Arduino или посмотреть получившийся результат на видео.

Как я уже писал, все исходники проекта можно найти на Github.

Автор статьи: Антон Дмитриевский, Максилект.

P.S. Когда-то мы с другом делали клон известной игры Color Lines (тогда было модно делать клоны именно этой игры, их тысячи) и там в дополнение к красивой графике у нас тоже была достойная, на мой взгляд, музыка. Представляю вашему вниманию интро для этой игры. А если возникнет желание послушать внутриигровую музыку, то придется запустить игру в эмуляторе - образ диска TR-DOS можно скачать здесь, после запуска необходимо нажать на пункт меню Выбор мелодии.

P.P.S. Выражаю благодарность всем авторам эмулятора Unreal Speccy, участникам проекта speccy.info.

P.P.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

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

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

7:00

Я - жаворонок, просыпаюсь вместе с солнцем часов в 6 или 7 утра.

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

10:00

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

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

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

10:15

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

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

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

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

13:00

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

14:00

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

Хотя больше всего я люблю решать технические задачи, в статусе тимлида я очень редко сижу и что-то программирую. Обычно весь день занимаюсь решением разного рода вопросов - от установки конкретных версий на тестовый стенд, до внедрения новых технологий. Это огромный спектр задач. К примеру, начали мы вводить testcontainers - подключили библиотеку. Локально у разработчиков все работает, а с GitLab возникли проблемы (когда мы пушим наш код в GitLab, он тоже гоняет тесты, и там они не заработали). Разработчик сам не смог решить проблему из-за отсутствия доступа к конфигурации GitLab, так что тут пришлось подключиться мне. У меня доступа тоже не было, но с помощью коллег вопрос решили. И такие задачи заполняют почти целый день.

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

17:00

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

19:00

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

22:00

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

Автор статьи: Андрей Буров, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Привет, Хабр! Вокруг меня сформировался позитивный информационный фон на тему обработки событий через Kafka Streams. Этот инструмент привлекает множеством видео-докладов и статей на Хабре, подробной документацией, понятным API и красивой архитектурой. Некоторые мои знакомые и коллеги разрабатывают с его помощью свои системы. Но что происходит с в реальной жизни, когда эти системы уходят в production?

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

Коротко о проекте

Внутренней командой вместе с партнерами мы работаем над биржой Ad Exchange, которая помогает перепродавать рекламный трафик. Специфику подобных инструментов мы уже когда-то описывали в статье на Хабре. По мере роста числа партнеров среди SSP и DSP, нагрузка на сервера биржи растет. А для повышения ценности самой биржи мы должны собирать с этого трафика развернутую аналитику. Тут-то мы и попытались применить Kafka Streams.

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

Статья не претендует на объективность и описывает только лишь наш опыт и проблемы, с которыми мы столкнулись, работая с этой технологией. Надеюсь, кому-то она поможет избежать ошибок при использовании Kafka Streams. А может быть даст повод посмотреть по сторонам.

Агрегаты

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

Вроде бы стандартный кейс для Kafka Streams: используем функции groupBy и aggregate и получаем нужный результат. Всё работает именно так, причем с отличной скоростью за счёт внутреннего кэша: несколько последовательных изменений по одному и тому же ключу сначала выполняются в кэше и только в определённые моменты отправляются в changelog-топик. Далее Kafka в фоне удаляет устаревшие дублирующиеся ключи через механизм log compaction. Что здесь может пойти не так?

Репартиционирование

Если ваш ключ группировки отличается от ключа, под которым изначально пришло событие, то Kafka Streams создаёт специальный repartition-топик, отправляет в него событие уже под новым ключом, а потом считывает его оттуда и только после этого проводит агрегацию и отправку в changelog-топик. В нашем примере вполне может быть, что событие "Показ рекламы" пришло с ключом в виде UUID. Почему нет? Если вам надо сделать группировку, например по трём другим ключам, то это будет три разных repartition-топика. На каждый топик будет одно дополнительное чтение и одна дополнительная запись в Kafka. Чувствуете, к чему я веду?

Предположим, на входе у вас 100 тысяч показов рекламы в секунду. В нашем примере вы создадите дополнительную нагрузку на брокер сообщений в размере +600 тысяч сообщений в секунду (300 на запись и 300 на чтение). И ведь не только на брокер. Для таких объёмов надо добавлять дополнительные сервера с сервисами Kafka Streams. Можете посчитать, во сколько тысяч долларов обойдется такое решение с учётом цен на железо.

Для читателей, не очень хорошо знакомых с механизмом репартиционирования, я поясню один момент. Это не баг или недоработка Kafka Streams. С учётом её идеологии и архитектуры это единственное возможное поведение - его нельзя просто взять и отключить. Когда у сообщения меняется ключ, этот новый ключ надо равномерно "размазать" по кластеру так, чтобы каждый инстанс Kafka Streams имел собственный набор ключей. Для этого и служат дополнительные запись/чтение в repartition-топик. При этом если инстанс А записал в топик сообщение, то не факт, что он же его и прочитает. Это может сделать инстанс Б, В и т.д. в зависимости от того, кто какую партицию читает. В итоге каждый ключ группировки у вас будет более-менее равномерно распределён по серверам кластера (если вы его хэшируете, конечно).

Запросы к агрегатам

Данные пишут для того, чтобы с ними потом можно было работать. Например делать к ним запросы. И здесь наши возможности оказались серьезно ограничены. Исчерпывающий список того, как мы можем запрашивать данные у Kafka Streams, есть здесь или здесь для оконных агрегатов. Если используется стандартная реализация state-store на основе RocksDB (а скорее всего это так), фактически данные можно получать только по ключам.

Предположу, что первое, что вам хочется сделать с полученными данными, - это фильтрация, сортировка и пагинация. Но здесь таких возможностей нет. Максимум, что вы можете, - это считать всё, что есть, используя метод all(), а потом вручную делать нужные операции. Вам повезет, если ключей не слишком много и данные уместятся в оперативной памяти. Нам не повезло. Пришлось писать дополнительный модуль, который по ночам выгружал данные из RocksDB и отправлял в Postgres.

Ещё надо помнить, что на каждом отдельно взятом сервисе находится только часть ключей. Что если вам необходимо отдавать ваши агрегаты, скажем, по HTTP? Вот кто-то сделал запрос к одному из сервисов Kafka Streams: мол, дай мне такие-то данные. Сервис смотрит у себя локально - данных нет. Или есть, но какая-то часть. Другая часть может быть на другом сервере. Или на всех. Что делать? Документация Kafka Streams говорит, что это наши проблемы.

Стабильность Kafka Streams

У нас бывают проблемы с хостинг провайдером. Иногда выходит из строя оборудование, иногда человеческий фактор, иногда и то, и другое. Если по какой-то причине теряется связь с Kafka, то Kafka Streams переводит все свои потоки в состояние DEAD и ждёт, когда мы проснёмся и сделаем ей рестарт. При этом рядом стоят соседние сервисы, которые работают с той же Kafka через Spring и @KafkaListener. Они восстанавливаются сами, как ни в чём не бывало.

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

Нам пришлось дописать в каждый сервис Kafka Streams дополнительный модуль, который работает как watchdog: поднимает Kafka Streams, если видит, что она умерла.

Кстати, если вы работаете с Kafka Streams через Spring, то не забудьте переопределить стандартный StreamsBuilderFactoryBean, указав в нём свой CleanupConfig. Иначе будете неприятно удивлены тем, что при каждом рестарте будет удаляться вся локальная база RocksDB. Напомню, что это приведёт к тому, что при каждом рестарте все сервера начнут активно считывать данные из changelog-топика. Поверьте, вам это не нужно.

KStream-KStream Join

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

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

Масштабируемость

Любой человек, знакомый с Kafka, скажет, что масштабируемость - одна из главных её преимуществ: "В чём проблема? Добавляем партиций и радуемся". Всё так. Но не для Kafka Streams.

Если вы используете джоины, то все ваши топики должны быть ко-партиционированы (co-partitioning), что, в числе прочего, означает, что у них должно быть одинаковое количество партиций. Так в чём же проблема?

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

На вопрос, что с этим делать, у меня сегодня ответа нет. Вероятно, можно потушить все рабочие инстансы Kafka Streams, потом поднять число партиций на всех причастных топиках, затем поднять Kafka Streams обратно и молиться. А может быть последовать совету отсюда: Matthias J. Sax пишет, что это нужно делать, создавая новый топик с новым количеством партиций и подключать к нему Kafka Streams с новым application.id. Там же есть совет, что если вы знаете заранее, что нагрузка будет большая, то лучше сделать партиций с запасом.

Заключение

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

Автор статьи: Андрей Буров, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

Под катом о том, как я переучивался и с какими трудностями эксплуатации столкнулся. Напоследок несколько выводов по итогам 7 лет эксплуатации.

В свое время я узнал о раскладке Дворака из подкаста Радио-Т.

Заинтересовавшись темой, я нашел видео у Sorax, где он в очень позитивном ключе отзывался об этой раскладке. Тогда я подумал: Я же программист! Моя работа и заключается в том, чтобы много печатать. И хотя скорость набора символов на английском языке у меня уже приближалась в среднем к 350 в минуту, решил поэкспериментировать. Тем более один из ведущих Радио-Т рассказывал, что пользуется Двораком наряду с QWERTY, переключаясь по необходимости, как мы переключаемся между английским и русским языками. Я предполагал действовать также - не терять QWERTY.

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

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

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

Для первой тренировки я использовал пакет dvorak7min. В нем 29 упражнений, которые учат правильно печатать и помогают запомнить, как буквы расположены по рядам. Благодаря этому консольному инструменту часа за четыре я освоил основные принципы. После этого все свои рабочие задачи выполнял уже в раскладке Дворака.

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

Два-три часа в день я тратил на тренажер, пока не заскучал с dvorak7min. А потом пошел на клавогонки (klavogonki.ru), чтобы следить за прогрессом. Выбрал специальный английский словарь и начал постепенно его проходить. Когда скорость подросла до 200 символов в минуту, я перешел на обычный английский словарь и еще месяц гонял на нем.

Честно скажу, первое впечатление было необычным. В раскладке Дворака гораздо больше работает правая рука. Я правша, но в первое время чувствовал, как именно правая устает на больших текстах. Спустя полтора месяца я подкачался и догнал свои 350 символов в минуту на английском языке, но уже в раскладке Дворака. Далее скорость удалось поднять еще немного - примерно до 400 символов в минуту.

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

Первые сложности и компромисс

Практика показала, что сменить раскладку, даже на довольно распространенную, не так-то просто.

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

Раскладка Дворака присутствует во всех основных ОС, но Дворака для программистов там по умолчанию нет. Устанавливать его на рабочее место в очередной аудитории запрещали доменные политики безопасности. В итоге вся вторая работа у меня проходила в QWERTY, что мешало эффективному переходу. Так мне пришлось пойти на первый компромисс - ограничиться использованием обычного Дворака, который можно было включить везде. Моя жизнь стала чуть легче, и в целом плюсы Дворака не исчезли. Но это был компромисс!

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

Мои выводы по итогам 7 лет использования Дворака

С Двораком руки действительно устают меньше

Раскладка Дворака действительно хорошо продумана.

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

Дворак усложняет взаимодействие с коллегами в офисе

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

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

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

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

Хотите Дворака? Забудьте о шорткатах

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

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

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

Хорошо, если нужная буква окажется под той же рукой. Но вообще говоря, это не гарантировано. Например, все привыкли, что в vim буквы hjkl используются как стрелки. Но в Двораке они расположены там, где в QWERTY-раскладке находятся буквы cv и jp. В итоге перемещение по тексту в редакторе осуществляется двумя руками. Левая рука отвечает за движение вниз-вверх, правая - влево-вправо.

На картинке выше (повторю ее тут для удобства) я отметил буквы, шорткаты с которыми перестают быть удобным для левой руки. Зеленые - неудобно, красные - совсем беда. Тут приходится либо использовать две руки, либо учиться нажимать правый Ctrl (Command).

Конечно, шорткаты можно перенастроить с помощью конфигурации используемых инструментов или ремапперов, вроде Karabiner Elements (для MAC). И я это делаю, но все не так просто.

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

Даже если ты все под себя настроил (или выучил стандартные шорткаты в новой раскладке), проблемы останутся.

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

Да, есть некоторые универсальные сочетания, но они работают не на всех ОС. Например, если бы я пользовался Windows или Ubuntu, я мог бы копировать и вставлять информацию через Ctrl / Shift + Ins, которые работали бы вне зависимости от включенной раскладки. Но в MAC этот универсальный способ не работает.

Лично я 90% времени нахожусь в английской раскладке, поэтому приучил себя пользоваться некоторыми функциями - в частности, упомянутыми копированием и вставкой информации - только в Двораке. Правда, из-за этого я теперь не могу пользоваться теми же шорткатами на чужом рабочем месте (Ctrl+C и Ctrl+V в QWERTY в других местах).

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

Я недавно купил себе MAC на новом чипе. Установил WebStorm, который JetBrains под него адаптировал. Но когда я нахожусь в раскладке Дворака, шорткаты у меня срабатывают дважды. Выполняется и команда, зарезервированная за буквой в QWERTY-раскладке, и команда на Двораке. Придется ждать фикса.

Видимо, какие-то такие проблемы будут преследовать поклонника Дворака всегда. Ты будешь бета-тестером новых инструментов для альтернативных раскладок.

На мой взгляд оно того не стоит

Для меня итогом этого многолетнего эксперимента фактически стала лишняя сотня символов в минуту на английском языке.

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

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

Вместо вывода

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

Следующим экспериментом по совершенствованию работы для меня стал vim. Вместе с пониманием, что скорость печати не так принципиальна, я осознал, что гораздо важнее, насколько безошибочно ты пишешь и в целом насколько эффективно ты используешь свои основные инструменты (ту же IDEA). Vim позволяет работать с кодом более продуктивно и выполнять объемные операции с текстом через макросы. В этом смысле он дает гораздо больший прирост производительности.

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

Автор: Сергей Широковских, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

Хотим поделиться с вами самыми интересными идеями (со ссылками на документацию, где подробно описано, как это работает).

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

Настройка экрана

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

• адаптация отображения под широкий монитор;

• непереносимость вкладок;

• режим максимального сосредоточения на коде.

Широкий монитор

Для тех, кто использует не два, а один широкий монитор, в IDEA предусмотрена настройка Widescreen tool window layout (ее легко найти в Preferences -> Appearance & Behavior -> Appearance -> Widescreen tool window layout).

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

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

Борьба с вкладками

IDEA позволяет изменить стандартное отображение вкладок с открытыми файлами. Скрыть вкладки в IDEA можно через Preferences -> Editor -> General -> Editor Tabs -> Tab placement -> None. Чтобы без вкладок перемещаться по файлам, по Ctrl+E (или Command+E на Mac) можно открыть список последних отредактированных. Также есть горячая клавиша для перемещения на один файл назад (Command + [).

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

Только код

Для тех, кому нужен более аскетичный вид кода, есть zen mode. Для перехода в этот режим нужно выбрать View -> Appearance -> Enter Zen Mode (инструкцию по переходу в Zen Mode можно найти в документации).

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

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

Организация всех проектов в одном окне

IntelliJ IDEA позволяет собрать все проекты, над которыми вы работаете, в одном окне (в одном списке Projects). Для этого необходимо создать в IDEA пустой проект и импортировать в него свои рабочие проекты через Git -> Clone. IDEA сама сложит все в дочерние папки.

Чтобы не плодить новых окон, на вопросе о том, где запустить проект, необходимо прервать мастер и выбрать File -> New module from existing source.Дальше достаточно открыть build.gradle.kts в проекте.

Проекты не перепутаются. Каждый из них будет смотреть на свой branch, а управлять ими можно будет через меню Git Branches.

Если модулей станет слишком много, их количество можно изменить в меню Load/Unload Modules. Unload позволяет временно выгрузить некоторые корневые модули из проекта.

IdeaVim

IdeaVim - не опция самой IDEA, а сторонний плагин, но его можно отнести к стандартным. Он добавляет горячие клавиши, которые облегчают перемещение по коду. Например, можно двигаться через 5 строк вниз или вверх, быстро искать нужный фрагмент текста. У IdeaVim есть отдельный буфер под сохраненные фрагменты текста, отличающийся от буфера ОС, а также много других полезных вещей.

Список команд можно найти в репозитории плагина.

Интеграция с YouTrack

Если команда использует YouTrack, IntelliJ IDEA можно интегрировать с этим с этим инструментом через плагин, который расширяет функционал стандартного таск-менеджера.

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

Интеграция настраивается в File -> Preferences -> Tools -> Tasks -> Servers. В разделе YouTrack можно указать все необходимые данные и правила поиска нужных тикетов. Правда, если имя тикета в YouTrack будет на русском, кириллическое название подтянется и в проект. Автоматическую подстановку имени задачи в название папки в этом случае можно отключить.

Множественные курсоры

IDEA поддерживает ввод множественными курсорами. Штука это не новая, но оказалось, что этим не все пользуются.

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

Например, из списка вроде такого:

aaabbbcccddd

можно сделать такой:

'aaa', 'bbb', 'ccc', 'ddd',

Это работает, даже если элементы списка имеют разную длину. Для этого при выделении можно использовать сочетание Ctrl + Shift + стрелку вправо. Это сочетание каждым из курсоров выделяет целое слово, вне зависимости от его длины. После этого Ctrl+C копирует в буфер обмена все выделенные слова. В результате из такого списка:

aaaaabbbbcccdddddd

Получаем готовый кусок кода:

aaaaa = params['aaaaa']bbbb = params['bbbb']ccc = params['ccc']dddddd = params['dddddd']

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

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

Статья написана по материалам внутреннего вебинара Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

Ссылка на первую часть статьи.

Scratch-файлы

Если нужно быстро что-то проверить или рассчитать, используя зависимости рабочего проекта, можно воспользоваться временными скретч-файлами IDEA. У них масса возможностей - посылать SQL-запросы, создавать временные JSON и т.п. Сюда же можно временно импортировать части проекта. Подробности в документации.

Shelve

IDEA Shelve по аналогии с git stash позволяет не смешивать контексты при переключении с одной задачи на другую.

Предположим, вы занимались одной задачей, но вынуждены были быстро перескочить на другую. В этом случае мы откладываем контекст текущей задачей (через New changelist -> Shelve change, чистим контекст), работаем над другой задачей, потом возвращаем отложенный контекст с помощью Unshelve (с сохранением всех старых переходов) и продолжаем работать над первой задачей. Подробно работа с shelve описана в документации к IDEA.

Кстати, IDEA многое отправляет в shelve автоматически.

Если собственный механизм IDEA почему-то не нравится, можно переключиться на git stash.

Закачка на удаленный хост

Следующая рекомендация для тех, кто любит все выполнять только в IDEA.

Командой Tools -> Deployment -> Browse Remote host можно активировать закладку Remote host. Здесь можно подключиться к удаленному хосту и перетаскиванием загружать на сервер файлы прямо из IDEA.

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

Интеграция с Docker

У IDEA есть интерфейс для работы с docker'ом. Здесь можно запускать контейнеры, просматривать логи, подключаться к контейнеру через терминал, расшаривать порты и т.д.

Changelist

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

Изменения можно перетаскивать из одного changelist-а в другой. Также changelist-ы можно разбивать или объединять.

Подробное описание работы с Changelist есть в документации.

Альтернативный механизм коммитов (при использовании Git) - Git staging. Но оба механизма сразу использовать нельзя. При переключении на Staging area собственные списки изменений IDEA (changelist-ы) будут удалены.

Дерево коммитов

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

В дереве коммитов есть поиск по commit message, имени задачи и хэшу коммита.

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

Дерево открывает широкие возможности для манипулирования коммитами. В частности, оно позволяет:

• откатывать коммит (Undo commit), после чего он попадает обратно в Change list;

• перетаскивать ветку с одного коммита на другой;

• сравнивать два разных коммита между собой.

Breakpoints

В процессе отладки IDEA позволяет устанавливать Breakpoint-ы. В этот момент можно, например, выводить информацию в лог.

Можно установить Breakpoint с условием (conditional breakpoints). Это удобно, когда точка остановки оказывается в цикле и нет желания 100 раз нажимать F9, пока не доберешься до нужной итерации. Вместо этого в настройках можно поставить условие - точку остановки делать только, если верно выражение:

В настройках можно также указать, что точка остановка должна сработать только один раз. Или она должна быть неактивна, пока мы не достигли определенной точки (Disable until hitting the following breakpoint).

А если поджимает время выполнения запроса, можно выбрать Evaluate and log. Выполнение не остановится, но данные будут выводиться в консоль.

Останавливаясь на breakpoint, можно воспользоваться кнопкой Evaluate Expression (горячая клавиша Alt + Shift + 8). Она открывает окно, в котором можно исполнять код прямо в рантайме в точке остановки, где будут доступны все зарезервированные объекты. Так можно модифицировать запросы из кода, проверяя быстрые гипотезы.

Evaluate Expression экономит много времени - не нужно перезапускать тесты и т.п.

Тестирование в IDEA

У тестирования непосредственно через IDEA есть одно важное преимущество. Если запускать тесты сторонним инструментом, в консоли появится индекс запускаемого теста. Если же тесты запускать через IDEA, она выведет названия тестов.

IDEA позволяет настраивать запуск тестов - как запускать, сколько раз запускать, останавливать ли повторы после падения (или запускать, пока не упадут) и т.п. Таким образом можно отлавливать любые нестабильные тесты.

Профайлер IDEA

В IDEA предусмотрена интеграция с инструментами для профилирования. Из коробки доступны Async Profiler и Java Flight Recorder. Выбрать, какой будет использоваться в данный момент, можно через Preferences в секции Profiler.

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

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

Анализ stack trace

IDEA умеет анализировать сторонние стектрейсы. Для этого стектрейс надо вставить в окно Analyze stack trace, доступное из меню Analyze -> Stack trace (или Thread Dump). Если в этом окне отметить настройку Automatic detect, то IDEA будет выводить анализ автоматом, как только обнаружит стектрейс в буфере обмена. Просматривая результаты анализа, можно будет переходить на нужные строки кода.

Лайфхак для код-ревью

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

Если изменений в коде много, для ревью удобно вытянуть всю ветку к себе, откатить все коммиты этого реквеста (Reset soft) до того, как он был влит в мастер, и выполнить git reset master. Все изменения в этом реквесте останутся в рабочей копии и будут отображаться, как будто они внесены собственными силами. Изменения попадут индекс Git и будут там подсвечиваться (сами они при этом не изменяются). Можно будет перемещаться по зависимостям.

В отличие от Git-> Compare with branch, который просто показывает список изменения, здесь будет более удобная навигация. Правда, можно случайно что-то поправить в коде, и новые изменения не будут выделяться на фоне остальных.

На сегодня все.

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

Статья написана по материалам внутренних митапов Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

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

В Maxilect системный аналитик в первую очередь концентрируется на технических задачах. Он немного понимает программный код, может самостоятельно писать базовые SQL запросы, осознает и применяет различные принципы построения архитектуры приложений, а также их взаимодействия. Умеет работать и проектировать веб сервисы и очереди (MQ). Но бизнес анализом ему заниматься не приходится.

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

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

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

Поговорим о том, какие направления аналитику открываются чаще.

Аналитик и бизнес

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

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

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

Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. It - сфера динамично развивается и в ней появляются новые смежные профессии. Еще 3-4 года не многие слышали про роль product owner, а сейчас роль владельца продукта все более востребована. И я уже ни раз сталкивалась с командами, где именно PO определяет, какие бизнес-задачи войдут в скоуп спринта, а какие нет. В каком-то смысле, помимо выполнения своих основных функций, product owner встраивается в цепочку разработки вместо бизнес-аналитика, взаимодействуя и с заказчиком, и с системным аналитиком.

Нужно ли тестировать?

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

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

Системный аналитик vs архитектор

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

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

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

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

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

Выйдет ли из аналитика лид?

Стоит следить и за трендами в управлении. Аналитиков часто ставят на роль лидов - дескать, они хорошо понимают в проекте, умеют общаться с бизнесом. На мой взгляд, это не всегда оправданный шаг. Руководство - это в большей степени менеджерская работа, которая отнимает много времени. Это в первую очередь распределение задач, полученных сверху, между мидлами и джунами в своей команде. Мне кажется, эту работу проще возложить на руководителя проекта или product owner - мне так работать привычнее. А сильный аналитик может сосредоточиться непосредственно на своей работе. Но для некоторых переход из системного аналитика в лиды - это хороший шаг в карьере, к которому лучше готовиться заранее, изучая особенности работы команд, различия в подходах к разработке (это уже про Agile, Scrum, Kanban).

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

Автор статьи: Лейла Кадырова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Я активный сторонник Robot Framework. Уже писал на Хабре о том, что с его помощью можно решить практически любую задачу по автоматизации тестирования, особенно когда разработка ведется на Python. В той же статье я упоминал, что на смежных проектах в компании используется Pytest. Мне пришлось довольно близко познакомиться с этим инструментом, так что теперь я готов провести его полноценное сравнение с Robot Framework, конечно же, со своей персональной колокольни.

Кстати, на идею статьи меня натолкнул один из комментариев к предыдущей статье, в котором читатель сравнил jUnit и Robot Framework для проекта на Java. На мой взгляд, в этих условиях Robot Framework (основанный на Python) изначально был не очень применим. Но сама идея сравнения ближайшего аналога jUnit в мире Python (того самого Pytest) и Robot Framework мне понравилась.

Что это за инструменты?

Pytest

Фактически, Pytest - реализация xUnit фреймворка для Python. Если вы всю жизнь работали с jUnit или nUnit (двумя самыми распространенными представителями этого семейства для Java и .NET соответственно), то в Pytest найдете ровно те же стандарты - быстро поймете, что происходит, будете следовать привычным подходам написания юнит-тестов. xUnit-фреймворки - это надстройки над языком программирования или библиотеки в них, которые удобно использовать самим разработчикам. За счет этого они довольно распространены и популярны.

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

Robot Framework

В отличие от Pytest, Robot Framework - это domain specific language (DSL) - язык, специфичный для своей предметной области. Это не Python, хотя он на нем построен. Зато на Python можно написать все, что угодно для Robot Framework. И все возможности, о которых я здесь говорю (а также интеграции, настройки), доступны из коробки.

Robot Framework не настолько удобен разработчикам, поскольку требует более глубокого погружения. По сути, это другой подход написания автотестов. Как Cucumber для Java. Зато Robot Framework самостоятельно генерирует развернутые отчеты (мы об этом еще поговорим), т.е. фактически он содержит в себе также слой генерации отчетов, и развивается продукт одним сообществом - неделимо и гармонично.

Кстати, сообщество открытое и довольно отзывчивое. У него есть открытый канал в Slack, где каждый желающий может задать вопрос по Robot Framework и получить на него ответ. Я и сам иногда там отвечаю. Я даже иногда контрибьючу в Robot Framework.

Аргументы в пользу Robot Framework

Отсутствие лишних ограничений на наименования

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

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

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

Robot Framework никак не заточен на юнит-тесты. В нем предусмотрен раздел Keywords, а сами тесты могут называться как угодно. Мне кажется, так работать удобнее. Более того, в Robot Framework любые сущности, в том числе keywords, можно называть по-русски. Грамотно подобрав названия, текст теста можно превратить в рассказ (Открой сайт, введи логин, убедись, что результат такой-то). Это позволяет не писать длинные комментарии, рассказывающие о том, что там происходит. Любой участник разработки или руководитель, никогда не залезавший в недра тестирования, может открыть этот тест и понять его. И время экономится, и понимание ситуации даже через полгода сохраняется.

Suite setup

Бывает, что для набора тест-кейсов (тест-сьюта) требуются однотипные настройки, например выполнение метода, который готовит некие данные, создает сущности и сохраняет их идентификаторы для использования в тестах. В Robot Framework предусмотрены отдельные настройки suite setup, которые применяются для всех тестов в наборе. Отдельно есть suite teardown, который выполняется после всех тестов в наборе, а также аналогичные настройки для каждого тест-кейса (test setup и test teardown). Это удобно, логично и не требует изобретения велосипедов.

В xUnit фреймворках есть аннотации, заменяющие настройки suite setup, а в Pytest есть фикстуры со scope=class.

В Pytest тест-кейсы могут быть просто методами (и тогда у них нет никакого suite setup - т.е. нет единой подготовки). Если же нужна единая подготовка, мы можем обернуть эти методы в класс. Но если мы сделаем фикстуру со scope=class для этого класса (т.е. попытаемся реализовать suite setup), то получим отдельный инстанс класса для каждого теста, так что данные из suite setup никак не попадут в тест-кейсы. Отдельные инстансы, вероятно, создаются из предположения, что данные из разных тест-кейсов не должны влиять друг для друга. Но из-за этого настроить среду для выполнения тестов намного сложнее, чем в Robot Framework, где suite setup предусмотрен априори.

Обычно этот вопрос в Pytest приходится обходить через создание отдельной фикстуры, куда загружаются данные. Эта фикстура впоследствии подтягивается в тесты. Другой путь - воспользоваться средствами Python, создав статическое поле у класса, которое будет общим для всех его инстансов (например, self.__class__.test_id = 2). Но на мой взгляд, это тоже костыль - к полям класса через подчеркивание не стоит обращаться извне.

Логи

Как я отметил выше, в Pytest для генерации логов чаще всего используется Allure. Это красиво и модно. Но из-за описанной выше особенности с инстансами, Allure не понимает, что и как связано с тестом. В отчет не попадают действия из suite setup. Приходится это обходить через написание обработчиков. И с моей точки зрения это уже не просто костыль, а настоящий костылесипед.

Кстати, в других xUnit фреймворках эта проблема тоже есть.

На фоне Pytest+Allure у Robot Framework логи максимально подробны и даже избыточны. Они включают даже то, о чем ты никогда не задумаешься - Robot пишет все, что ты делаешь. С помощью этого лога гораздо проще отлавливать плавающие ошибки, которые так просто не воспроизведешь. Ты точно знаешь, где и какое значение было у переменной, какой API вызвали. Зачастую и перезапускать тест не надо, чтобы понять, что происходит. Для Pytest в таких сложных случаях приходится придумывать инструменты, которые помогают генерировать лог, как у Robot Framework.

Синтаксический сахар

В Robot Framework не нужно придумывать усложняющих конструкций. Есть выражения, спасающие от лишнего кода.

Я люблю писать keyword-обертки и в них оборачивать другие keyword-ы. Например, в keyword, который из ответа API берет ID, можно будет подсовывать keyword, который дергает разные API (если в компании есть стандарты написания кода, то ответы API будут сходными - поле ID скорее всего будет во всех).

Например, можно написать: Идентификатор из создание сущности. Здесь Идентификатор из - keyword-обертка, создание сущности - это keyword, который вызывает API и отдает весь ответ. В другом случае можно написать Идентификатор из создание таблицы, где создание таблицы - это другой keyword.

Для меня писать подобным образом удобнее и понятнее. А если изменить keyword с создание сущности на создания сущности, то конструкция будет читаться даже с литературной точки зрения (Идентификатор из создания сущности).

Теггирование

В заголовке лога Robot Framework показывает статистику по каждому тегу. Если изначально правильно расставить теги, достаточно будет взглянуть на эту статистику, чтобы увидеть, в чем проблема, не забивая себе голову тем, что происходит внутри. Я писал про это в предыдущей статье. Там же я упоминал, что теги можно привязывать к идентификаторам багов в Jira или в любом другом треккере, который у вас используется. Как раз недавно у меня был случай, когда на одном из поддерживаемых тестов, о которых я и думать забыл с полгода назад, сработали старые забытые баги, привязанные к тегам. И на их поиски ушло несколько секунд, вместо минут и часов.

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

Кстати, и Allure не дает возможности отобразить статистику по тегам. Вероятно, если бы в нем появилась такая возможность, она в моих глазах приблизила бы связку Pytest+Allure к Robot Framework по функциональности. Плюс был бы в том, что связка Pytest+Allure не требовала бы забивать головы консервативных разработчиков новым DSL. К сожалению, появление таких инструментов маловероятно из-за того, что Pytest и Allure развиваются разными группами.

Аргументы в пользу Pytest

В моем списке всего два аргумента в пользу Pytest. Зато от сторонника другого инструмента они должны прозвучать весомо.

Отладка

Об этом писал один из читателей в комментариях к предыдущей статье. К сожалению, ты не можешь приостановить выполнение в Robot Framework, чтобы посмотреть значения переменных. Это факт, который можно записать в плюс Pytest.

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

Параметрические тесты Pytest

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

На примере реального проекта. Предположим, у нас есть API с двумя параметрами, каждый из которых может принимать несколько вариантов значений (например, один принимает 7 значений, другой - 10). И эти значения друг друга не исключают. В соответствии с теорией тестирования в таком случае надо выбрать несколько кейсов, более-менее равномерно покрывающих сетку из 70 пересечений (метод pair-wise). Но я с помощью метода product из модуля itertools (который перемножает списки) написал тест-сетап, который подготавливает 70 комбинаций данных, а потом ходит в API и обеспечивает то самое утопическое exhaustive testing. При появлении еще одного варианта в начальных данных мне достаточно просто добавить строчку в один из первоначальных списков.

В Robot Framework так сделать нельзя. Там можно написать тест-шаблон, который принимает два значения, и сделать 70 вызовов. При появлении новых значений количество вызовов придется увеличивать.

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

Автор статьи: Владимир Васяев

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagramили Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

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

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

Каждая секунда на счету

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

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

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

Каждый день в течение многих месяцев отчеты по всему коллективу демонстрировали плюс-минус восемь часов работы. Подвох заметили случайно. У одного из сотрудников трекер намерил 24 часа работы за сутки. Понимая, что человек не мог не отлучаться с рабочего места, начали разбираться. Оказалось, что уже давно сотрудники успешно обходят трекеры, запуская эмуляторы активности и т.п. Выявленные способы были настолько хитры и изворотливы, что перенастраивать ПО уже не было смысла. Вместо этого договорились, что каждый сотрудник будет подключаться к онлайн-конференции на все 8 часов своей работы. А охранники головного офиса получили задание за ночь отсматривать записанное видео и к утру отчитываться перед руководством о том, кто работал недостаточно рьяно. Это же отличный повод назначать или отменять премию! Да и весь коллектив при деле. Перед начальством открывается целое поле для поиска точек повышения эффективности. Охранники теперь точно не отвлекаются - смотрят на задумчивые лица разработчиков. А сами сотрудники (те, кто не успел уволиться в ходе ужесточений контроля) сутки напролет придумывают, как закольцевать видео рабочего процесса, чтобы никто не заметил, что это повтор.

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

Трудозатраты на проектах учитывать надо, но только в форме отчетности и с точностью до 15 минут. И уж точно содержание отчета не должно отражаться на ежемесячном доходе.

Найм джунов на широкую ногу

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

Первые подсчеты очень понравились финансовому отделу - не увеличивая ФОТ, можно держать в три раза больше разработчиков. Даже если работать каждый из них будет в два раза медленнее, выгода налицо! И джунов на рынке пруд пруди, почти все хотят работать удаленно. Если открыто заявить, что компания готова брать без N-летнего опыта работы, выстроится очередь. А если кто-то из нанятых юнцов потом уйдет, на смену всегда можно будет найти других. Главное успевать шарить между ними основные знания о проекте.

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

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

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

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

Безлимитный рабочий день в каждый дом!

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

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

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

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

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

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

Ни в коем случае не отвлекать!

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

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

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

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

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

Безоблачный рабочий процесс

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

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

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

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

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

Вне офиса никаких печенек

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

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

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

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

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

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

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

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

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

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

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

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

И нам пришлось на это отреагировать.

Почему мы должны были реагировать?

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

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

Мы поняли, что нужно что-то менять! И начали действовать сразу по нескольким направлениям.

Обучение - 30%

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

Возможность обучения в онлайне заинтересовала примерно треть коллектива (30%). Тему и время для пилотного тренинга выбрали общим голосованием.

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

Квизы - 20%

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

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

Квиз заказывали здесь. Эта компания - не монополист, но использовали их ресурс и остались довольны.

Онлайн-игры - 17%

Еще одна цель для совместного времяпровождения - онлайн-игры. По пятницам вечером мы начали гонять зомби в 7 Days to Die.

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

Как ни странно, вечер пятницы для игр оказался удобнее всего. Его выбрали голосованием. 7 Days to Die - не та игра, в которую можно побегать 15 минут. Мы несколько сократили игровой процесс - на нашем сервере до нашествия зомби проходит только 5 дней, при этом 1 день длится не час, а 40 минут. Но даже при таких сокращениях на сессию игры требуется несколько часов. Поэтому главным ограничением тут выступали вечерние созвоны на проектах в другие дни недели, которые у всех заканчиваются в разное время. Если ждать, пока все освободятся, то закончат игроки уже далеко заполночь. Это тяжело реализовать накануне следующего рабочего дня. А после игры в пятницу можно спокойно отоспаться.

Традиция можно сказать прижилась - игра проходит каждую пятницу. Постоянно играет около 5-7 человек (около 15%).

Скорее всего мы на этой игре не остановимся - будем пробовать и другие.

Тайный Санта - 94%

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

Тайный Санта - активность, которая приоткрывает завесу тайны над этой стороной их жизни, дает повод для общения. Эта идея зашла удивительно хорошо. Участие в Тайном Санте у нас добровольное. Но инициативу проявил почти весь коллектив - 94%.

Для выбора дарителей и одаряемых мы использовали генератор https://www.drawnames.com/. Он разгрузил и вовлек в процесс HR. Им не пришлось отказываться от участия, чтобы вручную составлять таблички, кто и кому посылает подарок. Настроили все честно - даже организатор группы не видит внутреннюю механику. При этом мы открыли вишлисты для всех участников группы - это немного раскрывает личность каждого. В рабочем проекте ты вряд ли узнаешь, что твой коллега любит забавные носки или как раз сейчас закупает оборудование для самогоноварения.

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

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

Онлайн корпоратив

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

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

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

Как мы это внедряли

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

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

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

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

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

И, конечно, пока действуют ограничения, мы продолжаем искать пути для совершенствования. Сейчас, например, думаем над темой онлайн-спорта. По итогам массовой удаленки РБК насчитал 19% людей, получивших проблемы со здоровьем из-за сидячего образа жизни. У нас всегда была HR-программа компенсации части расходов на спорт. Что именно оплачивать, максилектовцы выбирали сами. Это могла быть оплата абонемента в спортзал, индивидуальные занятия спортом или спортинвентарь - от велосипеда до запчастей на Ниву для участия в гонках по грязи.

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

Уехать в другую страну, работая удаленно? Легко! Но я сделал иначе. Я переехал из Краснодарского края в Валенсию (Испания), имея опыт только офисной работы. И лишь потом устроился удаленно, причем в российскую компанию.

Как и почему так получилось - под катом.

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

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

Я выбирал из нескольких стран. В моем вишлисте уже давно поселились США, Канада, Германия, Австралия и Испания. Вопрос заключался в том, насколько далеко я готов уехать, чтобы попробовать?

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

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

Переезд и поиски жилья

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

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

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

Снять жилье через сервис для отпускников, вроде AirBnB, очень дорого. Так можно и всю зарплату оставить. Долгосрочная аренда по идее должна быть дешевле. Сидя в России за компьютером и открывая местную доску объявлений (например, http://idealista.com/ или https://www.fotocasa.es/es/), ты действительно видишь привлекательные цены. Но на месте выясняется, что за эти деньги квартиру тебе никто не сдаст, потому что у тебя нет контракта на работу. Без него ты не выглядишь финансово обеспеченным и не пройдешь собеседование, которое традиционно предшествует подписанию договора аренды. Так что о самых хороших предложениях придется забыть.

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

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

Первая квартира обходилась в 850 евро в месяц. Это очень много даже для более-менее нормального ремонта. Но арендовал я ее, потому что боялся, что иначе варианты у меня останутся только в неблагополучном районе, где будет небезопасно. С семьей это не выход. Уже через пару месяцев я понял: если грамотно искать, здесь можно найти квартиру с тремя спальнями и небольшой кухней за 550 - 600 евро в месяц. Эти цены уже похожи на Москву и Питер и вполне приемлемы. Так что, потратив кучу нервов и потеряв 1000 евро, мы довольно быстро переехали из того первого самого дорогого жилья.

Первый месяц поисков работы

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

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

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

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

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

Чтобы построить какую-то карьеру в Испании, нужно было срочно подтягивать языки и переезжать в большой город. Наверное, к большому городу я был не готов. Там сразу возрастает ценник на аренду жилья (иногда в несколько раз). Если ты в глубинке снимал квартиру за 350 евро, то в Мадриде нужно будет выложить за такое же жилье больше 1 - 2 тысяч евро в месяц. При этом страна не конкурирует по зарплатам с такими крупными хабами, как Германия, Канада или Америка. После вычета налогов от испанских зарплат остается меньше, чем у ИТ-шника в Москве (в Испании прогрессивная шкала, ты отдаешь 40%). Мне комфортнее жить в крупном, но более спокойном городе. Не столь стремительном, где меньше людей на квадратный метр.

Казалось бы, выход - удаленка? Но работать на испанскую компанию в удаленном режиме оказалось невозможно. Тут это просто не развито. Я контактирую с местным ИТ-сообществом. В Валенсии костяк ИТ-шной тусовки - это 15-20 человек, которые активно общаются в чатах. Судя по нашим разговорам, в основном они работают удаленно на Америку, а живут здесь, потому что Испания - сравнительно недорогая страна для жизни.

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

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

Плюс удаленной работы в том, что ты можешь переехать, не привязываясь к офису компании, лишь бы было подключение к интернету. Я, например, за время проживания в Испании попробовал жизнь в небольшом поселке (около 100 тыс. человек) с заметным процентом русскоговорящего населения - Torrevieja. Но жизнь там однообразна. Для меня в новинку было идти на море после работы. Пока ты голодный до моря, каждый день гуляешь по набережной, ходишь купаться. Но со временем это приедается. Я обратил внимание, что мне после работы необходимо отвлечься - разгрузить голову, иначе на следующий день она будет хуже работать. И здорово, если есть разнообразие возможностей. Поэтому теперь я выбрал город с большим количеством общественных пространств. Я и не думал, что это окажется настолько важно.

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

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

Социальный пакет

Переехав в Испанию, я получил весь местный социальный пакет.

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

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

Я осел в Валенсии. Поскольку родился я в Краснодарском крае, местный климат для меня вполне комфортен. Я приехал перед прошедшей зимой и в городе без центрального отопления в квартире было, конечно, холодновато - 16-17 градусов. Но мы спасались обогревателями и больше времени проводили на улице. Здесь много солнца и, хотя квартира не успевает прогреться, воздух за окном разогревается до 20 - 22 градусов. Уже после зимовки мы переехали в квартиру в доме с кирпичными стенами с утеплителем. Мне кажется, в этом году нам будет теплее.

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

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

Автор статьи: Артем Курусь, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Этот год перевернул все планы с ног на голову. Закрытые границы, локдаун, а потом и затянувшаяся у многих удаленка

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

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

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

Ни отпуска, ни работы

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

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

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

Но дальше нужно было работать. Удаленщики переехали в съемный дом в Ялте, где (как предполагалось на этапе поиска) должны были быть оборудованные рабочие места в необходимом количестве и нормальный доступ к интернету, которого хватит на всех. К сожалению, владельцы дома слегка приукрасили удобства. Забегая вперед, отметим, что в той обстановке, что встретила удаленщиков в реальности, наладить рабочую атмосферу так и не получилось.

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

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

Попробовав несколько дней работать из общего съемного дома, Василий начал искать альтернативу. Съехать в гостиницу было уже слишком дорого - в пик сезона свободных номеров на сегодня, да еще с рабочим местом и интернетом, не найти. Коворкингов или офисов в аренду на короткий срок в Ялте не оказалось. Сетевых кафе, вроде Макдональдсов, нет. А в местных забегаловках Wi-Fi - далеко не самая главная опция (по мнению хозяев заведений). Да и шума там не меньше, чем в съемном доме.

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

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

Как не повторять этот опыт

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

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

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

• Для удаленной работы связь - это критичный момент. Проговаривайте все детали заранее. Объекты размещения часто приукрашивают качество связи, предполагая, что гости просто будут заливать фотки в Инстаграм, да переписываться в Вконтактике, а поэтому не станут жаловаться. Гостиницы могут писать про интернет на всей территории, имея в виду только зону вокруг бассейна, но не номера. Частный сектор может упоминать доступ в интернет, подразумевая только то, что вы поймаете своим смартфоном. Подстрахуйте себя от неприятных сюрпризов - выясните все детали заранее еще до того, как бронировать. Карты покрытия операторов беспроводной связи вам в помощь (но и они тоже могут ошибаться).

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

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

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

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

И удачи вам в дороге!

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagramили Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

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

В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.

Что собой представляет Charles Proxy

Charles Web Debugging Proxy - это инструмент мониторинга HTTP и HTTPS трафика. Он выступает в роли прокси-сервера (промежуточного звена) между тестируемым приложением и сервером на бэкенде, позволяя не только видеть, но также перехватывать и редактировать запросы.

Главное преимущество Charles Proxy и снифферов в целом - возможность просмотра трафика, в том числе с мобильных устройств, что значительно облегчает работу тестировщика клиент-серверных мобильных приложений.

Первичная настройка

При тестировании мобильного приложения

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

Как правило, соединение настраивается по Wi-Fi. В настройках Wi-Fi мобильного устройства в качестве proxy-сервера надо указать IP-адрес компьютера и стандартный порт инструмента 8888 (пароль остается пустым).

IP-адрес компьютера можно узнать через командную строку (ipconfig) или в самом Charles Proxy (Help -> Local IP Address).

Этот же адрес есть в инструкции по подключению, доступной в Help -> SSL Proxying -> Install Charles Root Certificate on mobile device remote browser.

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

Скачать сертификат можно по адресу: chls.pro/ssl (адрес, по которому скачивается сертификат, также можно найти в инструкции Help -> SSL Proxying -> Install Charles Root Certificate on mobile device remote browser). Далее в iOS его необходимо сделать доверенным (в Настройки -> Основные -> Профили).

В Android установленные сертификаты верифицируются в Settings -> Trusted Credentials на вкладке User.

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

При тестировании приложения на ПК

В этом случае дополнительные сертификаты нужно установить на сам ПК. Для скачивания и установки нужна ссылка из Help -> SSL Proxying -> Install Charles Root Certificate.

Сертификат устанавливается в доверенные корневые центры.

Два слова об интерфейсе

Интерфейс Charles Proxy прост. Слева - список перехваченных запросов, справа - детали.

В списке запросов есть две основные вкладки - Structure и Sequence.

В первом случае запросы рассортированы по хостам-папкам. Наведя на любой из них, можно получить всю информацию о количестве запросов к этому корневому хосту, доле удачных, таймингах, размерах и т.п. Фактически, здесь представлена вся та же информация, которую можно получить из панели разработчика в браузере. Выбрав конкретный URL, можно увидеть код ответа, версии протоколов, контент и т.п. Тело запроса, заголовки, cookie (если есть) можно посмотреть в разных форматах - даже в HEX.

С помощью контекстного меню запроса можно настраивать блокировки, повторять и изменять запросы. На этом мы еще остановимся.

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

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

Фильтрация

В Charles Proxy очень много вариантов фильтрации запросов.

Начнем с вкладки Structure. Самое примитивное - скопировать хост и вставить в поле Filter. Так мы увидим только запросы с этого хоста. Примерно того же результата можно добиться, если в контекстном меню хоста выбрать Focus. Остальные запросы будут собраны в Other Hosts. Если при этом перейти на закладку Sequence и отметить настройку Focused, то в списке окажется информация только о тех запросах, которые были выбраны на вкладке Structure.

На вкладке Sequence есть аналогичный фильтр.

Charles Proxy умеет работать с регулярными выражениями. Для этого на вкладке Sequence выбираем Settings и отмечаем пункт Filter uses regex. И вписываем в поле поиска элементарную регулярку.

Например, вот так

^\w{4}\.

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

Там же можно включить Autoscroll списка запросов или указать максимальное количество строк.

В Charles Proxy можно фильтровать не только отображение, но и запись запросов. Для этого надо зайти в Proxy -> Record settings и задать условия на одной из вкладок - Include или Exclude - так мы включаем или выключаем запись запросов данного хоста.

Похожего результата можно добиться, используя блок-листы. Включить хост в блок лист можно из контекстного меню (команда Block list) или через добавление в Tools -> Block list, где следует отметить Enable Block list.

Блокируемый запрос можно прервать двумя способами (подходящий надо выбрать в настройках):

• сбросить соединение;

• вернуть ошибку 403.

От выбранного способа блокировки зависит, какой ответ мы получим.

Можно провести эксперимент. Включим наш тестовый стенд в Block list, выбрав простой сброс соединения. С помощью контекстного меню запроса повторим его (команда Repeat) и получим такой ответ:

Статус запроса - Failed, а в описании ошибки указано, что Connection dropped.

Просмотр SSL-трафика

Если ранее мы успешно установили SSL-сертификат, для просмотра зашифрованного трафика остается только включить SSL proxying для нужного хоста в самом Charles Proxy. Это можно сделать через контекстное меню конкретного хоста.

Чтобы не включать каждый хост, можно зайти в Proxy -> SSL Proxying settings и на первой вкладке SSL Proxying включить Enable SSL Proxying.

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

Брейкпоинты

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

Установить Breakpoint можно из контекстного меню запроса. После этого все аналогичные запросы будут перехвачены. Их можно будет просматривать и редактировать.

Чтобы проверить, как это работает можно использовать повтор запроса (Repeat из того же контекстного меню). Запрос перехватывается, его можно редактировать.

В принципе, изменить можно все - от header до авторизационного токена. Когда редактирование будет закончено, можно выбрать Execute и в Charles Proxy появится повторный запрос, который и отправится на сервер, а потом вернется с ответом. В этот момент можно будет посмотреть и отредактировать ответ, который получит приложение - появится поле Edit response.

Редактируя запрос, можно ввести заведомо некорректные данные и посмотреть, как ответит сервер. Также можно отредактировать ответ (внеся некорректные данные) и использовать его для тестирования фронта. Можно оставить корректные данные, но изменить код - посмотреть, как фронт воспринимает информацию, переданную через API.

Map remote

Еще одна популярная функция Charles Proxy - подмена ответа сервера. Так мы можем ответ одного хоста подменить на ответ другого. Настраивается это через Tools -> Map Remote.

Обратите внимание, в левом нижнем углу есть кнопки Import и Export. Они позволяют обмениваться настройками - переносить их с одного рабочего места на другое.

Например, мы можем подменить контура. Я буду посылать запрос на dev-контур, но ответ хочу получить с тестового стенда. Для этого создаем новый пункт в списке Map Remote Settings. Map From - куда изначально был запрос; Map to - откуда берем ответ.

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

Map Local

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

Rewrite

Функция Rewrite может быть полезна, если вам нужно переписать данные, которые отправляются в Charles Proxy. В отличие от простого редактирования Rewrite позволяет задать правила изменения и работать в автоматическом режиме. Можно изменять и добавлять заголовки, искать и заменять текст в теле запроса или ответа. Можно даже менять статус ответа.

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

Настроить это можно через Rewrite settings, доступные в контекстном меню. Единственный недостаток инструмента в том, что каждое правило замены прописывается отдельно.

Помимо изменения запросов и ответов мы можем запретить кэширование или cookie (функции No caching и Block cookies). Эти опции повторяют аналогичные инструменты панели разработчика в браузере. В обоих случаях настраивается список хостов, для которых действует настройка. Если же список пуст, то кэширование и cookie отключаются на всех перехваченных хостах.

Throttling

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

Настраивается функция через Proxy ->Throttling settings.

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

Repeat Advanced

Хотя полноценное нагрузочное тестирование лучше проводить в специальных инструментах, Charles Proxy имеет одну базовую настройку, которая помогает закрыть минимальные потребности. Функция Repeat Advanced (доступная через контекстное меню перехваченного запроса) позволяет нужное количество раз повторить тот же запрос. После настройки откроется отдельная сессия, где будут видны детали каждого из запросов.

Конечно, список функций Charles Proxy этим не ограничивается. Есть еще много полезного - от перенаправления доменного имени на другой IP-адрес, до автоматического сохранения полученных ответов.

Отмечу, что Charles Proxy платный. Можно использовать триальную версию. Но раз в 5-7 минут поверх него будет отображаться всплывающее окно с версией, а раз в 30 минут он будет выключаться, при этом сессии не сохраняются. Решайте сами, помешает ли это вашей работе.

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

Автор статьи: Артем Холевко, Максилект.

Текст подготовлен по материалам внутреннего семинара Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

10 лет назад далеко не все ВУЗы готовили разработчиков для рынка. Я училась как раз там, где было все хорошо с базой, но плохо с современными технологиями, и по окончании не смогла найти себя в ИТ. Почти 10 лет меня мучил вопрос - а не вернуться ли? Не выйдет ли из меня хорошего тестировщика?

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

ИТ-шник вне ИТ

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

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

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

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

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

Дообучение на тестировщика

Все изменилось, когда я действительно ушла в декрет. У меня появилось время, чтобы изучать новое - я обложилась книгами Савина, Куликова и других, начала проходить бесплатные курсы, смотреть отдельные лекции на YouTube. Пробовала даже читать исследовательские туры Уиттакера в оригинале (у книги нет русского перевода) и Как тестируют в Google. Мне понравилось.

К началу 2020 года, когда ребенок уже подрос, я начала искать работу в тестировании.

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

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

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

Первые собеседования в новом статусе

Честно скажу, до последнего меня преследовал синдром самозванца. Несмотря на базу в ИТ из ВУЗа, мне все казалось, что я знаю недостаточно, чтобы претендовать даже на позицию джуна. Ну и возраст уже не тот, чтобы кардинально менять работу. Когда джун приходит после ВУЗа, все на это нормально смотрят. А когда тетя за 30 после декрета? Не поздновато-ли?

Но тут помогло сообщество. Я пообщалась в чатах с теми, кто успешно проходит собеседования, и поняла, что по многим вопросам знаю даже больше. И среди новичков в тестировании полно людей старше меня. Зачем к себе придираться? Найти свое призвание никогда не поздно! Если другие устраиваются на работу, то почему я не могу?

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

Период пандемии дал мне время на то, чтобы лучше присмотреться к собеседованиям. Еще до COVID-19 я успела пройти несколько собеседований, но не получила оффера. Проанализировав свои неудачи, я поняла несколько моментов.

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

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

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

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

Автор: Наталья Шилова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.