High availability и Fault tolerance

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

Хороший разработчик борется с даунтаймом на уровне архитектуры. Мы часто слышим что сервис High available, реже слышим что он Fault tolerant. Иногда эти понятия путают. Давайте разберемся что есть что.

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

1️⃣ High availability

Мы хостим наш стартап в одном датацентре (Availability Zone в AWS). В результате климатических изменений AZ затопило, вместе с ней и все сервера. Мы не можем выдавать в аренду плакаты 📉. Это не High availability.

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

2️⃣ Fault tolerance

Для нормальной работы нашего стартапа нужно 6 серверов, только такой сетап выдерживает текущую нагрузку. Обычно про пиковую нагрузку мы узнаем заранее, ориентируемся на твиттер Греты Тунберг. Наши сервера равномерно распределены по двум AZ. Вдруг один затопило и все стало работать медленнее, три сервера не справляются с нагрузкой. Мы выдаем в аренду меньше плакатов 📉. Это не Fault tolerance.

А вот если бы мы размещали по 6 серверов в двух AZ, то есть имели бы избыточные ресурсы, то наши пользователи бы не заметили конфуза с затоплением. Fault tolerant системы выдерживают обычную нагрузку, даже если произошли какие-то перебои с инфраструктурой.

Если представить, что каждый сервер обходится нам в 100€ в месяц, то очевидно, что построить Fault tolerant систему дороже 💸.

⬛️ Еще раз — даунтайм это плохо, из-за него бизнес теряет деньги. Лучше заранее, при проектировании, стараться строить систему где риск даунтайма мал. High availability это маст хэв. А вот Fault tolerance это дороже, нужно посчитать имеет ли это смысл, возможно можно немного потерпеть и отмасштабировать руками.

Вы строили Fault tolerant системы? Пишите в комментариях.

#хардскиллы

Что такое Glue work

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

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

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

У таких задач есть название — Glue work, а люди, которые этим занимаются — они being a glue. Потому что они, фигурально, склеивают сложный пазл разработки программного обеспечения и с ними определенно легче, чем без них.

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

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

⬛️ Еще раз — помимо разработки в IDE Хороший разработчик может делать еще кучу дел, которые делают команду эффективнее. Нужно понимать, что эти "мелкие" дела они сами по себе работа, может даже важнее программирования. Этим может заниматься каждый, не только менеджеры. Людей которые это берут на себя нужно за это благодарить (если они это делают хорошо). Glue work это классно и это тоже скилл.

Согласны? Пишите в комментариях.

#софтскиллы

У кого есть дети, я написал лонгрид о том как практики из IT помогают мне быть хорошим родителем. У кого нет детей — тоже может быть полезно :)

https://dou.ua/forums/topic/35409

Про типы компаний и карьерный рост

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

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

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

Компетенции которые делают меня Principle в SHARE NOW — знание доменной области, софт скиллы, влияние на развитие инженеринга, не делают меня даже Middle (в целом у них уровни по другому называются) в FAANG компаниях. Наверное все, что я упомянул это хорошо, но входной фильтр остается прежним — вращай деревья, пиши код на доске, быстро ищи в массивах, проектируй системы.

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

Это как плаванье и бег. Если я умею быстро плавать (SHARE NOW), то это не помогает мне быстро бегать (Netflix). Хотя и то и то — спорт.

Но есть и хорошие новости. Если будучи в 🇺🇦 Украине, в прошлом, я думал что в Google попасть сложно или невозможно. То сейчас, я понимаю что это целиком возможно и секретный соус в следующем:

1. Принять, что мой прошлый опыт для них не релевантен. Зато релевантен для меня, он поможет мне с пунктом два.
2. Нужно потратить время (много) и подготовиться. Cracking the coding interview и https://leetcode.com/ нон стоп и все будут довольны.

Что думаете? Есть среди нас люди из FAANG или другого BigTech? Интересно ваше мнение.

#истории

Новости

