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

Понимаю тебя. Думаю, такие мысли бывают у многих, и у меня тоже. Расскажу, что удалось осознать для себя:

🌸 Первое. Не складывай чужие достижения в одну кучу.

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

Плюс, если человек публичный, то тут уже публичность обязывает его увеличивать количество активностей.

🍀 Второе. Всегда стоит начать с целей.

А тебе это зачем?

Просто «потому что все» обычно в долгую работает плохо. Кто-то алгоритмы решает, потому что к конкретному собесу готовится. Кто-то курсы проходит, потому что хочет в ML перейти. Выступают тоже для чего-то. Для роста внутри компании или чтобы похвастаться мерчем 😃

Если твои цели другие, зачем повторять чужие шаги?

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

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

Короче, чтобы было понятно, для чего ты это изучаешь. Тогда мотивация будет 👨‍💻

🌸 Третье. У всех разные ситуации.

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

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

Когда будет нужно — поднажмёшь в конкретной области.

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

Задать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

#женя_есть_вопрос

Как мы внедряли contract first

Есть два подхода, как получить доку по API:
🔵 code first, когда сначала пишем код, потом по нему генерим спецификацию
🟢 contract first, когда сначала пишем спецификацию, затем по ней код.

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

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

«а почему так? а давайте вот так? а давай вот эту строку уже готовую на бэке сделаем»

А код-то уже написан 😭

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

Поначалу проектирование делали просто текстом, потом внедрили open api. Сначала делала это сама, потом стала в задачи бэков включать часть с проектированием.

Вообще это умеют и могут системные аналитики. Но пока в командах их не было, мы проектировали API сами.

Удобно и экономит кучу времени:

➕ можно параллелить разработку фронта и бэка, фронту не нужно ждать бэк

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

➕ тестировщики могут сразу написать тест-кейсы для бэка

Минусы у contract first такие:

➖ надо думать заранее, нельзя «просто начать писать код», как пойдет, там увидеть, что надо бы вот это добавить, а тут можно вот так, и в конце концов контракт выкристаллизуется по итогам работы

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

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

Привет, меня зовут Женя Янченко, я участник серии онлайн-митапов DIGITAL DIALOG | Карьерный трек, который пройдет с 22 по 29 апреля в онлайн-формате.

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

Моя тема: «КАК ДОГОВОРИТЬСЯ О ПОВЫШЕНИИ ЗАРПЛАТЫ»
Когда: 22 апреля в 19:00 по МСК
Где: Онлайн-трансляция в канале DIGITAL DIALOG

Спикеры:

ЖЕНЯ ЯНЧЕНКО - руководитель разработки в М.Видео, автор канала Женя Янченко. Выросла из бэкенд-разработчика, работала в эдтехе, финтехе и ритейле.

АЛЕКСАНДР РОМАНОВ - ИТ-лидер в Сбере (ex-T-Банк, Райффайзен), автор канала TeamLead говорит. Более 7 лет опыта в разработки в BigTech, 4 из которых в руководстве командами и стримами из нескольких команд.

Мы обсудим:

👉 Стоит ли вообще затевать разговор о повышении?
👉 Как подготовиться?
👉 Нужен ли другой оффер?
👉 Частые ошибки.
👉 Что делать, если отказали?

🔥 Ответим на все вопросы зрителей! Оставляйте вопросы в комментариях к этому посту до и во время эфира.

🎥 Запись будет!

Приходите узнать, как поднять свою зарплату!

Программа всей серии онлайн-митапов доступна по ссылке.

DIGITAL DIALOG

Сегодня в 19:00 буду на онлайн-митапе рассказывать, как повысить зарплату внутри компании.
У меня есть такой опыт с обеих сторон: и как у сотрудника, и как у руководителя 😼

Формат не в стиле «я с докладом», а живой диалог с ведущим. В конце ответы на вопросы, можем реальные кейсы обсудить.

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

Официальный анонс из канала, в котором будет проходить трансляция ⬇️

😱 Меня нашли издатели кабанчика

Две недели назад мне написала таинственная незнакомка. Оказалось — Елизавета, издательство «Питер». Сердце моментально ушло в пятки. Дело в том, что это они издали кабанчика на русском.

И тут как назло у меня пропадает интернет, потому что я в дороге 😱

Возможно вы встречали SmartReading и похожие сервисы, которые продают конспекты бизнес-книг.

Можно ли это делать с точки зрения авторского права?

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

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

🟢 у меня не пересказ "в целом", а выжимка того, что мне показались интересным и полезным

🟢 это конспект с разбором — я давала комментарии из своего опыта, многие примеры заменила на свои

🟢 проконсультировалась с компетентным товарищем из финансового сектора (знакомый техлид из Газпромбанка), он сказал:
отставить тряску всё будет ок
😃

🟢 я это не продаю, в блоге даже рекламы нет

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

Всё это крутилось у меня в голове, пока я ехала без связи.

А Елизавета написала следующее:

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

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

Конечно, я согласилась.

Новинки бесплатно! 😍
О чем тут думать) Разве что о том, как успевать читать побыстрее.
Можно было даже выбрать бумажную или электронную.версию. Выбрала электронную.

Под мои интересы предложили первую книгу 👇

DIGITAL DIALOG | Карьерный трек

Друзья, мы рады приветствовать вас на серии онлайн-митапов о карьерном росте! Хотите знать, как на самом деле растут зарплаты, должности и карьера в IT?

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

Без воды, только практика: личный опыт, разбор ошибок и готовые сценарии действий 🚀

Когда: 22 - 29 апреля в 19:00 по МСК
Где: Онлайн-трансляции в Telegram
Цена: Абсолютно бесплатно!

Вас ждут:

👉 Реальные кейсы от экспертов, которые знают систему изнутри.
👉 Живые ответы на ваши вопросы — ловите лайфхаки «из первых рук».
👉 Полезные материалы от спикеров.

Наши спикеры и темы:

1️⃣ 22 апреля (вторник)

Тема: «КАК ДОГОВОРИТЬСЯ О ПОВЫШЕНИИ ЗАРПЛАТЫ»

Спикер: Женя Янченко — руководитель разработки в М.Видео и автор одноимённого канала Женя Янченко расскажет, как повысить зарплату внутри компании и какие ошибки мешают это сделать.

2️⃣ 23 апреля (среда)

Тема: «КАК ВЫРАСТИ ИЗ ИСПОЛНИТЕЛЯ В ТИМЛИДА»

Спикер: Артем Харченков — лид разработки в CTSG и автор канала Артем Харченков | IT Инсайты расскажет о тонкостях перехода в тимлиды и первых шагах в новой должности.

3️⃣ 24 апреля (четверг)

Тема: «КАК ТИМЛИДУ НАЙТИ РАБОТУ»

