Good dev knows

2021-11-17 13:09:22 High availability и Fault tolerance

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

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

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

High availability

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

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

Fault tolerance

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

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

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

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

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

#хардскиллы Открыть/Комментировать

2021-11-15 11:41:31 Про коммуникацию

Как-то раз, в компании где я работал раньше сменилось руководство. Был один СЕО, а стал вообще другой — приглашенный из вне. Так решили инвесторы. И вот новое руководство привело с собой новые метлы. У нас сменился CTО, им стал руководитель разработки банка (в прошлом).

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

Для меня, как для разработчика, оба человека были неприятными. Они говорили какие-то отстраненные вещи — давайте писать ADR, давайте все запускать в контейнерах, давайте перейдем с bash скриптов при CI на декларативный стиль. А я думал - ну что "давайте", у меня что дел нет? Мне надо фичи писать, баги чинить, разгребать технический долг.

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

CTO в компании на 100+ инженеров потратил очень много своего личного времени, чтобы переписать CI на Jenkins на что-то декларативное. Чтобы потом просто скинуть ссылку на этот репозиторий в Slack и сказать что-то типа "80% работает, я не уверен что это покрывает все что было раньше". И все на этом. Очевидно, что эта идея умерла.

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

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

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

Что думаете? Пишите в комментариях.

#истории Открыть/Комментировать

2021-11-12 12:36:00 ​​Что такое Матрица Эйзенхауэра

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

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

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

Матрица представляет собой квадрат два на два, где по горизонтали деления Срочно и Не срочно, а по вертикали Важно и Не важно.

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

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

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

Важно + Не срочно.
Такие задачи можно запланировать на будущее, а сейчас выкинуть из головы. Например, создайте задачу в бэклоге.
Например, через год заканчивается срок поддержки LTS версии Node.js. Нужно перейти на новую версию. Но это сделать это нужно не прямо сейчас, можно отложить.

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

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

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

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

#софтскиллы Открыть/Комментировать

2021-11-10 11:57:35 Все как код

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

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

Это неудобно , потому что:

1. Много ручной работы. А что если у нас есть три среды окружения - development, integration, production ? Тогда надо три раза все сделать руками.
2. Можно что-то забыть, потому что см. пункт 1.
3. Это долго, везде надо прокликать мышкой.
4. Это плохо контролируется. Принцип 4-х глаз соблюдается только, если при выполнении тебе кто-то смотрит через плечо.

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

Это удобно , потому что:

1. Можно написать один раз и применять везде
2. Все будет одинаково, ровно так, как запрограммировано
3. Код применяется быстрее
4. Код хранится в git, можно делать merge request , видеть историю изменений.

Конфигурация (серверов) как код была доступна достаточно давно, Puppet на рынке с 2005 года. Но сейчас возможности больше. Можно создавать облачные ресурсы используя terraform определения (AWS provider), можно конфигурировать метрики в New Relic используя terraform (New Relic provider).

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

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

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

#хардскиллы Открыть/Комментировать

2021-11-08 12:06:55 Почему Spring Boot это лучший в мире фреймворк и все должны его использовать

Раньше я работал с Node.js и только два года назад начал постоянно писать на Java/Kotlin и использовать Spring Boot. Мои первые впечатления подтвердили то, что я слышал раньше — ты не учишь Java, ты учишь что можно сделать с помощью фреймворка. Где создать файл, куда написать аннотацию, сначала ты не очень то и понимаешь, что эти аннотации делают. Но ты их написал и все работает — это чудо.

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

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

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

Еще один пример. У нас в проекте многие сервисы шлют change data capture сообщения в RabbitMQ, но что если что-то потерялось и нужно опять обработать все сообщения? Для этого давно написали процедуру синхронизации. Она читает все из базы данных и шлет сообщения — миллионы. Пришло время ее менять...это было то еще удовольствие .

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

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

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

А вы как, любите Srping Boot? Пишите в комментариях.

#истории Открыть/Комментировать