Michael Jackson (не тот) и Ryan Florence придумали и поддерживают React Router — #1 декларативный роутер для React экосистемы. Этот проект open source, зато он сделал их известными на рынке. Поэтому зарабатывали они, насколько я понимаю, с помощью компании React Training — проводя оффлайн тренинги по React.

Но тут пришла пандемия 🦠 и оффлайн тренинги перестали быть популярными, а онлайн, как я понял, не имели такого же размаха. Ребята решили сделать небольшой пивот и придумали, что они смогут сделать проприетарный (т.е. платный) фулстэк фреймворк для веб разработки. С React, server rendering, улучшенным роутингом и своими фичами. Они назвали его Remix.

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

Сегодня день релиза, можно посмотреть пощупать: https://remix.run/. В общем альтернатива Next.js.

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

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

Слышали об этом проекте?

#новости

Что такое N-tier application

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

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

Это классический 3-tier architecture. Иными словами, в нашем сервисе есть presentation tier, application tier и data tier.

1️⃣ Мобильное приложение это presentation tier. Это интерфейс, который предназначен для пользователя.

2️⃣ Бэк-энд сервисы, которые помогают мобильному приложению работать это application tier, здесь живет бизнес логика. Повторяю, это не обязательно один монолит, несколько сервисов могут относиться к одному слою.

3️⃣ Базы данных, с которыми работает бэк-энд и которые обеспечивают сохранение данных это data tier.

3-tier architecture не является единственным возможным вариантом архитектуры. Представим, что наше мобильное приложение все запросы шлет через API Gateway, а этот gateway распределяет их по сервисам. Теперь у нас 4-tier architecture.

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

⬛️ Еще раз — любую архитектуру можно разбить на логические слои и описать как n-tier architecture. Не факт, что большее количество слоев делают архитектуру менее эффективной, но они усложняют ее понимание.

Со сколькими слоями сталкивались вы? Пишите в комментариях.

#хардскиллы

Перевел статью про git bisect для Хабра.

Используете такое? Делитесь опытом в комментариях. (и ставьте ⬆️ на Хабре 🙏)

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

Что такое Cognitive complexity

Под термином Сognitive complexity (когнитивная сложность) обычно понимают следующее — как сложно постороннему разработчику будет интуитивно понять ваш код.

Мои "любимые" примеры такой сложности, про то время, когда люди стремились к "эффективности" кода и везде. Например, в JavaScript, использовали битовые операции. Они ведь быстрые.

Что делает код 8 >> 1? Делит 8 на 2. Понимал ли я это когда-то без дополнительного гугления? Нет. (Ну только в следующие 3 минуты после предыдущего гугления). Этот код сложный для восприятия. Обычно такой код писать не надо, нужно писать только в том случае, когда вы действительно оптимизируете на производительность.

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

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

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

⬛️ Еще раз — когнитивная сложность это важно, чем ниже она, тем проще работать и поддерживать этот код или CI файл. Когда что-то делаешь, то нужно себя спрашивать — это будет сложно понять постороннему человеку?

Какова когнитивная сложность постов в этом канале? Пишите в комментариях.

#софтскиллы

Что важнее development experience или cost optimisation?

Примерно 4 года назад, я работал над проектом, который включал в одном репозитории бэк-энд и фронт-энд. Бэк-энд был на Node.js, а фронт-энд на React. Причем сервером для React фронт-энда выступало это же Node.js приложение. В итоге все собиралось вместе, запаковывалось в Docker и запускалось на настоящем железном сервере (нескольких, арендованных в OVH).

Чтобы React приложение стало готово к продакшену его надо собрать. Собиралось все на TeamCity, у которого был свой пул воркеров. И вот как-то раз я заметил, что весь процесс сборки и деплоймента занимает целых 20 минут ⏳. Для Node.js + React приложения с легким Docker контейнером это долго.