Спикер: Никита Ульшин — тимлид в Т-Банк и автор канала Никита Ульшин про IT расскажет, когда тимлиду пора искать новую работу и как правильно это делать.

4️⃣ 28 апреля (понедельник)

Тема: «КАК ПРОЙТИ HR-ОТБОР В IT»

Спикер: Любовь Герасимова — HR в Сбере и автор канала Герасимова Любовь | Рекрутер | IT | HR научит проходить скрининг так, чтобы вас «точно» позвали на интервью.

5️⃣ 29 апреля (вторник)

Тема: «КАК ПРОЙТИ ИНТЕРВЬЮ С РУКОВОДИТЕЛЕМ»

Спикер: Александр Романов — ИТ-лидер в Сбере и автор канала TeamLead говорит расскажет, что действительно важно для руководителей при найме.

Как принять участие:

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

🔥 Это не «еще один вебинар» — это разговор с теми, кто решает! Приходите, если хотите карьеру, а не просто работу.

DIGITAL DIALOG

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

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

Митап бесплатный, проходит онлайн, по вечерам на следующей неделе. Спикеры крутые, из крупных компаний.

💵Моё выступление про деньги — 22 апреля, во вторник. Дальше ребята расскажут, как расти в тимлида, искать работу и проходить финальные собеседования.

Приходите послушать ☺️
Официальный анонс 👇

P.S. Немного подсела на «гиблификацию» фоток с помощью ChatGPT (рисовка в стиле студии Ghibli Миядзаки). А вы уже пробовали?

Подготовила конспект 11-й главы кабанчика («Высоконагруженные приложения» Мартина Клеппмана).

Глава про потоковую обработку данных. На мой взгляд, получилась такая обзорная экскурсия в музее технологий: тут у нас брокеры сообщений, там — change data capture, а это вот event sourcing. Без сильного погружения.

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

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

Ещё вспомнила, как в 2020-м у нас в платформенной команде архитектор пришёл и такой:

«А давайте Кафку в режиме COMPACT юзать»

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

Что ж, всего в книге 12 глав, мы почти закончили!

Читать конспект 11-й главы

#кабанчик #сисдиз

Приветствую!
Расскажите, пожалуйста, как вы декомпозируете задачи, верхнеуровневые требования и т.д.?
Почему-то очень редко освещают эту тему с точки зрения реальной практики, хотя новичкам это даётся непросто :(

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

Но если перед вами всё же стоит эта задача, то конечно, погнали по шагам.

😳 Шаг 1. Понять, что нужно сделать

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

Обычно этим занимается аналитик: он собирает требования, делает прототипы.

Поэтому первые задачи:

👉 Сбор и описание функциональных и нефункциональных требований
👉 Опционально разработка прототипов

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

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


🤔 Шаг 2. Проработка задачи

Одним глазом смотрим на макет и требования, а вторым — на существующую систему (схемы БД, микросервисы, их взаимодействие). И начинаем думать:
🔹 надо ли создавать новые сущности в БД?
🔹 понадобятся ли новые микросервисы
🔹 какова бизнес-логика, которую нужно реализовать
🔹 есть ли все данные внутри нашей системы или нужен полет в другую галактику
🔹 будет ли асинхронное взаимодействие
🔹 какие подводные камни по технике: дедупликация, таймауты, нагрузка и др.

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

По-хорошему это все делается в рамках отдельных задач:

👉 Разработка HLD (high-level design)
👉 Разработка LLD (low-level design)


👨‍💻 Шаг 3. Собственно декомпозиция

Теперь, когда фича проработана, она сама собой превращается в стройную кучку задач.

В силу того, что я бэкендер, задачи для фронта у меня обычно выглядят лаконично:

👉 Реализация отображения и логики функциональности такой-то согласно макету
👉 Интеграция с бэком

Для бэка задач больше:

👉 Создать скрипты для БД (таблицы, поля, индексы)

👉 Если микросервис новый — сделать каркас (подключить библиотеки, логирование, трейсинг, мониторинг, подключение к БД)

👉 Реализовать эндпойнты API (по одному на задачу)

👉 Если нужно получать сообщения из очереди — отдельная задача

Сложная интеграция? Делаем по ней отдельные задачи:

👉 Интеграция с системой N согласно контракту
👉 Реализация бизнес-логики

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

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

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

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


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

Задать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

Как у вас устроена декомпозиция задач? Занимается ли этим лид или сами разработчики или может аналитик?

#женя_есть_вопрос

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

Делюсь.
Планирую пойти 18 апреля на архитектурный митап «на Неве». Проводят МТС, Сбер, Инфотекс. Вот ссылка на пост с регистрацией в канале МТС.

С организаторами не связана, за рекламу не платили, просто делюсь планами 😊

В прошлом году была на архитектурном митапе от МТС, понравилось. Интересно, бодро, были стенды с конкурсами. Писала об этом тут.

Ох, кажется, этот пост уже побил рекорд по количеству ссылок 👀

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

Если тоже придёте — давайте пересечёмся, мне будет очень приятно познакомиться вживую! 🥰 Увидите, что я не кот 😁

Алгозадачи: мартовский апдейт

Пошёл третий месяц, как решаю алгоритмы. Затеяла амбициозное — 300 задач за год. Сейчас 61/300, за март осилила 31 штуку. Решала на темы: stack, linked list, binary search.

Выводы по итогам второго месяца:

1️⃣ Если встретите упоминание, что привычка формируется за 21 день — смейтесь нагло и громко. Решаю уже 2 месяца и с сожалением констатирую, что привычка пока не выработалась. Мне интересно начинать новую тему (в том числе потому что она начинается с easy задач). А вот продолжать с medium уже не так интересно. Пропускаю дни, потом героически догоняю. Привычка пока не работает, держусь на мотивации и силе воли 🫠

2️⃣ Если раньше вы уже решали задачи на какую-то тему, то она пойдет ощутимо легче. У меня так оказалось с linked list. Раньше разбиралась с ним, реализовывала сама, даже на собесе как-то его давали. Поэтому задачи на linked list пошли у меня немного легче 👨‍💻

3️⃣ По-умолчанию мозг работает не как жесткий диск, а скорее как оперативка. Февральские задачи уже как будто решала не я, а мой двойник из параллельной вселенной: не могу сходу вспомнить решения для многих задач 😭 Нужно повторять задачи, чтобы они откладывались в долговременной памяти.

В апреле планирую не брать новых тем. Буду повторять уже изученное и решённое. Хочу попробовать карточки, нужно разобраться, как их делать для алгозадач. Постараюсь решить 10-15 новых задач на уже изученные темы ✌️

#челлендж_алгоритмы

Кто в команде главный

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

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

То есть отвечал за то, «что делать». Иначе это называют дискавери.

Я же занималась проектированием (техрешение, API, БД), декомпозировала фичи на задачи, писала код, делала ревью, разруливала вопросы, релизила, общалась с девопсами.

То есть отвечала за «как делать». Это называли деливери.

Структуры команд бывают разные. Где-то лиды внутри команд, а где-то их выносят отдельно — например, один лидер фронта и лидер тестирования на несколько команд.

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

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

— Я бы не стал отчитываться джуну!

Я ему:

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

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

Но тот коллега в чате жил в строгой иерархии и признавал авторитет только вышестоящего начальства. Поспорили мы с ним немного, но так и остались каждый при своем мнении 🤷‍♀️

А как устроено у вас в команде? Вам ок, если продакт или проджект — джун, или вас это напрягало бы?

Подборка мемов в честь дня смеха :)