2021-11-05 11:54:30 Что влияет на продуктивность разработчика

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

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

В IT только и приходится что думать. Тогда как обеспечить хорошую производительность?

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

После этого на продуктивность влияют три фактора:

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

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

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

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

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

Что еще мотивирует вас работать? Пишите в комментариях.

#софтскиллы Открыть/Комментировать

2021-11-03 15:00:26 Написал немного более развенуто про Техрадар, включил обзор интересных находок.

Поддержите апвоутом плз

https://habr.com/ru/post/587184/ Открыть/Комментировать

2021-11-03 11:51:47 Что такое Technology Radar от ThoughtWorks

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

Ответить на эти вопросы поможет Technology Radar . Большая консалтинговая компания ThoughtWorks регулярно, примерно раз в полгода, выпускает документ, где субъективно рассказывает о положении на рынке технологий. Эта информация, помимо текста, отображается в виде радара.

На радаре четыре секции (описания условны):

Techniques. Техники, которые могут использоваться при разработке. Например, Four Key Metrics.

Tools. Инструменты, которые используются при разработке. Например, JavaScript сборщик Vite.

Platforms. Инфраструктурные компоненты или сервисы. Например, Backstage.

Language & Frameworks. Все про уровень языков программирования и вытекающих из них особенностей. Например, React Hooks.

В каждой секции вещи, о которых говориться, расположены в четырех категориях:

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

Assess. Стоит понаблюдать за технологией.

Trial. Стоит пощупать руками и сделать выводы.

Adopt. Можно смело внедрять.

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

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

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

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

#хардскиллы Открыть/Комментировать

2021-11-01 11:52:40 Истории и чужой опыт

Вчера был Halloween, поэтому сегодня три короткие страшные истории. Перед сном лучше не читать. Готовы?

Как-то давно, мы искали нового фронт-энд разработчика. В те далекие времена тестовое задание кандидат делал в офисе. Утром пришел кандидат, мы дали ему задание, все было в порядке, он сидел и работал. Пришло время обеда, по плану мы обедали вместе с командой. Кандидат сказал, что ему нужно позвонить и вышел... Больше его мы не видели, на звонки он не отвечал.
Когда мы заглянули в код, то что мы увидели шокировало нас! то увидели вялые попытки решить тестовое задание. Съели ли кандидата оборотни , когда он вышел позвонить? Не факт.

Когда-то давно я еще не был Хорошим разработчиком. Тогда я работал с магазинами на Magento. И вот во время оформления покупки, там был какой-то баг. PHP ошибки сыпались в браузер. Как Плохой разработчик, я, в то время, хотел не найти причину бага, а убрать его симптомы. Я загуглил и нашел что-то на Stack Overflow и применил это. Ошибки пропали. Я делал это и дальше, в других магазинах. Наверное где-то магазинов пять стерпели мое "лекарство".

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

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

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

Какие у вас были страшные истории? Расскажите в комментариях.

#истории Открыть/Комментировать

2021-10-29 11:36:00 Как давать обратную связь

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

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

Как дать адекватный фидбэк:

Подготовьтесь заранее. Лучше уведомить человека, что вы хотите провести такой митинг, чтобы он тоже подготовился.
Обратную связь нужно давать вовремя. Не прямо через 15 минут после события. Но лучше не ориентироваться на события последних 3-х месяцев.
Вы оцениваете не человека, а его дела. Вы не знаете его мотивацию.
Ваша оценка субъективна, возможно другие оценивают те же дела по другому. Расскажите о вашем восприятии.
Когда вы за что-то хвалите, это укрепляет модель поведения. Человеку будет легче ее повторить. С критикой эффект обратный.
При конструктивном фидбэке используйте технику бутерброда (знаете другое название этой техники? ). Сначала хорошее, потом критика, потом хорошее. Это просто и это работает.

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

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

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

Любите получать фидбэк? Пишите в комментариях.

#софтскиллы Открыть/Комментировать