Я начал смотреть внимательнее и увидел, что сам билд React приложения и Docker контейнера занимают ~15 минут. А у меня на машине, тогдашнем Macbook Pro, это происходило за 5 минут. Почему? Я быстро предположил что дело в жестком диске. У меня был точно SSD, а что было на воркерах TeamCity? Я спросил у наших DevOps — мне ответили, что там HDD.

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

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

Я решил продолжить и пошел с этим же вопросом к инженеринг менеджеру, который был и менеджером DevOps команды. Он мне тоже сказал что идея хорошая, но вот нельзя просто так взять и изменить это. Это будет стоить дороже. Нельзя просто вытащить одни жесткие диски и вставить другие, это надо просить OVH. Или менять серверы на новые. И команда DevOps тоже не виновата, у них есть другие важные задачи.

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

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

Как вы считаете, кто был прав? Пишите в комментариях.

#истории

Про Рождественский календарь для разработчика

В Европе есть традиция Рождественского календаря. Это календарь на первые 24 дня декабря, который "помогает" дождаться Рождества. Обычно что-то с 24 дверками, на каждой написано число от 1 до 24. Каждый день вы открываете одну дверку и там вас ждет сюрприз. Насколько я знаю, в 🇺🇦 и 🇷🇺 такая традиция тоже проникает последние годы.

В общем, что такое календарь ясно, а причем тут Хороший разработчик?

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

Ниже подборка календарей на 2021 год:

⛄️ Advent of Code

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

🌲 Java advent

Календарь про JVM технологии. Каждый день новая статья. То что нужно любителям Kotlin или Java.

🎅🏻 bekk christmas

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

❄️ Advent of GraphQL

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

⬛️ Еще раз — можно провести декабрь с пользой.

Знаете еще какие-то хорошие проекты? Пишите в комментариях.

#хардскиллы

Про продуктивные конфликты

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

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

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

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

В этом определении содержится и ключ к возможности получить продуктивный конфликт.

Представим ситуацию. Мы пишем новый сервис, сайт по производству NFT из фотографий комнатных растений 🌵, и думаем, какая база данных бы нас устроила. Собрали митинг и обнаружили, что у нас два лагеря — одни разработчики хотят использовать InfluxDB, а другие AWS Aurora, как в остальных ваших сервисах. Спор идет уже долго и никакая сторона не хочет уступать.

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

Теперь нам понятны интересы сторон. У одной — попробовать что-то новое, у другой — здоровый консерватизм. В итоге на следующем митинге, учитывая интересы сторон, вы предложили использовать AWS Aurora и написать бэк-энд на Go, с этим согласились все разработчики, команда давно хотела попробовать Go в продакшене. Это решение удовлетворило интересы обеих сторон 🤝.

Один из 🗝 к продуктивному конфликту следующий — фокусируйтесь на интересах, а не на позициях сторон.

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

Есть примеры конфликтов, которые удалось решить удовлетворив интересы, а не позиции? Пишите в комментариях.

#софтскиллы

Холм, за который вы готовы умереть

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

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

Однако, люди такие существа, что им, обычно, недостаточно выслушать логические аргументы, чтобы принять решение. В одном подкасте я услышал про исследование, где 100 людям с раком легких сказали, что им надо бросить курить, иначе они умрут ☠️. Казалось бы — логичнее некуда и ставки достаточно высоки. Сколько из них бросило курить? 10%.

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

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

"Холмов" за которые можно повоевать в любой компании куча, но выбирать такие холмы нужно с умом. Иначе можно устать (выгореть). А Уставший разработчик не может быть Хорошим разработчиком.

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

У вас есть примеры задач от которых вы отступили? Пишите в комментариях.

#истории

Хочу порекомендовать еще один Telegram-канал.

В течении моей карьеры, где-то между PHP и Java, моей основной платформой была Node.js. И даже сейчас, для своих пет проектов я выбираю Node.js, но теперь с TypeScript ;)