Как произвести крутое впечатление на тех собесе

Договорилась написать посты о собеседованиях с Николаем — старшим системным аналитиком из Сбера. Мой пост о хард-скиллах, а Колин — о софтах.

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

Однако есть способ, который поможет показать, что мы не просто зазубрили ответы на 100 вопросов с собедований, а реально что-то умеем.

Готовимся как профи

Учить теорию — это база, но нам надо пойти дальше. Вспоминаем:

✅ реализованные задачи на текущем месте работы
✅ интересные случаи, когда вы раскрутили какую-то проблему
✅ какие-то фейлы (лучше те, что удалось исправить без последствий)
✅ как устроен ваш текущий проект, что удобно, а что — боль и страдания

На самом собесе

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

✏️ Пример

Задают вопрос про синхронное и асинхронное взаимодействие.

Добавляем к ответу описание практического опыта:

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

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

✏️ Другой пример

Дают задачу на SQL и спрашивают, часто ли приходится писать на чистом SQL.

Для разработчика:

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

Или:

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

Для аналитика:

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

Зачем так делать?

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

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

🔹 Бонус-прием: если читали по теме классную статью или книгу — скажите об этом! Это покажет вас человеком, который не просто вбивает любые вопросы в ChatGPT, а реально прокачивается сам.

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

А как можно ответить на частые вопросы по софт-скиллам — читайте у Коли, в канале Обыкновенный айтишник.

А у вас есть свои рабочие приемы для техсобесов?

Вчера ходила на митап Сбера про бизнес-процессы, BPM-системы и использование AI.

Ведущий бодро начал:

«Автотестировщики больше не нужны, AI уже отлично пишет тесты на Селениуме»

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

Мне понравился первый доклад — про нотацию BPMN и автоматизацию процессов. Я когда-то давно этим занималась. Плюс очень харизматичный спикер — архитектор с большим опытом.

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

Теперь важное. Кормили отлично. Нет, я не ради еды хожу на митапы (или ради еды? 🤔), но хорошая организация кофе-брейка — это уважение ➕

Мне было интересно посмотреть на офис Сбера в Питере. Я работаю на удалёнке уже больше 5 лет, и 🔥 Однако с текущей тенденцией к гибриду стало интересно посмотреть на офисы крупных компаний. В прошлом году была в VK и в Юмани.

Увы, особо посмотреть сам офис не получилось, мы были в отдельном зале. То, что я увидела — понравилось. Всё очень современно и удобно. Стулья в зале были на колесиках! Можно вставать и садиться, не мешая соседям. Комфорт уровня «сервис для котов» 🤪

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

Что вам больше нравится: удалёнка или гибрид? Если вы удалёнщик, рассмотрели бы офис за бóльшую зарплату?

Подготовила конспект 10-й главы кабанчика («Высоконагруженные приложения» Мартина Клеппмана). Глава про пакетную обработку, и честно говоря она показалось мне скучноватой по двум причинам:

🔵 у меня не было практического опыта с пакетной обработкой
🔵 большая часть главы посвящена MapReduce, а это уже устаревшая технология (про некоторые преимущества более современных Spark и Flink будет в конспекте).

Зато часть главы про конвеерные операции в Unix всколыхнула во мне воспоминания. На второй работе разработчиком в офисе у всех стояла Fedora. Тимлид объяснил это так:

На сервере у нас CentOS, это наиболее близкий к нему дистрибутив

🫤

Это был 2019 год, докер у нас тогда был только для контейнерных тестов. Хорошо, что тогда я и сама сидела на Linux Mint, так что от Fedora офигела не на 100%, а всего лишь процентов на 80 🤣
Как же там всё отличалось от Mint и тем более от винды!

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

Кстати, тот же тимлид показал мне работу с Postgres через командную строку (до этого я пользовалась DBeaver), и я полгода страдала с ней, думая, что тру-программисты работают только так. А потом коллега-сеньор показал мне, что сидит через плагин IDE. Мою реакцию можно было описать мемом

А что, так можно было?

Я попробовала, и это было настолько удобнее даже Dbeaver, что с тех пор пользуюсь только Database Tools and SQL в Idea.

Вернёмся к кабанчику. Решила не делить главу на отдельные посты, а сделать сразу большим постом в телеграф. Спасибо подписчику Стасу, который это предложил! ❤️

Читать конспект 10-й главы

#кабанчик #сисдиз

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

Вопрос прямо как с собеса 😉
Если бы я оказалась у руля, то сделала бы так:

1️⃣ Выясняем, что реально важно

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

2️⃣ Рисуем карту кодовой базы

Созываем лидов, рисуем архитектурную схему:
🔵 какие микросервисы/модули есть
🟣 за что отвечают
🟢 как общаются
🟡 где какие базы и что в них лежит
🟣 какие есть проблемы (техдолг можно собирать постепенно)

3️⃣ Делаем star map

Это табличка, в которой отмечаем, кто насколько шарит в каком сервисе (0 – никогда не сталкивался, 3 – кодил с закрытыми глазами).

Видим пробелы, понимаем, кто в чем эксперт 😎

4️⃣ Режем слона на части

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

5️⃣ Фокусируемся на приоритетах

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

6️⃣ Чиним процессы

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

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

7️⃣ Разбираемся с техдолгом

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

8️⃣ Автоматизируем, что можно

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

9️⃣ Проводим регулярные демо для бизнеса

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

Растёт прозрачность -> растёт доверие. Жизнь налаживается 😊

Все перечисленные приемы в разное время проверяла на практике.

Задать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

Ребят, что бы вы предложили для такой ситуации?

#женя_есть_вопрос

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

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

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

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

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

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

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

Как вы относитесь к работе в казино/ставках/etc?

#женя_есть_вопрос

Выношу оглавление книги с кабанчиком («Высоконагруженные приложения» Мартина Клеппмана) в отдельный пост.

📎 Глава 1 Надежные, масштабируемые
и удобные в сопровождении
приложения

📎 Глава 2 Модели данных и языки запросов

📎 Глава 3 Подсистемы хранения и извлечения данных
🔵Введение и хэш-индексы
🔵Уплотнение и слияние в LSM
🔵SS-таблицы и LSM-деревья
🔵B-деревья
🔵Сравнение B- и LSM-деревьев
🔵OLAP и OLTP

📎 Глава 4 Кодирование и эволюция
🔴Форматы сериализации данных
🔴Режимы движения данных

📎 Глава 5 Репликация
🔵Репликация с одним лидером, способы реализации репликации
🔵Синхронная и асинхронная репликация
🔵Проблемы при задержке репликации
🔵Репликация с несколькими лидерами
🔵Стратегии работы с конфликтами записи
🔵Репликация без лидера
🔵Операции записи и чтения по кворуму

📎 Глава 6 Шардирование
🔴Как распределять по шардам данные
🔴Вторичные индексы при шардировании
🔴Ребалансировка шардов

📎 Глава 7 Транзакции
🔵Концепция транзакций
🔵Уровень изоляции Read Committed
🔵Уровень изоляции Repeatable Read
🔵Асимметрия записи и фантомы
🔵Уровень изоляции Serializable

📎 Глава 8 Проблемы распределенных систем
🔴Ненадежные сети
🔴Ненадежные часы
🔴Истина и ложь в распределенных системах

📎 Глава 9 Согласованность и консенсус
🔵Линеаризуемость
🔵Гарантии упорядоченности
🔵Двухфазный коммит
🔵Консенсусные алгоритмы

📎 Глава 10 Пакетная обработка
📎 Глава 11 Потоковая обработка

#кабанчик #сисдиз

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

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

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

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

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

✍️ К разговору стоит подготовить краткий рассказ, что вы сделали за прошедший месяц.

На встрече вы рассказываете, что сделали и спрашиваете:

Я нормально двигаюсь? Может на что-то дополнительно обратить внимание?

И тут лиду придется какую-то обратную связь вам дать 🙂

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

📌 Важный момент. В команде бывает несколько руководителей (техлид, тимлид, продакт-менеджер, проджект-менеджер и др.). В этом случае стоит держать руку на пульсе отношений с каждым из них, особенно на испытательном сроке. Будет неприятно, если по технической части у лида вопросов не будет, а менеджер усмотрит какой-то «недостаток мотивации» 😵‍💫
Поэтому на испытательном сроке можно предлагать встречи всем, кто имеет какое-то отношение к руководству командой.

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

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

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

Разраб приходит в команду. Его никто толком не онбордит. Ну не джун же, сам разберется, не маленький. Ему поручают задачи. Он их делает. Лид никакой обратной связи не дает. Работа выполняется, задачи закрываются, фичи едут на прод. Спустя время к человеку приходит HR и говорит: «ты не оправдываешь ожиданий, мы тебя выводим из команды». Знаю уже пару таких ситуаций. У одного знакомого такое случилось через полгода работы в команде 🤯

В смысле? А почему лид молчал все это время, что что-то не так?

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

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

Долго делает?

👉 Узнать, почему.
Может ему постановку меняют каждый день, и он каждый день переделывает. Может он ждёт чего-то от другой команды, девопса, DBA и др.

👉 Предложить ресурсы для помощи.

👉 Явно проговорить, что сроки важны.

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

А что тогда пипл менеджмент? Табличку с отпусками запинить в рабочем чате? ❌

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

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

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

Как вы считаете? Встречали такие ситуации в вашем окружении?

Девочки, поздравляю с 8-м марта! 🌷

Желаю, чтобы коллеги восхищались красотой ваших решений и элегантностью вашей архитектуры.

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

Пусть всё сложится лучше, чем вы мечтали!

С праздником! 😘

Евгения, здравствуйте! Есть вопрос к Вам и заодно послушать мнение публики. Кто и как сейчас учится? Интересует по большей части чтение книг и как именно их читают?
1) просто читают
2) читают и прорабатывают все примеры
3) читают, прорабатывают примеры, конспектируют (именно конспект, а не переписывание книги)

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

Но такой подход очень долгий, на чтение книги 800+ страниц уходит 4-5-6 месяцев.

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

Здравствуйте!
У вас вдумчивый и грамотный подход, который дает максимальный результат. Очень круто, что у вас есть мотивация так действовать!

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

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

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

Лет 5 назад на собеседовании у меня спросили:

— Какую книгу по специальности вы сейчас читаете?

В тот период я как раз узнала про книгу Effective Java Джошуа Блоха и собиралась ее прочитать, но на момент собеседования еще не успела начать. Зато тогда я читала «Дюну» Фрэнка Герберта. Поэтому когда меня спросили про книгу, я слегка занервничала, ведь от меня ждали книгу по специальности, а в голове крутились только песчаные черви Арракиса, начисто вытеснив из памяти остальное 🤣

И тут я вспоминаю про Effective Java и выпаливаю, что начала читать ее. Тут же следом думаю: зачем я это сказала? А если меня сейчас что-нибудь спросят по ней? Вдруг там что-то такое в самом начале? 🙈

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

После этого собеса я сразу же взялась за Effective Java 🙂

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

Поделитесь, пожалуйста, вашими подходами к получению знаний: книги, статьи, видео, курсы, каналы/чаты, ChatGPT? Делаете ли конспекты? Как боретесь с забыванием информации?

Прислать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

#женя_есть_вопрос

Евгения, здравствуйте! Есть вопрос к Вам и заодно послушать мнение публики. Кто и как сейчас учится? Интересует по большей части чтение книг и как именно их читают?
1) просто читают
2) читают и прорабатывают все примеры
3) читают, прорабатывают примеры, конспектируют (именно конспект, а не переписывание книги)

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

Но такой подход очень долгий, на чтение книги 800+ страниц уходит 4-5-6 месяцев.

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

Здравствуйте!
У вас вдумчивый и грамотный подход, который дает максимальный результат. Очень круто, что у вас есть мотивация так действовать!

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

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

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

Лет 5 назад на собеседовании у меня спросили:

— Какую книгу по специальности вы сейчас читаете?

В тот период я как раз узнала про книгу Effective Java Джошуа Блоха и собиралась ее прочитать, но на момент собеседования еще не успела начать. Зато тогда я читала «Дюну» Фрэнка Герберта. Поэтому когда меня спросили про книгу, я слегка занервничала, ведь от меня ждали книгу по специальности, а в голове крутились только песчаные черви Арракиса, начисто вытеснив из памяти остальное 😬

И тут я вспоминаю про Effective Java и выпаливаю, что начала читать ее. Тут же следом думаю: зачем я это сказала? А если меня сейчас что-нибудь спросят по ней? Вдруг там что-то такое в самом начале? 🙈

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

После этого собеса я сразу же взялась за Effective Java 😅

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

Поделитесь, пожалуйста, вашими подходами к получению знаний: книги, статьи, видео, курсы, каналы/чаты, ChatGPT? Делаете ли конспекты? Как боретесь с забыванием информации?

Прислать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