Хотя активно с технологией я сейчас не работаю, но держу руку на пульсе, в этом мне помогает канал Никиты Галкина Node.js recipes. У Никиты более 15 лет опыта, сейчас он работает System Architect и консультирует стартапы, чтобы их бизнес требования опирались на хороший технологический фундамент, где основная бэк-энд технология это Node.js.

В канале много постов про Node.js стэк. Не только сугубо технические, как Топ 10 ошибок в Nest.js проектах, но и в целом, про экосистему Как технологии будут востребованы для Node.js разработки в 2022?. Еще Никита пишет про личный опыт — Топ 3 моих покупки за последние годы.

Подписывайтесь на Node.js recipes и ❤️ Node.js.

Про классификацию информации

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

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

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

В целом, можно выделить три категории.

1️⃣ Restricted data. Если эти данные утекут, то это может оказать вред нашим пользователям. Сюда обычно так же включают Personally Identifiable Information (PII), все, что позволяет связать нашего пользователя с реальным человеком.

2️⃣ Private data. Данные, утечка которых, может помочь злоумышленнику, получить доступ к Restricted data. Например, если у хакера есть e-mail пользователя, то он может послать тому фишинговое письмо, и получить доступ в аккаунт пользователя.

3️⃣ Public data. Эти данные могут быть доступны всем и требуют минимальной защиты. Например — рейтинги или обзоры, которые оставлял пользователь.

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

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

⬛️ Еще раз — данные нужно защищать. Чтобы понять, что нужно защищать больше, данные нужно категоризировать. Restricted data нужно защищать лучше всего — шифровать, выдавать доступ к ней только тем, кому он действительно нужен.

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

#хардскиллы

Вакансия

Мы в SHARE NOW ищем нового разработчика в команду, где я работаю. SHARE NOW это самый большой каршеринг в Европе, мы присутствуем в восьми странах. Наша команда отвечает за процессы, которые происходят с пользователем до того, как он может начать водить машину. А именно - валидация прав, GDPR, применение промо кодов. Но это не все, еще отвечаем, например, за программу лояльности. Используем Java/Kotlin, немного Node.js. Нас 9 человек (PO, QA, 4xBE, 1xFE, Chapter Lead).

Ищем крепкого Middle разработчика с фокусом на back-end и Java/Kotlin.

Из интересного:
* Перевозим в 🇩🇪 Германию. Можно в Гамбург или Берлин
* Если вы уже в Европе, то можно работать из Германии или Испании
* Пока оформляются бумаги, можно начать работать из вашей текущей страны (легально)
* Даем 100€ в месяц на наш каршеринг
* Development budget, курсы немецкого
* Отпуск 30 рабочих дней
* Офис около Эльбы в Гамбурге, мимо проплывают дорогие 🛥, например эта


Подписка на Хороший разработчик знает это плюс 🙃

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

Что такое RACI матрица

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

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

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

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

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

Доступно четыре кода:

R (Responsible) — значит что человек выполняет задачу. Например, перенастраивает микросервисы, чтобы они работали с новым RabbitMQ.

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

C (Consulted) — люди с которыми нужно проконсультироваться, во время выполнения задачи. Например, разработчики одной из команд, которые используют легаси RabbitMQ кластер.

I (Informed) — сотрудники, которых нужно информировать о выполнении задачи. Например, держать всех разработчиков в курсе прогресса о миграции на новых брокеров.

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

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

Были ситуации, когда не было понятно кто должен принять решение? Как они разрешились? Пишите в комментариях.
⁠
#софтскиллы

Про онлайн тренинги

На прошлой неделе со среды по пятницу я участвовал в онлайн тренинге по Kotlin и хочу поделиться своими впечатлениями.

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

Наш тренинг должен был ознакомить разработчика с Kotlin best practices. Как это выглядело:
* Лектор рассказывает и показывает какой-то рандомный топик про Kotlin
* Основное взаимодействие с аудиторией это вопрос — все понятно? Если не понятно, то спрашивайте
* Теория разбавлена заданиями на самостоятельное выполнение
* Перерыв
* Поехали дальше, новый рандомный топик