#женя_есть_вопрос

Чек-лист: что проверить перед интеграцией

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

Всё может пойти не так! Каждое поле из таблички может оказаться не тем, за кого себя выдает. А брокер может оказаться вообще в другом кластере 😵‍💫

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

✔️ Формат даты времени

Примеры:

▶️Ваша система ожидает дату в ISO формате YYYY-MM-DD (год-месяц-день), а она приходит в формате DD/MM/YYYY (день/месяц/год)

▶️Также могут сыграть роль миллисекунды:
2025-03-05T14:30:00 или
2025-03-05T14:30:00.123Z


✔️ Строка vs список строк

Пример:

Мы ждём
currency: “RUB”

А приходит
currency: [“RUB”]

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


✔️ Уникальность полей

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

💡Стоит уточнить даже про поле id, которое к вам приходит, уникально ли оно.

Например, один API принимал запросы на обработку, а в ответ для последующей проверки статуса отдавал не уникальные id. При попытке получить статус по такому id ругался на ошибку уникальности. Сам выдал, сам ругался 🤷‍♀️


✔️ Заполненность обязательных полей

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

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


✔️ Версии API и библиотек

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

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


✔️ Адрес брокера

Если коллеги отправили данные, а вы их не видите у себя, стоит сверить адрес брокера и название очереди (топика Кафки).

В названии банально могла закрасться опечатка.

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


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

Сталкивались ли вы с чем-то из списка или может у вас были другие ситуации ?

Отчет по челленджу за февраль

5 февраля я объявила себе челлендж по алгоритмам: хочу решить 300 задач на литкоде до конца года.

За месяц я решила 30 задач (было 44, стало 74) 🕺
Решала на темы «Два указателя», «Скользящее окно» и начала «Стэк». По сложности: easy и medium. Харды пока не смотрела.

Хотелось бы рассказать красивую историю, как я каждый день решала по задачке, но увы) Я пропускала дни, поэтому в другие дни приходилось наверстывать и решать по 2-3 задачи, особенно ближе к концу месяца. Хотелось не ударить лицом в грязь 👨‍💻

Первая картинка к посту наиболее правдоподобно отражает мое состояние.

Было нелегко. Все же у меня пока не набита рука на такие задачи.

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

Если нужно смотреть объяснения, то я делаю это на довольно известном сайта neetcode.io, потому что его автор как раз сначала объясняет на квадратиках и стрелочках, а потом в конце пишет код на Python, и часть с написанием кода можно не смотреть и писать самой (а потом сломаться на каком-нибудь edge-кейсе 😄)

Инсайты по итогам первого месяца:

📎 Оказывается, если массив в задаче изначально не отсортирован, а хотелось бы, то можно его первым делом отсортировать. А что так, можно было??? 😱

📎 Полезно как можно раньше разобраться и даже запомнить, как пишется в коде тот самый паттерн (вот такие переменные нужны, вот так инициализируем, вот такое условие проверяем в цикле и др.) Тогда при решении можно сосредоточиться именно на особенностях задачи, а не на написании стандартной части паттерна 👨‍💻

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

Что ж, впереди новый месяц 👍

#челлендж_алгоритмы

Женя, расскажи, пыталась ли ты проходить собеседование в FAANG или Яндекс? Зачем они так сильно душат по алгоритмам, ведь сейчас есть фреймворки и ORM, которые сами отсортируют как надо все и быстро

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

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

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

1️⃣ Придумывать релевантные работе задачи здорово, но это затратно по времени: нужно следить за утечками и постоянно обновлять банк задач. А алгозадач на том же литкоде уже 3000 штук!

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

2️⃣ Дополнительный плюс для таких компаний — это проверка мотивации кандидатов.

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

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

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

4️⃣ Есть еще момент насчет равенства коллег 🤝 Работая в фаанг-компании, ты знаешь, что все твои коллеги прошли через тот же самый фильтр. Никого не взяли по блату или только за хорошие коммуникативные навыки. Все решали алгосы. Это дает ощущение «своей стаи». Хорошо работает для повышения лояльности.

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

Где-то готовы брать человека на частично новый для него стек и дать ему месяц-два на раскачку, а где-то хотят, чтобы человек уже имел большой опыт конкретно с MongoDB, например. Где-то нужен человек, который будет готов сам прорабатывать задачи от бизнеса, а где-то — тот, кто не демотивируется, что «аналитик все решил за него» 🫠

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

Ребят, а как вы думаете, зачем такие собесы?
Вернут ли компании решение задач в офисах на досках из-за ИИ у кандидатов или придумают новый подход для собесов?

Прислать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

#женя_есть_вопрос

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

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

Что значит консенсус среди узлов? Это значит, несколько узлов пришли к согласию по какому-то вопросу.

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

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

Однако если лидер выйдет из строя, то всё, система больше не сможет принимать решения.

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

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

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

Наиболее известные отказоустойчивые алгоритмы консенсуса:
🟣Paxos
🟣Raft

🤝 Нумерация периодов и кворумы

Для работы консенсусного алгоритма нужен ведущий узел. В алгоритме Paxos такие узлы называются proposers, в Raft — лидеры. Чтобы не было конфликтов, кто сейчас является лидером, консенсусные алгоритмы используют систему периодов: для каждого периода времени определяется свой лидер.

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

Чтобы стать лидером, узел должен собрать голоса кворума узлов. Обычно кворум состоит из большинства узлов (2 из 3, 3 из 5 и др.). Узел голосует за предложение только если ему неизвестен другой лидер с более высоким номером периода.

🤨 Ограничения консенсуса

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

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

✔️ «Аутсорсинг» консенсуса

Допустим, нашей системе нужен алгоритм консенсуса. Сначала у нас было 3 узла, потом 5, потом мы выросли до системы с тысячами узлов. Попытка получить большинство голосов на таком количестве узлов будет совершенно неэффективной. Вместо этого удобно использовать для задач консенсуса уже готовый сервис, например хранилища ZooKeeper, Google Chubby.

ZooKeeper работает на фиксированном количестве узлов (3 или 5) и может «аутсорсить» услуги консенсуса для внешнего сервиса с большим количеством узлов.

Когда это может понадобиться?

👉 для определения ведущего сервиса среди нескольких, например, нового ведущего узла при репликации с одним лидером

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

Хранилище etcd, которое использует Kubernetes, тоже основано на консенсусном алгоритме Raft.

Ух, на этом мы закончили главу 9 🔥 Всего в книге 12 глав, ссылки на разобранные есть в закрепе.

#кабанчик #сисдиз

CAP-теорема простыми словами

«Быстро, качественно, дёшево» — выберите любые два.

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

🔤 (consistency) — согласованность. Каждое чтение даст вам самую последнюю запись.

🔤 (availability) — доступность. Каждый живой узел всегда успешно выполняет запросы (на чтение и запись).

🔤 (partition tolerance) — устойчивость к разделению. Даже если между узлами нет связи, система продолжает работать.

Однако потеря связи между узлами — это не что-то, что мы можем «выбрать» или «не выбрать». Распределенная система на то и распределенная, что ее узлы связаны по сети, а сети ненадежны, могут возникать “разрывы”. Поэтому распределенная система по-умолчанию «выбирает» partition tolerance.

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

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

Если в этом случае оба узла перестанут принимать запросы на запись, чтобы данные на них не разъехались в отсутствии связи, то это CP-система.
✔️ Мы сохранили согласованность: каждый запрос на чтение возвращает актуальные данные (мы же запретили их менять по-отдельности 🤪, значит они остаются актуальными на обоих узлах).
✖️ Но при этом отказались от доступности: запросы на запись мы не выполняем.

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

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

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

👀 PACELC-теорема

Ее можно назвать расширением CAP-теоремы. Звучит она так:

Если присутствует
🔤 Partition Tolerance, то выбираем между
🔤 Availability и
🔤 Consistency (это как в CAP)
🔤 Иначе (else), когда нет сетевого сбоя, выбираем между
🔤 Latency (скорость ответа) и
🔤 Consistency.

😱 Google сломал CAP-теорему

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

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

Если кабель перережут, то Spanner выберет согласованность, то есть технически это CP система.

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

Ребята, поздравляю вас с праздником!

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

Желаю прийти к своим целям и чтобы все получалось так, как вам хочется!

Спасибо, что вы есть. Оставайтесь сильными, мужественными и замечательными.

С праздником! 🤗

Женя, не пробовала ли ты использовать в работе новые нашумевшие ИИ помощники: Copilot, Qwen 2.5? Они уже пишут код на уровне сеньоров, максимально быстро и качественно. Не кажется ли тебе, что скоро столько программистов будет не нужно?

Привет!
В Intellij Idea у меня какое-то время работал ассистент, по ощущениям — как очень продвинутый автокомплит. Селф-хостить я пока не пробовала, так как завести LLM с большим количеством параметров на моем ноутбуке проблематично.

Поэтому, как все, использую Claude, DeepSeek и ChatGPT для отдельных локальных задач.
Несмотря на то, что Claude считается андеграундным лидером среди чатов для кода, а DeepSeek — очень перспективным новичком, в моих задачах пальму первенства по качеству ответов по-прежнему удерживает ChatGPT.

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

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

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

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

В целом, у меня достаточно сдержанное отношение к хайпу вокруг замены разработчиков на ИИ. Пока что в наблюдаемой части вселенной замедление роста зарплат и снижение количества вакансий связано с экономической ситуацией в стране и мире 🤷‍♀️

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

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

Также и внедрение LLM изменит работу программиста, а не заменит его.

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

Задать вопрос для рубрики можно здесь: https://forms.gle/SPE6NEALG9vcnF3s7

Как на ваш взгляд, нас заменит ИИ?
Как вы сейчас его используете?

#женя_есть_вопрос

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

— Жень, вот ты часто грамотные вещи говоришь, но ты так неуверенно их говоришь, что все впечатление портится.

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

Тем не менее, слова тестировщика неприятно удивили меня. Я-то думала, что коллегам не видна моя неуверенность и я просто выгляжу вежливой 😅

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

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

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

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

Продолжала активно учиться и работать.

На архитектурных обсуждениях стала задавать вопросы в стиле «А можем ли мы сделать вот так: … ?»

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

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

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

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

Двухфазный коммит (2 Phase Commit)

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

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

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

🔽🔼Алгоритм двухфазного коммита:

1️⃣ Приложение запрашивает
у координатора ID распределенной транзакции.

2️⃣ Приложение выполняет нужные операции (чтение, запись) в нескольких узлах БД.

3️⃣ Когда приложение готово к фиксации, координатор отправляет каждому узлу запрос готовности коммита, помеченный глобальным ID транзакции. Это начало фазы 1.

4️⃣ Узлы-участники отвечают, готовы ли они коммитить транзакцию (да/нет). Координатор отслеживает ответ.

5️⃣ 🙂 Если все узлы-участники ответили «да», то координатор записывает решение в журнал и отправляет участникам запрос коммита. Это начало фазы 2.

☹️ Если один из участников ответил «нет», то в фазе 2 координатор отправляет всем узлам запрос на роллбэк.

6️⃣ Узлы-участники выполняют коммит или роллбэк.
‰
Клепманн пишет, что процесс двухфазного коммита похож на церемонию бракосочетания: регистратор сначала спрашивает отдельно невесту и жениха, хочет ли каждый из них вступить в брак, и обычно получает от обоих ответ «да». Получив подтверждения от обоих, он объявляет их мужем и женой: транзакция зафиксирована. Если же невеста или жених не скажет «да», то церемония прерывается.

☄️ Отказы в фазе 1 и 2

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

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

💥 Отказ координатора

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

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

Транзакция узла-участника в таком состоянии называется сомнительной или неопределенной.

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

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

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

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

🤔 На практике

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

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

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

#кабанчик #сисдиз

Женя, что ты думаешь по поводу сертификации айтишников? будем экзамены теперь сдавать?

Вчера по пабликам была новость про сертификацию. Я посмотрела официальный канал Минцифры, там написано следующее:

ИТ-специалисты смогут бесплатно пройти тестирование и подтвердить свои компетенции на отечественной платформе. Эксперимент по её внедрению начнётся 14 февраля 2025 года и продлится до конца 2026 года.

С 31 мая 2025 года любой желающий, независимо от уровня образования, сможет пройти тесты и выполнить практические задания. В этом году на платформе планируется разместить материалы по 21 направлению (Python, Java, Git и др.).

Если специалист успешно пройдёт испытания, сертификат появится в личном кабинете на Госуслугах. Срок действия сертификата — один год.

Если этот эксперимент не заглохнет (а такое тоже может быть), то развитие может пойти по одному из двух знакомых нам вариантов:

😼 как сертификаты от Oracle

У них была целая линейка. Я сдавала по своей инициативе в 2019 году весной на Oracle Certified Associate, а осенью — на Oracle Certified Professional.

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

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

Но в остальном для трудоустройства они не были важны.

😼 как сертификаты от 1С

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

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

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

▶️Либо будет важна для ИТ-аккредитации компании, и тогда затронет больше людей, т.к. ИТ-компаний много.

Тогда развернется отдельная отрасль подготовки к этой сертификации. Возможно, самое время стартовать свой проект на эту тему 🚀

Сейчас в этой новости меня смущает только срок действия — один год. Работающему человеку пресдавать тест каждый год или сдавать каждый раз перед выходом на рынок — явный перебор 🤷‍♀️

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

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

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

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

Что вы думаете по поводу этой новости?

#женя_есть_вопрос