Моей основной проблемой было удержание фокуса. Для меня это оказалось невозможным. Я не могу просто сидеть и смотреть интересное видео про Kotlin 8 часов в день, даже с перерывами. Мой attention gap намного меньше.

Что можно было улучшить, на мой взгляд:
1️⃣ У тренинга должна быть история, какая-то общая легенда, которая пронизывает все топики
2️⃣ Взаимодействие с аудиторией должно быть интерактивным. У нас было пару моментов, когда мы голосовали, но мы голосовали по темам "Перерыв должен быть сейчас или позже?" 🙃 Так легче быть вовлеченным
3️⃣ Задания нужно выполнять в парах, тогда будет сложнее поддаться соблазну их просто пропустить
4️⃣ Мы начали сразу со сложной темы — Thread safety. Зачем? Логики в этом не было никакой. Потом были менее сложные темы. Сначала надо дать участникам ощущение прогресса, чтобы они поверили в свои силы.
5️⃣ Никакого преимущества, в том, что мы проводим три дня подряд на этом тренинге, нет. Такие курсы лучше проходить медленнее и за более продолжительный срок.

Были и положительные моменты — я услышал о топиках, про которые хочется узнать больше: Offensive programming, Mutation testing, Sequences.

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

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

Вы проходили какие-то классные тренинги онлайн? Напишите о них в комментариях.

#истории

Write-ahead logging

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

А что будет, если RabbitMQ будет недоступен в этот момент и сообщение не отправиться ☠️? Можно добавить какой-то retry, можно вообще откатить транзакцию и ответить 500. Можно "потерять" это сообщение, таких случаев ожидается мало, но лучше не "терять", ведь тогда может нарушиться цельность данных в нашей информационной системе.

Есть другое решение — использовать технику write-ahead log. В таком случае, отправка сообщения будет, грубо говоря, состоять из трех шагов:

1. Записываем что нужно отправить в базу данных, в табличку events, ставим статус PENDING
2. Какой-то worker периодически проверяет эту табличку и отправляет сообщения со статусом PENDING
3. Если сообщение отправилось, ставим ему статус SENT
4. Бонус. Время от времени удаляем строки у которых статус SENT

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

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

⬛️ Еще раз — если вы хотите быть уверенными, что действие будет выполнено, используйте технику write-ahead log. Это делает программу сложнее, но стабильнее.

Реализовывали такое сами? Пишите в комментариях
⁠
#хардскиллы

Техника Pomodoro

Прокрастинация. Мы все страдаем от этого, правда? Я точно да. Думаю каждый Хороший разработчик, иногда, страдает от этого. Нужно сделать столько всего, и это все вроде бы так важно, что не знаешь с чего начать и как к этому подступиться. Поэтому жмешь Cmd + R и проверяешь есть ли что новое на Медузе.

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

Она простая, уверен, что многие о ней уже слышали:

1. Составьте список задач, над которыми вам надо работать
2. Заведите таймер на 25 минут, в течении этого времени НИ НА ЧТО не отвлекайтесь. Выключите мессенджеры. Работайте над задачей.
3. Поработали? Отдохните пять минут. Можно читать Facebook.
4. Еще раз пункт два. Завели таймер и работаем. Один такой интервал называется — помидорка.
5. После четырех помидорок можно сделать большой перерыв, например 20 минут.

Это точно работает, я проверял. Согласиться поработать 25 минут намного проще, чем согласиться с абстрактным "сделать задачу".

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

Я использую программу Be Focused - Focus Timer на Mac, все еще на бесплатной версии. Ссылка в комментариях. Мне очень помогает тиканье часов + я включаю белый шум в Spotify.

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

Уже использовали эту технику? Если использовали, напишите, пожалуйста, в комментариях свое любимое приложение.
⁠
#софтскиллы