⭐️ Гарантии упорядоченности

➡️ Причинно-следственная согласованность

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

Например, история Git похожа на график причинно-следственных зависимостей.

➡️ Упорядоченность по порядковым номерам

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

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

В случае репликации с одним лидером мы спокойно присваиваем номера операциям на лидере и передаем их на реплики.

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

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

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

Например, у нас всего 2 узла. Счетчик одного генерит четные номера, другого — нечетные. Они не смешаются и не создадут проблем. Но можем ли мы сказать, что операция 115 была позже операции 100? Не всегда, ведь нечетный узел может обрабатывать запросы быстрее (в силу своей мощности или легкости запросов). В итоге 115-я операция с нечетного узла могла произойти раньше 100-й операции с четного узла.

💡Для решения проблемы упорядоченности есть метод временных меток Лампорта:

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

➡️ Рассылка общей последовательности

Рассылка общей последовательности — это протокол обмена сообщениями между узлами. Он требует выполнения двух пунктов:
‰
‰✅ Надежная доставка. Ни одно сообщение не должно быть потеряно. Если сообщение доставляется одному узлу, то оно доставляется всем узлам.
‰
‰✅ Полностью упорядоченная доставка. Сообщения доставляются во все узлы в одном и том же порядке.

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

Где используется рассылка общей последовательности:

🟡для репликации БД

🟡в сервисах консенсуса (ZooKeeper и др.)

🟡для реализации сервиса блокировки, которая предоставляет ограждающие маркеры

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

#кабанчик #сисдиз

Начинаем следующую главу кабанчика («Высоконагруженные приложения» Мартина Клепманна): глава 9 «Согласованность и консенсус».
Первая ее часть посвящена рассмотрению различных гарантий. Скажу честно, глава скучновата и академична 🙁

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

⭐️ Конечная согласованность (eventual consistency)

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

Однако это очень слабая гарантия. Мы не знаем, когда именно реплики сойдутся. До этого момента операции чтения могут возвращать разные данных с разных реплик. Поэтому придумывают подходы вроде «read-your-writes», рассмотренные в главе про репликацию.

⭐️ Линеаризуемость

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

Рассмотрим пример нелинеаризуемой системы.

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

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

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

Однако цена линеаризуемости — производительность. Линеаризуемость всегда медленная! Поэтому на практике редко делают линеаризуемые системы.

#кабанчик #сисдиз

Продолжение 👇

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

Сегодня увидела мем, который напомнил мне историю времен работы в платформенной команде. При развертывании приложения у меня возникала ошибка с нахождением keystore (хранилище сертификата для подключения по SSL). Я тогда перечитала весь интернет на тему keystore/truststore, а ошибка оказалась в пробелах в yaml файле 🤦‍♀️
Жаль у меня не было такого инструмента 😄

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

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

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

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

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

1️⃣ Показать, что ты разделяешь, то, что важно для них:

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

2️⃣ Обозначить, как текущее состояние конфликтует с тем, что важно:

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

3️⃣ Подчеркнуть, что не хочешь проблем продукту, хочешь наоборот улучшить скорость доставки новых фич:

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

Вряд ли получится отстоять подход, чтобы вам дали месяц-два-три на техдолг. Кажется, что проще «продать» выделение части времени спринтов.

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

4️⃣ Если выделение части времени будет согласовано, на следующих встречах с бизнесом стоит презентовать то, что сделано в терминах пользы для дохода продукта:

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

- переработали модуль такой-то, благодаря чему число жалоб в техподдержку снизилось на …
(и добавляешь это себе в резюме 😎)

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

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

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

Будет здорово, если потом напишешь, что получилось.

Задать вопрос для рубрики можно здесь: https://forms.gle/SPE6NEALG9vcnF3s7

#женя_есть_вопрос

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

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

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

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

Мотивация примерно следующая: "Принесёт пользу, тогда потом сделаем нормально, не принесёт, то мы зря потратим время".

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

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

Проблемы сдвигаются с мёртвой точки, только если начинать публично и агрессивно требовать: "Заявляем, что мы отказываемся так работать, если у нас не будет сколько-то ресурсов на ремонт сейчас, то завтра продукт развалится"

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

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

Или смысла во всём этом нет, проще принять, что это не твоя ответственность и сменить проект пораньше, пока все не начало разваливаться?

Отвечаю ниже 👇

Мой челлендж про алгоритмы

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

А недавно заметила, что после праздников стала решать значительно меньше. Все время находятся дела поважнее 😄

Хочу поддержать свою внутреннюю мотивацию внешней — взять челлендж решить за год 300 задач.
Сейчас у меня на литкоде решено 44 задачи.

🤨 Считаю ли я, что алгозадачи на собесах — это хорошо?

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

На собесах, где я нанимаю, алгоритмы не спрашиваю.

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

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

🤔 Зачем мне это нужно?

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

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

Поэтому решила сделать для себя челлендж по алгоритмам. Заявляться на какую-то разбивку по сложности задач easy/medium/hard заранее не буду, потому что 300 за год для меня уже звучит очень амбициозно.

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

#челлендж_алгоритмы

Сегодня заканчиваем 8-ю главу кабанчика («Высоконагруженные приложения» Мартина Клепманна) про проблемы распределенных систем.

Ссылки на предыдущие части в закрепе. В этой части речь идет о понятиях «истины» и «лжи» в распределенных системах.

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

Обычно кворум представляет собой большинство от более чем половины узлов (хотя есть и другие разновидности). Он позволяет системе работать в случае сбоев отдельных узлов: при 3-х узлах допустим отказ 1-го, при 5 — отказ 2-х.

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

Подробнее кворумы будут рассмотрены в следующей главе при обсуждении алгоритмов консенсуса.

🟢 Ограждающие маркеры

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

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

Для решения этой проблемы добавим к договору аренды ограждающий маркер (fencing token). Маркер представляет собой номер, наращиваемый при каждом предоставлении блокировки (например, его может наращивать сервис блокировок). А клиенты при отправке запроса на запись теперь будут включать в запрос такой маркер.

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

💥 Византийские сбои

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

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

Задача византийских генералов

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

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

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

Также имеет смысл добавить механизмы защиты от слабых форм «лжи» — некорректных сообщений из-за ошибок ПО, неправильных настоек или аппаратных проблем.
Это могут быть:
🟠 контрольные суммы в сообщениях
🔴 проверка корректности вводимых пользователем данных, в том числе ограничение длины строк
🔴 синхронизация времени по нескольким серверам точного времени

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

#кабанчик #сисдиз

Здравствуй, Женя!) Реально ли стать джуном на полставки, если глаза горят, готов работать за охапку черемши и вообще ты молодечек, но прямо сейчас не можешь уйти со своего места работы из-за контракта (но очень хочешь и сделаешь это при первой же возможности)?

Привет!
Конечно, вакансий джунов сейчас мало. На полставки тем более. Но есть несколько вариантов, которые можно попробовать.

Я бы не стала в такой ситуации искать работу на агрегаторах вроде 🔖 Мне кажется, если будет вакансия на полставки, то у нее будет много откликов. Либо джунов, либо ребят, которые ищут подработку.

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

Как бы я действовала:

✔️ Если дело происходит в регионе, посмотрела бы на 🔖 какие местные компании вообще публикуют вакансии с моим стеком и сходила бы туда лично с распечатанным резюме.

Олдскул? 💯 Но при таком подходе появляется возможность лично пообщаться с hr и произвести хорошее впечатление. Также вопрос полставки лучше обсуждать лично.
Я бы заранее отрепетировала самопрезентацию и формулировку, почему им стоит меня нанять.

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

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

Из чата джавистов:

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

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

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

✔️ Отклики на вакансии из телеграм-каналов с прямым контактом рекрутера. Если откликаться, то лучше там, где есть возможность написать рекрутеру лично. Если ответы на первые вопросы рекрутера подойдут под вакансию, то дальше возможен уже HR-скрининг (кстати, они сейчас могут задавать технические вопросы, будь готов).

✔️ Не искать другую компанию, а написать проект на своей текущей работе. В идеале, если на работе есть свой IT-департамент с подходящим стеком. Но даже если нет, можно автоматизировать какую-то часть своей текущей работы. Собрать требования, написать ТЗ, спроектировать решение, декомпозировать его на подзадачи, реализовать. Лучше взять ментора, который подскажет best practices и сделает ревью кода.

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

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

У меня было несколько постов про это, возможно будет полезно:

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

Найти первую работу в новой сфере нелегко. Нужно проявить упорство, не опускать руки при неудачах и пробовать еще и еще. Уверена, у тебя обязательно получится! ❤️‍🔥

Задать вопрос для рубрики можно здесь: https://forms.gle/SPE6NEALG9vcnF3s7

Почитать другие ответы можно по тегу
#женя_есть_вопрос

Про дизайн-ревью

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

👨‍🎓 Разработчик анализирует задачу и описывает текстом, как планирует ее делать (возможны схемы, open-api, json и др. в зависимости от задачи).

🧑‍🎓 Полученный дизайн-док согласовывается с лидом. Приветствуется, чтобы остальные участники команды также читали дизайн-док (как раз шаринг знаний о проекте).

🤨 Если человек что-то понял неправильно, то это будет видно в дизайн-доке и решено еще до написания кода.

👨‍💻 Код пишется только после согласования дизайн-дока.

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

Такой подход называют дизайн-ревью. Впервые я узнала о нем из тимлидских чатов от Филиппа Дельгядо и Виталия Шароватова.

Что может быть включено в дизайн-док:

✅ Изменения REST API (как раз можно обсудить, где меняется текущий эндпойнт, а где заводится новая версия эндпойнта)

✅ Изменения в БД (как раз можно согласовать тип данных для новых полей, наличие или отсутствие констрейнтов)

✅ Описание интеграции, если она есть: схема, протокол, пример в JSON, периодичность, объем данных и другие нефункциональные требования

✅ Кратко описание логики (на дизайн-ревью лид как раз может подсказать, если часть логики уже реализована где-то и можно ее вызвать)

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

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

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

Став тимлидом в новой команде, я столкнулась с ситуацией, когда бэкендер в рамках своей задачи придумывал и реализовывал REST API, потом приходил фронт и говорил, что ему не нравится. Начиналось обсуждение, что из этого должен делать фронт, а что бэк, потом переделки, короче бррр 😵‍💫

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

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

При декомпозиции истории на подзадачи мы явно выделяем подзадачу «проектирование» и отдельно идут задачи реализации.

Плюсы подхода с дизайн-ревью:

➕ Экономит время на переделки: исправить небольшое текстовое описание проще и быстрее, чем переделывать покрытый тестами код.

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

➕ Уменьшение прокрастинации, возникшей по причине «непонятно, что вообще делать в этой задаче»

Есть ли у вас в команде согласование API, изменений в базе и подхода к реализации заранее?

Про код-ревью

Хорошо помню мое первое джунское код-ревью. Мне казалось, что я неплохо справилась, перепроверила логику несколько раз. В результате получила 20 замечаний. 20, Карл!

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

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

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

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

Заметила за собой, что почитав код проекта, начинаю писать в нем в том же стиле, подстраиваюсь под проект (если там не жесть, конечно).

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

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

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

Плюсы:

➕ обмен знаниями

➕ улучшение bus-фактора (дословно «если разработчика собьет автобус, проект не встанет»)

➕ обнаружение проблем и багов

➕ контроль качества и читаемости кода

Минусы:

➖ из-за ожидания ревью код задерживается на стадии разработки, особенно если ревьюит только лид

➖ замечания к уже написанному коду вызывают неприятные чувства у автора кода, возможны споры

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

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

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

Есть ли у вас код-ревью? Ревьюит лид или кросс-ревью между участниками команды?

Продолжим разбирать кабанчика? («Высоконагруженные приложения» Мартина Клепманна).

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

Ненадежные часы

В распределенной системе у каждого сервера в сети свои аппаратные часы, поэтому время на разных серверах всегда будет хоть немного, но отличаться. Часы можно синхронизировать до некоторой степени. Самый распространенный
механизм для этого — NTP (network time protocol, сетевой протокол времени), позволяющий компьютерам подстраивать свои часы в соответствии с временем, передаваемым группой серверов точного времени.

Виды часов

📌 Часы истинного времени возвращают текущие дату и время в соответствии с каким-то календарем. Именно они обычно синхронизируются с помощью NTP.

Например, в Java есть метод System.currentTimeMillis(). Он возвращает количество миллисекунд, прошедших с начала эры UNIX — полуночи 1 января 1970 года по UTC. Этот метод представляет собой часы истинного времени.

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

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

Например, в Java метод System.nanoTime() является примером монотонных часов.

Потеря данных при репликации

При репликации с несколькими лидерами или без лидера часто используется стратегия разрешения конфликтов «выигрывает последний» (last write wins).

Допустим у нас два лидера и реплика. На каждом лидере операции записи получают метку даты/времени в соответствии с часами этого лидера и затем реплицируются на остальные узлы.

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

Паузы на лидере при репликации

Допустим, есть БД с репликацией с одним лидером. Принимать операции записи способен только лидер. Откуда узел знает, что он все еще является лидером (а не был объявлен остальными узлами неработающим) и может спокойно принимать операции записи?

Одна из возможностей — получить договор аренды (lease). Это некое подобие блокировки с заданным временем ожидания. Быть владельцем аренды одновременно может только один узел, поэтому при получении договора узел знает, что стал лидером на некоторое время, до истечения аренды.

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

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

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

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

#кабанчик #сисдиз